数据库水平切分的实现原理解析.pdf

惠卡世纪集团金融事业部技术研究院 数据库水平切分的实现原理解析 ——分库，分表，主从，集群，负载均衡器 简述 随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于 一个大型的互联网应用，每天几十亿的PV 无疑对数据库造成了相当高的负载。对于系统的 稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成 为架构研发人员首选的方式。 水平切分数据库：可以降低单台机器的负载，同时最大限度的降低了宕机造成的损失； 负载均衡策略：可以降低单台机器的访问负载，降低宕机的可能性； 集群方案：解决了数据库宕机带来的单点数据库不能访问的问题； 读写分离策略：最大限度了提高了应用中读取数据的速度和并发量； 基本原理和概念 什么是数据切分 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。 这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。 B C (陈国涛) 惠卡世纪集团金融事业部技术研究院 接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的 时候我们用到了区分字段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 的设计，本文不再赘述。 为什么要数据切分 上面对什么是数据切分做了个概要的描述和解释，读者可能会疑问，为什么需要数据切 分呢？像 Oracle 这样成熟稳定的数据库，足以支撑海量数据的存储与查询了？为什么还需 要数据切片呢？ 的确，Oracle 的DB 确实很成熟很稳定，但是高昂的使用费用和高端的硬件支撑不是每一个 公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑， 这是一般公司能支付的起的吗？即使就是能支付的起，假如有更好的方案，有更廉价且水平 扩展性能更好的方案，我们为什么不选择呢？ 我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远 远超出单台机器的某个上限的时候，我们惟有寻找别