浅谈数据库分片技术

假如您有一个应用程序，随着业务越来越有起色，系统所牵涉到的数据量也就越来越大，此时您要涉及到对系统进行伸缩（Scale）的问题了。一种典型的扩展方法叫做“向上伸缩（Scale Up）”，它的意思是通过使用更好的硬件来提高系统的性能参数。而另一种方法则叫做“向外伸缩（Scale Out）”，它是指通过增加额外的硬件（如服务器）来达到相同的效果。从“硬件成本”还是“系统极限”的角度来说，“向外伸缩”一般都会优于“向上伸缩”，因此大部分上规模的系统都会在一定程度上考虑“向外”的方式。由于许多系统的瓶颈都处在数据存储上，因此一种叫做“数据分片（Database Sharding）”的数据架构方式应运而生，本文便会讨论这种数据架构方式的一种比较典型的实现方式。

在分布式存储系统中，数据需要分散存储在多台设备上，数据分片（Sharding）就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的：

1.分布均匀，即每台设备上的数据量要尽可能相近；
2.负载均衡，即每台设备上的请求量要尽可能相近；
3.扩缩容时产生的数据迁移尽可能少。

值得强调的是：数据分片不是银弹，它对系统的性能和伸缩性（Scalability）带来一定好处的同时，也会对系统开发带来许多复杂度。例如，有两条记录分别处在不同的服务器上，那么如果有一个业务是为它们建立一个“关联”，那么很可能表示“关联”的记录就必须在两个分区内各放一条。另外，如果您重视数据的完整性，那么跨数据分区的事务又立即变成了性能杀手。最后，如果有一些需要进行全局查找的业务，光有数据分片策略也很难对系统性能带来什么优势。

数据分片虽然重要，但在使用之前一定要三思而后行。一旦踏上这艘贼船，往往不成功便成仁，很难回头。在我的经验里，一个滥用数据分片策略而事倍功半的项目给我留下了非常深刻的印象（当然也有成功的啦），因此目前我对待数据分片策略变得愈发谨慎。所以本文的结构将会先从分片的替代方案开始介绍，即为什么选择分片技术而不用其他的方案。

分片的替代方案

功能分区：在许多环境中，单独的MySQL实例变成了各种数据库的倾销之所。你可能最终让你的主应用与Drupal共享一个数据库实例，用WordPress增强你的站点，用vBulletin增强你的博客，甚至论坛。把所有这些应用碎片分入不同的数据库实例是你首先应该考虑的，而不是直接考虑分片。客户定制系统经常有不同数据集的应用，所以这个分法很容易实现。 复制：许多应用都是“读操作”的压力大，而扩展读操作性能要比扩展写性能更容易一些。如果是这种情况，那么复制就是非常好的选择。MySQL有自带的复制功能非常健壮，虽然其异步特性增加了应用的复杂性。这种情况下，开发人员必须判断从哪台复制服务器上读取信息，不可以从哪里获取。因为你必须绝对保证你读取到的是最新的实际数据。这也正是针对MySQL出现的可替代的异步复制技术广受欢迎的原因（例如PerconaXtraDB）。这些工具把大部分集群环境下的功能提供给向单个数据库操作的能力。

缓存和队列： 缓存是降低数据库读取量的出色技术 有许多应用使用这种技术可以降低数据库读负载高达80-95%。与之相对的是队列，它是用来优化写操作的。通过合并多次写操作，提高了对数据库操作的效率。大部分大型应用都应该重点考虑这两种技术。Memcached和Redis是MySQL领域非常流行的两种缓存技术。对于队列，最流行的技术是ActiveMQ和RabbitMQ。

**外部支持技术：**MySQL在很多方面都很出色，但也不是所有方面都强。如果你需要高性能全文检索，应该考虑ElasticSearch、Sphinx或者Lucene。如果你想做大规模数据分析，可以考虑基于Hadoop的基础架构或者Vertica也是不错的选择。你应该让MySQL处理它擅长的事，把其它事留给外部支持工具来做。

