数据库分片（Sharding）技术
假如您有一个应用程序，随着业务越来越有起色，系统所牵涉到的数据量也就越来越大，此时您要涉及到对系统进行伸缩（Scale）的问题了。
一种典型的扩展方法叫做“向上伸缩（Scale Up）”，它的意思是通过使用更好的硬件来提高系统的性能参数。
而另一种方法则叫做“向外伸缩（Scale Out）”，它是指通过增加额外的硬件（如服务器）来达到相同的效果。
从“硬件成本”还是“系统极限”的角度来说，“向外伸缩”一般都会优于“向上伸缩”，因此大部分上规模的系统都会在一定程度上考虑“向外”的方式。由于许多系统的瓶颈都处在数据存储上，因此一种叫做“数据分片（Database Sharding）”的数据架构方式应运而生，本文便会讨论这种数据架构方式的一种比较典型的实现方式。
简介
数据分片，是将整体数据分摊在多个存储设备（下文统称为“数据分区”或“分区”）上，这样每个存储设备的数据量相对就会小很多，以此满足系统的性能需求。
值得注意的是，系统分片的策略有很多，例如常见的有以下几种：
（1）根据ID特征：例如对记录的ID取模，得到的结果是几，那么这条记录就放在编号为几的数据分区上。
（2）根据时间范围：例如前100万个用户数据在第1个分区中，第二个100万用户数据放在第2个分区中。
基于检索表：根据ID先去一个表内找到它所在的分区，然后再去目标分区进行查找。
在这些数据分片策略之中没有哪个有绝对的优势，选择哪种策略完全是根据系统的业务或是数据特征来确定的。值得强调的是：数据分片不是银弹，它对系统的性能和伸缩性（Scalability）带来一定好处的同时，也会对系统开发带来许多复杂度。例如，有两条记录分别处在不同的服务器上，那么如果有一个业务是为它们建立一个“关联”，那么很可能表示“关联”的记录就必须在两个分区内各放一条。另外，如果您重视数据的完整性，那么跨数据分区的事务又立即变成了性能杀手。最后，如果有一些需要进行全局查找的业务，光有数据分片策略也很难对系统性能带来什么优势。
数据分片
在ORACLE 中，【全局关系】是一个【视图】，而数据分片是通过关系数据的基本运算实现的，这一点在全局视图的定义中体现。
数据分片主要有两种方式：
(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;
全局关系实际上是将分布在不同数据库中的一个职工记录的各部分重新连接起来,然后投影出所要的属性。
实际上,我们可以通过视图的定义,实现全局关系数据的多种分布要求，全局关系屏蔽了数据的物理分布,提供了数据分布的又一个透明性。
--------------------------------------------------------------------------------------------------
“Shard”字面意思为碎片，Sharding可以译为【分片】。
MySQL5以后提供了Sharding的能力，其目的就是为突破单节点数据服务器I/O能力限制，解决数据库Scale Out水平扩展的问题。通过Sharding可以将数据按照物理位置贴合用户分布，得到更加快速的响应；操作庞然大物总是让人头疼，Sharding将数据分块，更小的数据集操作汇总能够得到更加的体验；
分片使得数据分摊在各个数据节点，对其操作实现负载均衡！