基于MySQL分库分表方案简介

1、    背景介绍

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

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

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

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

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

2、    可行性分析

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)       以上某些产品在必定程度上能够知足咱们的需求，但不能完全解决咱们大数据量可扩展的问题。

3、    性能指标

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

4、    特性列表和RoadMap

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

2.     数据切分：

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

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

3.     短时间：分库分表

a)       数据库实例编号递增

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

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

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

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

4.     长期：数据库访问层

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

b)       支持MySQL集群

c)       读写分离和负载均衡

d)       可用性探测

e)       分布式事务

f)        对应用透明

附录：