分库分表的一些策略思考

这是学习笔记的第 1912 篇文章

最近对一个业务进行了架构改造，主要是对已有的存储过程进行改写，使用SQL的方式来实现，同时对已有的业务处理做事务降维，在性能上的提升效果非常明显，本来通过存储过程是和数据库交互1次，通过SQL的方式是交互2-3次，但是从测试的效果来看，没有看到多次交互带来的流量压力，从应用层的性能来看，比原来的方式好了不少。所以通过改造为我们的后续改造树立了信心，大家也不会一味在存储过程的交互次数纠结了。

所以架构改造就进入了快车道，如果之前的进度是按照5%来更新，那么现在的进度是按照10%的迭代速度进行的，因为通过这些改造的经验沉淀，其实可改进的空间依旧非常大，而我们行之有效的大规模改造才正式开始。

事务降维其实是对应用数据的一个权衡结果，如果做一些取舍之后，整个系统的逻辑就很简单了，通过标准的DML语句即可实现，但是从存储和性能的角度来说，目前单表亿级数据量的支撑能力和业务快速增长都会让已有的架构不再使用，难以扩展，在考虑性能水平扩展的时候，分库分表就是一个很好的切入点。

比如流水型数据，属于周期性业务，那么我们可以完全按照时间维度（天）来进行分表。

分表的规则是能够对1张表生成多个子表。

而在分库分表的拆分中，我们怎么实现统一而完整的方案呢， 假设目前的业务需求支持的表分为几类，一类是周期表，一类是固定表，还有一类是数据字典表。

周期表的时间维度有五类，年，月，日，周等。目前的周期划分日是最清晰也最容易扩展的，比如日表的数据有10亿，我们可以对外统一为user_data,而内部拆分成了1000张表，这样一来每张表的量级在100万，是一个完全可控的场景，按照这种扩展速度，哪怕翻10倍都是可控的。

对于周的拆分就存在疑问了。如果我们给定一个表名，week_data,那么我们要拆分为100份，按照目前行业内的大多数中间件，可能需要有1000个database来支持这个需求，每个database只有1张表。

假设这种方式依旧可行，那么在另外两个方面就成为瓶颈了，一个是数据的清理层面，按照目前的处理方式，数据是只进难出，要删除数据的代价太高，另外一个是就是对于时间维度的支持层面很难灵活，比如有的业务逻辑对于周的划分是不同的，有的是希望支持类似时长的周，比如3月8日开始计算，一周后的时间是3月15日。

和我们常说的这种固定的周的逻辑是不同的，从业务层面来说也是合理的。

对于这列需求，我们就可以对已有的表新增两列，通过输入起始周期和结束周期来平滑对接。

这样一来数据存储就是如下的形式：

20190308 20190315 xxx xxx xxx

20190325 20190331 xxx xxx xxx

这个逻辑是通过分片逻辑很难控制的，但是我们可以指定一个配置表来做这种映射。 即通过这种时间映射得到是需要到week1_data还是week2_data中查找数据。

而从这个角度来看，已有的week为维度，我们就可以创建50多个以周围单位的表，而对于周期数据的清理，也可以更加清晰可控，这样一个以周围单位的表就可以完成线性扩展，轻松支撑亿级数据。

同理，对于月表，年表也可以采用类似的思路。

而对于固定表，没有时间维度，即数据是覆盖型的，比如存在500万数据，那么数据总量是相对稳定的，但是数据状态会不断发生变化，这类表的分表策略就相对限制一些，思路就是单库单表，基本上拆分成100-400个都是基本可控的。

而对于配置表来说，单表数据量少数的情况下，是设置为全局模式，当然这类表是越少越好。

所以分库分表的一个理念就是没有拆不开的表，只有拆不开的逻辑。要实现水平扩展，在现有的关系型基础上，虽然离完美还遥远，但是也是一种行之有效的方式。