一、背景
当业务发展到一定阶段后，存储的数据会越来越多，千万甚至过亿；此时发现，在大量数据的某个库或者表的时候，性能会被拖累。同时在主从同步，备份时，带来很大的代价（小主亲身经历，不得不把库重构）。这时候需要把一个库（表）拆分成多个库（表）
二、原则
- 平滑迁移
- 保持分布式存储机制
- CRUD操作效率提升
- 不增加空间复杂度
- 拆分均匀，避免访问倾斜
三、拆库和拆表
3.1 拆库
拆分数据源，可分为拆库和拆表；拆库的要求是所有数据可通过某一个唯一标识聚合到一起。而这种拆分方式，分为两种hash 拆分 和 冷热隔离。
hash拆分
比如某个库是用来存储用户多维度信息的，可通过用户id聚合到一起，这种库的特点是多表有共同的聚合id字段。
这种方式的拆库，需要同时操作多个库，比如mod 10 取值，那需要同时操作10个库，每个库的链接请求都是同量的，同时跨库操作也是十分麻烦的，事务就不用说了，维护成本也是成倍增加的。优点是风险分散，某一个库挂了，其他库不受影响，整体服务受影响的比例也会降低。
冷热隔离
冷热隔离，是指把冷热数据区分开，这种隔离是基于数据访问的时效性，比如新闻资讯，越近的数据被访问概率越大。冷热的区分期间，或以时间来分割，或以id来分割。这种隔离的特点是，一core多non-core，重点维护core数据，而non-core随着时间推移，越早的数据被访问的概率越小，甚至可被直接归档。这样维护的数据会是极少的几个数据库。
#拆分前
orders 订单表 （总库）
orders_info 订单基础信息
orders_cls 订单分类信息
orders_city 订单城市表
....
#拆分后
orders_2019 2019订单表
orders_info_2019 订单基础信息
orders_cls_2019 订单分类信息
orders_city_2019 订单城市表
...
orders_2018 2018订单表
orders_info_2018 订单基础信息
orders_cls_2018 订单分类信息
orders_city_2018 订单城市表
...
3.2 拆表
单独表的拆分，比库拆分简单多了，没有聚合标识的。拆表的方式比较自由，可按id，可按时间，可按某个标识聚合（比如city，age，country）等。拆表的缺点很明显，所有数据仍然还在同一个库中，随着数据越来越多，归档、备份、同步都是很大的问题，同时因为操作多张表的可能，会导致其他表性能受影响。无须dba介入，新建多张表，在代码中增加分表因子，即可拆分多表
jd_buy (库)
t_user_0 #按照uid mod 10
t_user_1
t_user_2
t_user_3
t_user_4
t_user_5
t_user_6
t_user_7
t_user_8
t_user_9
t_order_0 #按照 uid mod 10
t_order_1
t_order_2
t_order_3
t_order_4
t_order_5
t_order_6
t_order_7
t_order_8
t_order_9
....
3.3 怎么选择
本身 两者之间，没有对立，不是抑或的方案。数据存储的方案经历一个 单库单表 ==> 单库多表 ==> 多库多表的周期。拆库会增加系统维护的负责度，拆表会增加业务代码的负责度；拆库增加了系统的稳定性，降低数据依赖风险，拆表增加了单库的负责度，降低了性能，没有解决数据备份同步问题；一般选择的条件是，大量数据选择拆表，超大量数据选择拆库
4. 总结
实际大数据应用中，大数据存储不会简单使用mysql等单一数据库，经常是缓存（redis/ memcache） + 永久性存储 （mysql，mongo）+ 离线存储（hive，hbase）等方案，解决整体的实际问题。无奈拆库和拆表，都对整体的存储系统较多很大，数据存储横向扩展带来的，会对线上系统，造成一定的风险和维护代价。在分清楚数据的周期，存储价值，使用场景后，可以使用上述的三层结构来解决。
