数据库分库分表方案

MySQL使用为什么要分库分表 
可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表. 
这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗? 
其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表 
属于一个非常核用的表:朋友关系表. 

但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题. 
这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基 
本不在可能.所以大项在使用中都会面监着分库分表的应用. 

从Innodb本身来讲数据文件的Btree上只有两个锁, 叶子节点锁和子节点锁,可以想而知道,当发生页拆分或是添加 
新叶时都会造成表里不能写入数据. 
所以分库分表还就是一个比较好的选择了. 

那么分库分表多少合适呢? 
经测试在单表1000万条记录一下,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数据字型的保持在 
800万条记录以下, 有字符型的单表保持在500万以下. 

如果按 100库100表来规划,如用户业务: 
500万*100*100 = 50000000万 = 5000亿记录. 

心里有一个数了,按业务做规划还是比较容易的.

一、    背景介绍

1．大数据量的存储需要大量的数据库资源；

2．数据量的不断增长要求数据库存储具有可扩展性；

3．在保证大数据量的情况下，要保证性能、高可用性等质量要求；

4．现有框架中没有彻底解决大数据量的存储问题；

5．Oracle等海量存储方案价格不菲，采用MySQL进行分库分表节约IT成本。

二、    可行性分析

1.     风险评估

1)       DBA数据库管理的资源和规范要求；

2.    业务数据量规模和变化的影响

1)       对于事先可规划的中等以上数据规模，采用单库分表（一个数据库实例，分多张表）、读写分离、或者多库多表（多个数据库实例，多张表）可以满足业务需求，且相应设计和实现相对简单，不易出错。

2)       对于初期数据规模不可准确预知，但随着业务发展数据规模不断增长的系统，要求数据存储具有可扩展性。这种可扩展性通过分库分表解决，要求分库分表在路由上具有极强的伸缩性，这也是分库分表的难点，本方案提出一个循序渐进的实现路线逐步解决这个问题。

3.    技术积累

1)       公司已有简单的分库分表方案

2)       这个方案缺乏扩展性

3)       本方案将提出短期实现一定扩展性、中长期高可扩展性的方案

4.    开源或产品

1)       商业版数据库Sharding：MySQL Proxy，提供MySQL协议接口（非JDBC），主从结构，可以负载平衡，读写分离，failover等，lua语法复杂，不支持大数据量的分库分表；

2)       Amoeba，支持分数据库实例，每个数据相同的表，不支持事务；类似MySQL Proxy，设计上抛弃lua，更简单；

3)       阿里集团研究院开源的CobarClient，主要面向小规模的数据库sharding集群访问，基于ibatis，需要规划数据规模，缺乏扩展性；另外有Cobar，阿里集团内部的一个完整DAL层，实现完整JDBC代理；

4)       HibernateShards，Hibernate提供的sharding，支持分数据库实例，比较复杂，事先规划数据规模，和框架不符；

5)       guzz，多库（虚拟的数据库，实际数据库的路由规则仍然自定义）、表分切、读写分离，以及多台数据库之间透明的分布式事务支持，设计目标是支持大型在线生产应用；需完全替换ibatis；完全和框架不符。

6)       TDDL，淘宝的DAL，很强的分库分表能力，仍然需要数据量实现规划，动态扩展有限。

7)       以上某些产品在一定程度上可以满足我们的需求，但不能彻底解决我们大数据量可扩展的问题。

三、    性能指标

1.       和没有引入分库分表时相比，每次操作最大延迟<1ms；

四、    特性列表和RoadMap

1.     垂直分库，不同业务数据使用不同数据库实例存储

2.     数据切分：

a)       根据切分字段Hash取模；

b)       确定需要切分的数据，尽量将可能进行关联的分片数据放在一个数据库实例中，例如同一用户的基本信息、好友信息或者文件信息等；

3.     短期：分库分表

a)       数据库实例编号递增

b)       每个数据库内分表序号从1递增，不全局编号

c)       基于数据源（ibatis基础上）拦截建立访问层，应用感知

d)       应用需在底层进行数据源、分布式事务考虑和管理等

e)       可扩展性：只支持向上扩展，不支持收缩

4.     长期：数据库访问层

a)       建立灵活的数据切分和路由规则

b)       支持MySQL集群

c)       读写分离和负载均衡

d)       可用性探测

e)       分布式事务

f)        对应用透明

一、互联网当下的数据库拆分过程

