分库分表的基本思想

时间 2019-11-19

标签分库分表基本思想繁體版

原文原文链接

Sharding的基本思想就要把一个数据库切分红多个部分放到不一样的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，若是是由于表多而数据多，这时候适合使用垂直切分，即把关系紧密（好比同一模块）的表切分出来放在一个server上。若是表并很少，但每张表的数据很是多，这时候适合水平切分，即把表的数据按某种规则（好比按ID散列）切分到多个数据库(server)上。固然，现实中更可能是这两种状况混杂在一块儿，这时候须要根据实际状况作出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分红相似矩阵同样能够无限扩充的数据库(server)阵列。html

须要特别说明的是：当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。好比：在只考虑垂直切分的时候，被划分到一块儿的表之间能够保持任意的关联关系，所以你能够按“功能模块”划分表格，可是一旦引入水平切分以后，表间关联关系就会受到很大的制约，一般只能容许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将再也不以“功能模块”进行划分，而是须要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至能够说是彻底一致，每一个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，可是shard里的表却很少），为了不管理过多的数据源，充分利用每个数据库服务器的资源，能够考虑将业务上相近，而且具备相近数据增加速率（主表数据量在同一数量级上）的两个或多个shard放到同一个数据源里，每一个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不一样的只是它们的散列取模（即节点数量）必需是一致的.java

经常使用的分库分表中间件

简单易用的组件：

强悍重量级的中间件：

分库分表须要解决的问题

一、事务问题

解决事务问题目前有两种可行的方案：分布式事务和经过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。mysql

方案一：使用分布式事务

优势：交由数据库管理，简单有效

缺点：性能代价高，特别是shard愈来愈多时

方案二：由应用程序和数据库共同控制

原理：将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并经过应用程序来总控各个小事务。

优势：性能上有优点

缺点：须要应用程序在事务控制上作灵活设计。若是使用了spring的事务管理，改动起来会面临必定的困难。

二、跨节点Join的问题

只要是进行切分，跨节点Join的问题是不可避免的。可是良好的设计和切分却能够减小此类状况的发生。解决这一问题的广泛作法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求获得关联数据。git

三、跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，由于它们都须要基于所有数据集合进行计算。多数的代理都不会自动处理合并工做。解决方案：与解决跨节点join问题的相似，分别在各个节点上获得结果后在应用程序端进行合并。和join不一样的是每一个结点的查询能够并行执行，所以不少时候它的速度要比单一大表快不少。但若是结果集很大，对应用程序内存的消耗是一个问题。github

四、数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具备向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，可是依然须要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来讲，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。算法

五、事务

