为什么要分库分表

移动互联网时代，海量的用户每天产生海量的数量，比如：用户表、订单表、交易流水表。

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

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

1. 分区；
2. 分库分表；
3. NoSQL/NewSQL；

说明：

只分库，或者只分表，或者分库分表融合方案都统一认为是分库分表方案，因为分库，或者分表只是一种特殊的分库分表而已。

NoSQL比较具有代表性的是MongoDB，es。

NewSQL比较具有代表性的是TiDB。

数据库架构演变

刚开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问题。

但是当用户量级上来后，写请求越来越多，该怎么办？加一个Master是不能解决问题的， 因为数据要保存一致性，写操作需要2个master之间同步，相当于是重复了，而且更加复杂。

这时就需要用到分库分表（sharding），对写操作进行切分。

为什么不 NoSQL/NewSQL?

首先，为什么不选择第三种方案NoSQL/NewSQL，我认为主要是RDBMS有以下几个优点：

RDBMS：关系型数据库管理系统（Relational Database Management System）

  - RDBMS生态完善；

  - RDBMS绝对稳定；

  - RDBMS的事务特性；

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

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

为什么不 分区?

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

分区：就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。

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

一旦分表，一个库中的表会越来越多

将整个数据库比作图书馆，一张表就是一本书。当要在一本书中查找某项内容时，如果不分章节，查找的效率将会下降。而同理，在数据库中就是分区。

• 什么时候考虑使用分区？

一张表的查询速度已经慢到影响使用的时候。

1. sql经过优化
2. 数据量大
3. 表中的数据是分段的
4. 对数据的操作往往只涉及一部分数据，而不是所有的数据

• 分区解决的问题

主要可以提升查询效率

• 分区的实现方式（简单）：

mysql5 开始支持分区功能

CREATE TABLE sales (

id INT AUTO_INCREMENT,

amount DOUBLE NOT NULL,

order_day DATETIME NOT NULL,

PRIMARY KEY(id, order_day)

) ENGINE=Innodb

PARTITION BY RANGE(YEAR(order_day)) (

PARTITION p_2010 VALUES LESS THAN (2010),

PARTITION p_2011 VALUES LESS THAN (2011),

PARTITION p_2012 VALUES LESS THAN (2012),

PARTITION p_catchall VALUES LESS THAN MAXVALUE);

• 事实上，这个方案也不错，它对用户屏蔽了sharding的细节，即使查询条件没有sharding column，它也能正常工作（只是这时候性能一般）。
• 不过它的缺点很明显：很多的资源都受到单机的限制，例如连接数，网络吞吐等！虽然每个分区可以独立存储，但是分区表的总入口还是一个MySQL示例。从而导致它的并发能力非常一般，远远达不到互联网高并发的要求！
• 至于网上提到的一些其他缺点比如：无法使用外键，不支持全文索引。我认为这都不算缺点，21世纪的项目如果还是使用外键和数据库的全文索引，我都懒得吐槽了！

所以，如果使用分区表，你的业应该具备如下两个特点：

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

并发能力要求不高；

分库分表概述

 

读写分离：分散数据库读写操作压力

分库分表：分散存储压力

适用场景

 

• 类似读写分离，分库分表也是确定没有其他优化空间之后才采取的优化方案。
• 那如果业务真的发展很快岂不是很快要进行分库分表了？那为何不一开始就设计好呢？

按照架构设计的“三原则”（简单原则，合适原则，演化原则），简单分析一下：

首先，这里的“如果”事实上发生的概率比较低，做10个业务有一个业务能活下去就很不错了，更何况快速发展，和中彩票的概率差不多。如果我们每个业务上来就按照淘宝、微信的规模去做架构设计，不但会累死自己，还会害死业务。

其次，如果业务真的发展很快，后面进行分库分表也不迟。因为业务发展好，相应的资源投入就会加大，可以投入更多的人和更多的钱，那业务分库带来的代码和业务复杂问题就可以通过加人来解决，成本问题也可以通过增加资金来解决。

分库分表的方式方法

一般就是垂直切分和水平切分，这是一种结果集描述的切分方式，是物理空间上的切分。

我们从面临的问题，开始解决，阐述： 首先是用户请求量太大，我们就堆机器搞定（这不是本文重点）。

然后是单个库太大，这时我们要看是因为表多而导致数据多，还是因为单张表里面的数据多。