对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在一个数据库中进行访问操作。但随着后续的市场推广力度不断加强，用户数量和并发量不断上升，这时如果仅靠一个数据库来支撑所有访问压力，几乎是在自寻死路。所以一旦到了这个阶段，大部分Mysql DBA就会将数据库设置成读写分离状态，也就是一个Master节点对应多个Salve节点。经过Master/Salve模式的设计后，完全可以应付单一数据库无法承受的负载压力，并将访问操作分摊至多个Salve节点上，实现真正意义上的读写分离。但大家有没有想过，单一的Master/Salve模式又能抗得了多久呢？如果用户数量和并发量出现量级上升，单一的Master/Salve模式照样抗不了多久，毕竟一个Master节点的负载还是相对比较高的。为了解决这个难题，Mysql DBA会在单一的Master/Salve模式的基础之上进行数据库的垂直分区（分库）。所谓垂直分区指的是可以根据业务自身的不同，将原本冗余在一个数据库内的业务表拆散，将数据分别存储在不同的数据库中，同时仍然保持Master/Salve模式。经过垂直分区后的Master/Salve模式完全可以承受住难以想象的高并发访问操作，但是否可以永远高枕无忧了？答案是否定的，一旦业务表中的数据量大了，从维护和性能角度来看，无论是任何的CRUD操作，对于数据库而言都是一件极其耗费资源的事情。即便设置了索引，仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实，因此这个时候Mysql DBA或许就该对数据库进行水平分区（分表，sharding），所谓水平分区指的是将一个业务表拆分成多个子表，比如user_table0、user_table1、user_table2。子表之间通过某种契约关联在一起，每一张子表均按段位进行数据存储，比如user_table0存储1-10000的数据，而user_table1存储10001-20000的数据，最后user_table3存储20001-30000的数据。经过水平分区设置后的业务表，必然能够将原本一张表维护的海量数据分配给N个子表进行存储和维护，这样的设计在国内一流的互联网企业比较常见，如图1-1所示：

 

图1-1 水平分区

 

上述笔者简单的讲解了数据库的分库分表原理。接下来请大家认真思考下。原本一个数据库能够完成的访问操作，现在如果按照分库分表模式设计后，将会显得非常麻烦，这种麻烦尤其体现在访问操作上。因为持久层需要判断出对应的数据源，以及数据源上的水平分区，这种访问方式我们称之为访问“路由”。按照常理来说，持久层不应该负责数据访问层(DAL)的工作，它应该只关心one to one的操作形式，所以淘宝的TDDL框架诞生也就顺其自然了。

 

二、TDDL的架构原型

淘宝根据自身业务需求研发了TDDL（Taobao Distributed Data Layer）框架，主要用于解决分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步，它是一个基于集中式配置的JDBC DataSource实现，具有分库分表、Master/Salve、动态数据源配置等功能。

就目前而言，许多大厂也在出一些更加优秀和社区支持更广泛的DAL层产品，比如Hibernate Shards、Ibatis-Sharding等。如果你要问笔者还为什么还要对TDDL进行讲解，那么笔者只能很无奈的表示公司要这么干，因为很多时候技术选型并不是笔者说了算，而是客户说了算。当笔者费劲所有努力在google上寻找TDDL的相关使用说明和介绍时，心里一股莫名的火已经开始在蔓延，对于更新缓慢（差不多一年没更新过SVN），几乎没社区支持（提问从不响应）的产品来说，除了蜗居在企业内部，必定走不了多远，最后的结局注定是悲哀的。好了，既然抱怨了一番，无论如何还是要坚持讲解完。TDDL位于数据库和持久层之间，它直接与数据库建立交道，如图1-2所示：

 

图1-2 TDDL所处领域模型定位

 

传说淘宝很早以前就已经对数据进行过分库分表处理，应用层连接多个数据源，中间有一个叫做DBRoute的技术对数据库进行统一的路由访问。DBRoute对数据进行多库的操作、数据的整合，让应用层像操作一个数据源一样操作多个数据库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成2个、4个、8个、16个、32个……直到1024个、2048个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询要求在几毫秒内完成），TDDL就承担了这样一个工作（其他DAL产品做得更好），如图1-3所示：

 

图1-3 TDDL分库分表查询策略

 

上述笔者描述了TDDL在分库分表环境下的查询策略，那么接下来笔者有必要从淘宝官方copy它们自己对TDDL优点的一些描述，真实性不敢保证，毕竟没完全开源，和社区零支持，大家看一看就算了，别认真。

淘宝人自定的TDDL优点：

1、数据库主备和动态切换；
2、带权重的读写分离；
3、单线程读重试；
4、集中式数据源信息管理和动态变更；
5、剥离的稳定jboss数据源；
6、支持mysql和oracle数据库；
7、基于jdbc规范，很容易扩展支持实现jdbc规范的数据源；
8、无server,client-jar形式存在，应用直连数据库；
9、读写次数,并发度流程控制，动态变更；
10、可分析的日志打印,日志流控，动态变更；