分布式事务
参考： [关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究](http://blog.csdn.net/bluishglc/article/details/7612811)
优势

基于两阶段提交，最大限度地保证了跨数据库操做的“原子性”，是分布式系统下最严格的事务实现方式。

实现简单，工做量小。因为多数应用服务器以及一些独立的分布式事务协调器作了大量的封装工做，使得项目中引入分布式事务的难度和工做量基本上能够忽略不计。

缺点

系统“水平”伸缩的死敌。基于两阶段提交的分布式事务在提交事务时须要在多个节点之间进行协调,最大限度地推后了提交事务的时间点，客观上延长了事务的执行时间，这会致使事务在访问共享资源时发生冲突和死锁的几率增高，随着数据库节点的增多，这种趋势会愈来愈严重，从而成为系统在数据库层面上水平伸缩的"枷锁"，这是不少Sharding系统不采用分布式事务的主要缘由。

基于Best Efforts 1PC模式的事务

参考spring-data-neo4j的实现。鉴于Best Efforts 1PC模式的性能优点，以及相对简单的实现方式，它被大多数的sharding框架和项目采用spring

事务补偿（幂等值）

对于那些对性能要求很高，但对一致性要求并不高的系统，每每并不苛求系统的实时一致性，只要在一个容许的时间周期内达到最终一致性便可，这使得事务补偿机制成为一种可行的方案。事务补偿机制最初被提出是在“长事务”的处理中，可是对于分布式系统确保一致性也有很好的参考意义。笼统地讲，与事务在执行中发生错误后当即回滚的方式不一样，事务补偿是一种过后检查并补救的措施，它只指望在一个允许时间周期内获得最终一致的结果就能够了。事务补偿的实现与系统业务紧密相关，并无一种标准的处理方式。一些常见的实现方式有：对数据进行对账检查;基于日志进行比对;按期同标准数据来源进行同步，等等。sql

六、ID问题

一旦数据库被切分到多个物理结点上，咱们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID没法保证在全局上是惟一的；另外一方面，应用程序在插入数据以前须要先得到ID,以便进行SQL路由.
一些常见的主键生成策略数据库

UUID

使用UUID做主键是最简单的方案，可是缺点也是很是明显的。因为UUID很是的长，除占用大量存储空间外，最主要的问题是在索引上，在创建索引和基于索引进行查询时都存在性能问题。服务器

结合数据库维护一个Sequence表

此方案的思路也很简单，在数据库中创建一个Sequence表，表的结构相似于：
CREATE TABLE `SEQUENCE` (  
    `table_name` varchar(18) NOT NULL,  
    `nextid` bigint(20) NOT NULL,  
    PRIMARY KEY (`table_name`)  
) ENGINE=InnoDB
每当须要为某个表的新纪录生成ID时就从Sequence表中取出对应表的nextid,并将nextid的值加1后更新到数据库中以备下次使用。此方案也较简单，但缺点一样明显：因为全部插入任何都须要访问该表，该表很容易成为系统性能瓶颈，同时它也存在单点问题，一旦该表数据库失效，整个应用程序将没法工做。有人提出使用Master-Slave进行主从同步，但这也只能解决单点问题，并不能解决读写比为1:1的访问压力问题。

Twitter的分布式自增ID算法Snowflake

在分布式系统中，须要生成全局UID的场合仍是比较多的，twitter的snowflake解决了这种需求，实现也仍是很简单的，除去配置信息，核心代码就是毫秒级时间41位机器ID 10位毫秒内序列12位。
* 10---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000
在上面的字符串中，第一位为未使用（实际上也可做为long的符号位），接下来的41位为毫秒级时间，而后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），而后12位该毫秒内的当前毫秒内的计数，加起来恰好64位，为一个Long型。

这样的好处是，总体上按照时间自增排序，而且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID做区分），而且效率较高，经测试，snowflake每秒可以产生26万ID左右，彻底知足须要。

七、跨分片的排序分页

通常来说，分页时须要按照指定字段进行排序。当排序字段就是分片字段的时候，咱们经过分片规则能够比较容易定位到指定的分片，而当排序字段非分片字段的时候，状况就会变得比较复杂了。为了最终结果的准确性，咱们须要在不一样的分片节点中将数据进行排序并返回，并将不一样分片返回的结果集进行汇总和再次排序，最后再返回给用户。以下图所示：

上面图中所描述的只是最简单的一种状况（取第一页数据），看起来对性能的影响并不大。可是，若是想取出第10页数据，状况又将变得复杂不少，以下图所示：

有些读者可能并不太理解，为何不能像获取第一页数据那样简单处理（排序取出前10条再合并、排序）。其实并不难理解，由于各分片节点中的数据多是随机的，为了排序的准确性，必须把全部分片节点的前N页数据都排序好后作合并，最后再进行总体的排序。很显然，这样的操做是比较消耗资源的，用户越日后翻页，系统性能将会越差。
那如何解决分库状况下的分页问题呢？有如下几种办法：

若是是在前台应用提供分页，则限定用户只能看前面n页，这个限制在业务上也是合理的，通常看后面的分页意义不大（若是必定要看，能够要求用户缩小范围从新查询）。

若是是后台批处理任务要求分批获取数据，则能够加大page size，好比每次获取5000条记录，有效减小分页数（固然离线访问通常走备库，避免冲击主库）。

分库设计时，通常还有配套大数据平台汇总全部分库的记录，有些分页查询能够考虑走大数据平台。

八、分库策略

分库维度肯定后，如何把记录分到各个库里呢?
通常有两种方式：

根据数值范围，好比用户Id为1-9999的记录分到第一个库，10000-20000的分到第二个库，以此类推。

根据数值取模，好比用户Id mod n，余数为0的记录放到第一个库，余数为1的放到第二个库，以此类推。

优劣比较：
评价指标按照范围分库按照Mod分库
库数量前期数目比较小，能够随用户/业务按需增加前期即根据mode因子肯定库数量，数目通常比较大
访问性能前期库数量小，全库查询消耗资源少，单库查询性能略差前期库数量大，全库查询消耗资源多，单库查询性能略好
调整库数量比较容易，通常只需为新用户增长库，老库拆分也只影响单个库困难，改变mod因子致使数据在全部库之间迁移
数据热点新旧用户购物频率有差别，有数据热点问题新旧用户均匀到分布到各个库，无热点
实践中，为了处理简单，选择mod分库的比较多。同时二次分库时，为了数据迁移方便，通常是按倍数增长，好比初始4个库，二次分裂为8个，再16个。这样对于某个库的数据，一半数据移到新库，剩余不动，对比每次只增长一个库，全部数据都要大规模变更。
补充下，mod分库通常每一个库记录数比较均匀，但也有些数据库，存在超级Id，这些Id的记录远远超过其余Id，好比在广告场景下，某个大广告主的广告数可能占整体很大比例。若是按照广告主Id取模分库，某些库的记录数会特别多，对于这些超级Id，须要提供单独库来存储记录。

九、分库数量

分库数量首先和单库能处理的记录数有关，通常来讲，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(固然处理能力和字段数量/访问模式/记录长度有进一步关系)。

在知足上述前提下，若是分库数量少，达不到分散存储和减轻DB性能压力的目的；若是分库的数量多，好处是每一个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序须要访问多个库，若是是并发模式，要消耗宝贵的线程资源；若是是串行模式，执行时间会急剧增长。

最后分库数量还直接影响硬件的投入，通常每一个分库跑在单独物理机上，多一个库意味多一台设备。因此具体分多少个库，要综合评估，通常初次分库建议分4-8个库。

十、路由透明

分库从某种意义上来讲，意味着DB schema改变了，必然影响应用，但这种改变和业务无关，因此要尽可能保证分库对应用代码透明，分库逻辑尽可能在数据访问层处理。固然彻底作到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：

对于单库访问，好比查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。

对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。

十一、使用框架仍是自主研发

目前市面上的分库分表中间件相对较多，其中基于代理方式的有MySQL Proxy和Amoeba，基于Hibernate框架的是Hibernate Shards，基于jdbc的有当当sharding-jdbc，基于mybatis的相似maven插件式的有蘑菇街的蘑菇街TSharding，经过重写spring的ibatis template类是Cobar Client，这些框架各有各的优点与短板，架构师能够在深刻调研以后结合项目的实际状况进行选择，可是总的来讲，我我的对于框架的选择是持谨慎态度的。一方面多数框架缺少成功案例的验证，其成熟性与稳定性值得怀疑。另外一方面，一些从成功商业产品开源出框架（如阿里和淘宝的一些开源项目）是否适合你的项目是须要架构师深刻调研分析的。固然，最终的选择必定是基于项目特色、团队情况、技术门槛和学习成本等综合因素考量肯定的。