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. 和没有引入分库分表时相比，每次操作最大延迟
四、 特性列表和roadmap1. 垂直分库，不同业务数据使用不同数据库实例存储
2. 数据切分：
a) 根据切分字段hash取模；
b) 确定需要切分的数据，尽量将可能进行关联的分片数据放在一个数据库实例中，例如同一用户的基本信息、好友信息或者文件信息等；
3. 短期：分库分表
a) 数据库实例编号递增
b) 每个数据库内分表序号从1递增，不全局编号
c) 基于数据源（ibatis基础上）拦截建立访问层，应用感知
d) 应用需在底层进行数据源、分布式事务考虑和管理等
e) 可扩展性：只支持向上扩展，不支持收缩
4. 长期：数据库访问层
a) 建立灵活的数据切分和路由规则
b) 支持mysql集群
c) 读写分离和负载均衡
d) 可用性探测
e) 分布式事务
f) 对应用透明
附录：
摘自 doliu6的专栏
bitscn.com