一、背景  

    无论是传统的关系数据库还是非关系数据库，扩展问题都是一个永恒的话题。   早期传统的关系数据库，采用纵向扩展（Scale Up）的方式，即买更好的机器添加更多的资源来取得更好的性能。关系数据库通过Scale Up方式已在传统的企业应用环境中统治了将近三十多年。   但是硬件资源始终存在性能极限，纵向扩展无法一直持续下去。近年来随着数据量的暴增，尤其是云计算模式的出现，纵向扩展的方式已经无法满足需求。这时便出现了横向扩展 （Scale Out）模式。这种方式采用数据库主从配置（Master-Slave）、数据库复制 （Replication）技术以及服务器缓存（Server Cache）等，将负载分布到多个物理节点上去。本文讨论的sharding技术就是一种常见的横向扩展模式。 

二、什么是sharding

     shard是“碎片”的意思，将整个数据库打碎的过程就叫做sharding，可以翻译为分片。sharding 是把数据库Scale Out到多个物理节点上的一种有效方式。sharding可以简单理解为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个shard。 

三、常见sharding方案

1.基于功能切分 

     将功能不同的表放在不同的数据库中。 

2.基于区间范围切分  

将数据根据数值区间sharding到不同分片上，例如将uid在[1, 10000000]区间的数据放到shard1上，uid在[10000001, 20000000]区间的数据放到shard2上，以此类推...... 

扩展方案

（1）数据扩容    当数据量增长，超过预留的最大数值时就需要进行数据扩容。比如预留的最大uid为30000000，当该值快要达到时就需要进行扩容，将最大uid扩容到40000000。 

 （2）数据迁移    在设计初期，由于没有足够的数据作为sharding的参考，简单的方式就是把数据平均分到不同shard上，如每个shard均存放10000000用户的数据。系统上线后发现，如果用户id采用自增方式分配，即越早注册用户uid越小。通常情况下，系统早期用户都是比较活跃的用户。由于shard1上的用户更活跃，那么它的负载高于其他shard，当其性能出现瓶颈时就需要进行数据迁移。 

   于是将uid在区间[5000001, 10000000]上的用户数据从shard1迁移到shard2，此时数据落在shard2上的用户区间为[5000001, 20000000]。不幸的是当我们把数据从shard1迁移到shard2上后，shard2由于数据量增加也出现性能瓶颈，这时我们又需要把shard2上的数据往shard3上迁移，这就造成了恶性的连锁迁移。可以采用如下两种方案解决连锁迁移问题：

多区间sharding 即一个shard存储多个区间的数据。针对上述连锁迁移问题，先扩容出一个shard4，其负责的新用户范围为[30000001, 35000000]，并将[1, 5000000]范围内的用户数据迁移到shard4上。mongodb就是使用多区间sharding的方案进行扩展。

VIP sharding 另一种解决连锁迁移问题的方案是把特殊用户(VIP)sharding到独立的shard上，预先规划好热点用户。例如，QQ使用QQ号登陆，位数少的QQ号、有特殊含义的靓号容易记忆，也就更有价值。拥有这些QQ号的用户不是早期用户就是花了大价钱选号的用户，他们通常更活跃也更在乎用户体验，可将他们分配到专属的shard上。

3.基于hash切分  

    基于区间范围切分非常适合处理有区间查询需求的场景，但是各个shard上负载的均衡很难保证。hash切分能够较均匀地分配数据，一开始便要确定切分的shard个数，通过hash取模来决定使用哪个 shard。但是随着数据量增大，需要进行扩展的时候，就比较麻烦了。每增加一个shard，就需要对hash算法重新运算，数据需要重新切分。 

     如上图所示，当shard个数从2扩展到3时，shard1上的数据4需要迁移到shard2上，shard2上的数据3需要迁移到shard1上，shard1、shard2上也都有数据要迁移到新的shard3上。这种每个shard都会接收其他shard迁移过来的数据，每个shard也都有数据要迁移到其他众多shard，这种混乱不堪的迁移简直就是灾难。导致这种混乱不堪的迁移的原因是hash取模算法不具备单调性，下面我们就说明何为hash算法的单调性。

hash算法单调性 hash算法的一个重要衡量指标就是单调性，其定义如下：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。为了让扩展更方便，我们需要保证hash算法具有单调性，下文介绍两种hash扩展方案。

扩展方案

（1）一致性hash     著名的分布式缓存系统memcached就是采用一致性hash将数据sharding到不同节点上，算法如下：  首先求出memcached服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上；  然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上；  然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台memcached服务器上。 

  当需要增加一个新的节点node5时，如果是增加在node2和node4之间，那么只有node2和node4之间部分数据会迁移到node5上，其他数据均不需要迁移。 

 （2）二叉树扩展     二叉树扩展也能够很好地解决迁移混乱问题，redis在rehash渐进式迁移时就采用的这种方案。二叉树扩展要求shard的个数为2n个，只要满足此要求即可进行二叉树扩展。下面我们图解数据库如何进行二叉树扩展 ：   

    假设我们数据的范围为[1, 2, 3, 4, 5, 6, 7, 8]，一开始我们有2个shard，数据为[2, 4, 6, 8]和[1, 3, 5, 7]，现在发现性能出现瓶颈，需要对其进行扩展；     对shard1和shard2分别建一个从库，主从同步完成后将其作为新的分片shard3和shard4，同时将取模算法从mod 2改为mod 4；     此时每个shard上包含了不用迁移出去的数据，而需要迁移出去的数据其他shard上已经存在，不需要进行迁移，只需将其删除即可。下图中标红的数据就是需要删除的数据。 

 4.基于路由表切分  

     前面的几种方式都是跟据应用的数据来决定操作的shard，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行。

 四、总结

sharding优点

（1）提高了数据库的可扩展性。可以随着应用的增长来增加更多的服务器，只需要将新增加的数据以及负载放到新加的服务器上即可。

（2）提高了数据库的可用性。其中几个shard服务器down掉之后，并不会使整个系统瘫痪，只会影响到需要访问这几个shard服务器上的数据的用户。

（3）数据量小的数据库的负载较小，查询更快，性能更好。

（4）系统有更好的可维护性。对系统的升级和配置可以按照shard一个一个来做，并不会对服务产生大的影响。

常见sharding方案对比

基于功能切分是纯粹业务上的隔离，更多的是业务层面的考量。 基于区间范围切分非常适合处理有区间查询需求的场景，但是各个shard上负载的均衡很难保证。 基于hash切分能够较均匀地分配数据，但是扩展比较麻烦，需要保证hash算法单调性。 基于路由表切分，最灵活、最通用、最容易扩展和迁移，但是需要额外维护路由数据。