一、 背景介绍
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) 对应用透明
附录：
60_3710_0a6c1f2734e2b49.gif[删除]
60_3710_559da718ab7e971.gif[删除]