如果以上的方式还是不能满足自身需求，则应该考虑分片技术。

数据分片主要有两种方式：

A.方法大纲

(1) 水平分片（以行）
　　按一定条件将全局关系的所有元组划分成若干个相交的子集，每个子集为关系的一个片段。
　　例如，一个公司下属两个子公司，每个子公司建有自己的数据库，并存放本公司的职员信息。在总公司的数据库上建立一个全局关系，可以看到全公司的全体职员信息。建立全局关系emp（视图）的语句如下：
　　CREARTE VIEW emp AS
　　（SELECT* FROM emp1@ D1）
　　UNION
　　（SELECT *FROM emp2@ D2）；
　　这样，全局关系emp中的元组实际上是分布在另外两个不同的数据库上。

(2) 垂直分片（以列）
　　把全局关系的属性集分成若干子集，形成几个垂直片段。
　　例如，全局关系emp中，有关职工的人事信息在数据库D1上，而职工的业务信息在数据库D2上。当然，有些属性（如职工号这样的关键字属性）应出现在每个垂直片中。建立全局关系EMP（视图）的语句如下：
　　CREATTE VIEW emp AS
　　SELECRT emp1.eno， emp1.ename， emp2.sal，…
　　FROM emp1@D1, emp2@D2
　　WHERE emp1.eno=emp2.eno;
　　全局关系实际上是将分布在不同数据库中的一个职工记录的各部分重新连接起来,然后投影出所要的属性。
实际上,我们可以通过视图的定义,实现全局关系数据的多种分布要求，全局关系屏蔽了数据的物理分布,提供了数据分布的又一个透明性。

B.具体实现

数据分片一般都是使用Key或Key的哈希值来计算Key的分布，常见的几种数据分片的方法如下：

1.划分号段。这种一般适用于Key为整型的情况，每台设备上存放相同大小的号段区间，如把Key为[1, 10000]的数据放在第一台设备上，把Key为[10001, 20000]的数据放在第二台设备上，依次类推。这种方法实现很简单，扩容也比较方便，成倍增加设备即可，如原来有N台设备，再新增N台设备来扩容，把每台老设备上一半的数据迁移到新设备上，原来号段为[1, 10000]的设备，扩容后只保留号段[1, 5000]的数据，把号段为[5001, 10000]的数据迁移到一台新增的设备上。此方法的缺点是数据可能分布不均匀，如小号段数据量可能比大号段的数据量要大，同样的各个号段的热度也可能不一样，导致各个设备的负载不均衡；并且扩容也不够灵活，只能成倍地增加设备。
2.取模。这种方法先计算Key的哈希值，再对设备数量取模（整型的Key也可直接用Key取模），假设有N台设备，编号为0~N-1，通过Hash(Key)%N就可以确定数据所在的设备编号。这种方法实现也非常简单，数据分布和负载也会比较均匀，可以新增任何数量的设备来扩容。主要的问题是扩容的时候，会产生大量的数据迁移，比如从N台设备扩容到N+1台，绝大部分的数据都要在设备间进行迁移。
3.检索表。在检索表中存储Key和设备的映射关系，通过查找检索表就可以确定数据分布，这里的检索表也可以比较灵活，可以对每个Key都存储映射关系，也可结合号段划分等方法来减小检索表的容量。这样可以做到数据均匀分布、负载均衡和扩缩容数据迁移量少。缺点是需要存储检索表的空间可能比较大，并且为了保证扩缩容引起的数据迁移量比较少，确定映射关系的算法也比较复杂。
4.一致性哈希。一致性哈希算法（Consistent Hashing）在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot Spot)问题，该方法的详细介绍参考此处http://blog.csdn.net/sparkliang/article/details/5279393。一致性哈希的算法简单而巧妙，很容易做到数据均分布，其单调性也保证了扩缩容的数据迁移是比较少的。

参考文章链接：

http://www.cnblogs.com/JeffreyZhao/archive/2010/03/09/sharding-by-id-characteristic.html