如果是因为表多而数据多，使用垂直切分，根据业务切分成不同的库。

如果是因为单张表的数据量太大，这时要用水平切分，即把表的数据按某种规则切分成多张表，甚至多个库上的多张表。

分库分表的顺序应该是先垂直分，后水平分。 因为垂直分更简单，更符合我们处理现实世界问题的方式。

垂直拆分

 

垂直分表

也就是“大表拆小表”，基于列字段进行的。

一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。

一般是针对那种几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库

垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Producet一个库，订单Order一个库。

切分后，要放在多个服务器上，而不是一个服务器上。

为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。

按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。

数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。

数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

 

水平拆分

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

RANGE

从0到10000一个表，10001到20000一个表；

HASH取模

一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

地理区域

比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

时间

按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

业务分表

 

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。

如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

路由问题：

垂直分表：增加表操作的次数

水平分表：路由问题

 

数据库操作问题

多库结果集合并（group by，order by）

跨库join

分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。

 

• 解决方法

 

类似读写分离，具体实现也是“程序代码封装”和“中间件封装”，但具体实现复杂一些，因为还有要判断SQL中具体操作的表，具体操作(例如count、order by、group by等)，根据具体操作做不同的处理。

 

多分片（水平切分）返回结果合并（排序）

①Select + None Aggregate Function的有序记录合并排序

解决思路：对各分片返回的有序记录，进行排序去重合并。此处主要是编写排序去重合并算法。

②Select + None Aggregate Function的无序记录合并

解决思路：对各分片返回的无序记录，进行去重合并。

• 优点：实现比较简单。
• 缺点：数据量越大，字段越多，去重处理就会越耗时。

③Select + Aggregate Function的记录合并（排序）Oracle常用聚合函数：Count、Max、Min、Avg、Sum。

• AF：Max、Min

• 思路：通过算法对各分片返回结果再求max、min值。

• AF：Avg、Sum、Count

• 思路：分片间无重复记录或字段时，通过算法对各分片返回结果再求avg、sum、count值。分片间有重复记录或字段时，先对各分片记录去重合并，再通过算法求avg、sum、count值。

比如：

select count(*) from user

select count(deptno) from user;

select count(distinct deptno) from user;

2.多分片（水平切分）返回结果分页

解决思路：合并各分片返回结果，逻辑分页。

       优点：  实现简单。

       缺点：  数据量越大，缓存压力就越大。

                    分片数据量越大，查询也会越慢。

3.多分片（水平切分）查询有分组语法的合并

①Group By Having + None Aggregate Function时

• Select + None Aggregate Function

• 比如：select job user group by job;
• 思路：直接去重（排序）合并。

• Select + Aggregate Function

• 比如：select max(sal),job user group by job;
• 思路：同Select + Aggregate Function的记录合并（排序）。

②Group By Having + Aggregate Function时

解决思路：去掉having AF条件查询各分片，然后把数据放到一张表里。再用group by having 聚合函数查询。

4.分布式数据库架构--排序分组分页参考解决方案

• 解决方案1：Hadoop + Hive。

• 思路：使用Hadoop HDFS来存储数据，通过Hdoop MapReduce完成数据计算，通过Hive HQL语言使用部分与RDBBS一样的表格查询特性和分布式存储计算特性。
• 优点：

1. 可以解决问题
2. 具有并发处理能力
3. 可以离线处理

• 缺点：

4. 实时性不能保证
5. 网络延迟会增加
6. 异常捕获难度增加
7. Web应用起来比较复杂

• 解决方案2：总库集中查询。

• 优点：

4. 可以解决问题
5. 实现简单

• 缺点：

6. 总库数据不能太大
7. 并发压力大

5.小结

对 于分布式数据库架构来说，排序、分页、分组一直就是一个比较复杂的问题。避免此问题需要好好地设计分库、分表策略。同时根据特定的场景来解决问题。也可以 充分利用海量数据存储（Hadoop-HDFS|Hive|HBse）、搜索引擎（Lucene|Solr）及分布式计算（MapReduce）等技术来 解决问题。

别外，也可以用NoSQL技术替代关系性数据库来解决问题，比如MogonDB\redis。

 

参考来源:

https://www.jianshu.com/p/2b75742e9941

http://www.cnblogs.com/davidwang456/articles/10008544.html

https://www.cnblogs.com/sunny3096/p/8595058.html