数据库水平切分的实现原理解析——分库，分表

第1章 引言
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。

• 水平切分数据库：可以降低单台机器的负载，同时最大限度的降低了宕机造成的损失
• 负载均衡策略：可以降低单台机器的访问负载，降低宕机的可能性
• 集群方案：解决了数据库宕机带来的单点数据库不能访问的问题
• 读写分离策略：最大限度了提高了应用中读取数据的速度和并发量

第2章 基本原理和概念
什么是数据切分
"Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由或者table路由规则找到需要查询的具体的DB或者table，以进行Query操作。“sharding”通常是指“水平切分”，这也是本文讨论的重点。接下来举个简单的例子：我们针对一个Blog应用中的日志来说明，比如日志文章（article）表有如下字段：


面对这样的一个表，我们怎样切分呢？怎样将这样的数据分布到不同的数据库中的表中去呢？我们可以这样做，将user_id为1～10000的所有的文章信息放入DB1中的article表中，将user_id为10001～20000的所有文章信息放入DB2中的 article表中，以此类推，一直到DBn。这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。

接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的时候我们用到了区分字段user_id，那么很自然，数据库路由的过程当然还是少不了user_id的。就是我们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库。比如user_id是234，利用刚才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程我们称之为“DB路由”。

平常我们会自觉的按照范式来设计我们的数据库，考虑到数据切分的DB设计，将违背这个通常的规矩和约束。为了切分，我们不得不在数据库的表中出现冗余字段，用作区分字段或者叫做分库的标记字段。比如上面的article的例子中的user_id这样的字段（当然，刚才的例子并没有很好的体现出user_id的冗余性，因为user_id这个字段即使就是不分库，也是要出现的，算是我们捡了便宜吧）。当然冗余字段的出现并不只是在分库的场景下才出现的，在很多大型应用中，冗余也是必须的，这个涉及到高效DB的设计，本文不再赘述。

参考：http://www.cnblogs.com/zhongxinWang/p/4262650.html