分库分表的技术演进

每一个优秀的程序员和架构师都应该掌握分库分表，这是个人观点。

移动互联网时代，海量的用户天天产生海量的数量，好比：

• 用户表

• 订单表

• 交易流水表

以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，好比美团外卖，天天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。事实上MySQL单表能够存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW如下是最佳状态，由于这时它的BTREE索引树高在3~5之间。

既然一张表没法搞定，那么就想办法将数据放到多个地方，目前比较广泛的方案有3个：

1. 分区；

2. 分库分表；

3. NoSQL/NewSQL；

说明：只分库，或者只分表，或者分库分表融合方案都统一认为是分库分表方案，由于分库，或者分表只是一种特殊的分库分表而已。NoSQL比较具备表明性的是MongoDB，es。NewSQL比较具备表明性的是TiDB。

Why Not NoSQL/NewSQL?

首先，为何不选择第三种方案NoSQL/NewSQL，我认为主要是RDBMS有如下几个优势：
- RDBMS生态完善；
- RDBMS绝对稳定；
- RDBMS的事务特性；

NoSQL/NewSQL做为新生儿，在咱们把可靠性当作首要考察对象时，它是没法与RDBMS相提并论的。RDBMS发展几十年，只要有软件的地方，它都是核心存储的首选。

目前绝大部分公司的核心数据都是：以RDBMS存储为主，NoSQL/NewSQL存储为辅！互联网公司又以MySQL为主，国企&银行等不差钱的企业以Oracle/DB2为主！NoSQL/NewSQL宣传的不管多牛逼，就如今各大公司对它的定位，都是RDBMS的补充，而不是取而代之！

Why Not 分区?

咱们再看分区表方案。了解这个方案以前，先了解它的原理：

分区表是由多个相关的底层表实现，这些底层表也是由句柄对象表示，因此咱们也能够直接访问各个分区，存储引擎管理分区的各个底层表和管理普通表同样（全部的底层表都必须使用相同的存储引擎），分区表的索引只是在各个底层表上各自加上一个相同的索引，从存储引擎的角度来看，底层表和一个普通表没有任何不一样，存储引擎也无须知道这是一个普通表仍是一个分区表的一部分。

事实上，这个方案也不错，它对用户屏蔽了sharding的细节，即便查询条件没有sharding column，它也能正常工做（只是这时候性能通常）。不过它的缺点很明显：不少的资源都受到单机的限制，例如链接数，网络吞吐等！虽然每一个分区能够独立存储，可是分区表的总入口仍是一个MySQL示例。从而致使它的并发能力很是通常，远远达不到互联网高并发的要求！

至于网上提到的一些其余缺点好比：没法使用外键，不支持全文索引。我认为这都不算缺点，21世纪的项目若是仍是使用外键和数据库的全文索引，我都懒得吐槽了！

因此，若是使用分区表，你的业务应该具有以下两个特色：

1. 数据不是海量（分区数有限，存储能力就有限）；

2. 并发能力要求不高；

Why 分库分表?

最后要介绍的就是目前互联网行业处理海量数据的通用方法：分库分表。

虽然你们都是采用分库分表方案来处理海量核心数据，可是尚未一个一统江湖的中间件，笔者这里列举一些有必定知名度的分库分表中间件：

• 阿里的TDDL，DRDS和cobar，

• 开源社区的sharding-jdbc（3.x已经改名为sharding-sphere）；

• 民间组织的MyCAT；

• 360的Atlas；

• 美团的zebra；

其余好比网易，58，京东等公司都有自研的中间件。总之各自为战，也能够说是百花齐放。

可是这么多的分库分表中间件所有能够归结为两大类型：

• CLIENT模式；

• PROXY模式；

CLIENT模式表明有阿里的TDDL，开源社区的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已经支持了proxy模式）。架构以下：

PROXY模式表明有阿里的cobar，民间组织的MyCAT。架构以下：

可是，不管是CLIENT模式，仍是PROXY模式。几个核心的步骤是同样的：SQL解析，重写，路由，执行，结果归并。