亿级大表垂直拆分：上云业务的工程实践

1、前言

伴随着不断扩张的业务量，在数据库层面一般会经历数据拆分。解决问题的第一步，就是重新评估 DB 表结构设计的合理性。

我实际遇到的是怎么样的情况呢？下面我简单介绍下(做了脱敏处理)：

过去对表结构设计时，研发由于忽略了业务原子性，使用了一个大字段（TEXT/LONGTEXT/JSON 等）存储了耦合业务的大数据字段，如今表行数已经接近 1 亿了，总使用空间超过 100G；虽然碎片率不高，但仍有 1.97GB 的碎片空间。

DB 大表的存在导致了诸多问题：

1、读查询：每次带大字段的 SQL 被执行了，都会引起从 DB-Server 到应用服务之间的一次大数据量传输；如果 SQL 执行并发量大，吃机器内存的情况，将发生在 Mysql-Server 和应用容器中，甚至 OOM；

2、业务拓展：业务是不断往前迭代的，意味着针对这个表，将不断有 DDL 和 DML 的 SQL 被执行；这也注定了，如果不对大表进行瘦身，第 1 点提到的问题，将是一颗定时炸弹，埋在不断被堆积的业务里；

3、DB 运维：在追求平滑升级的背景下，我们对表结构变更时，一般选择是在业务低峰期，对临时表进行拷贝，然后执行 DDL 变更（增删字段和索引），最后通过 rename 完成业务切换；大表的临时表将具有跟原表同样大小体积，这对运维来说，每次备份大表都是一个巨大的资源和时间开销。

4、业务隐患：为了完成 DB 高可用部署，我们的业务上云之后，采取了一主多从的部署架构。因此 DDL 变更期间，由于强同步配置，难免造成从库的数据延迟问题。

数据库拆分原则：就是指通过某种特定的条件，按照某个维度，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面以达到分散单库（主机）负载的效果。

数据库拆分，分为水平和垂直拆分两种；

上文讲了大表背景下导致的种种问题，基于上述原因，我们团队决定趁着重构的机会，进行一次大表垂直拆分：大字段迁移。

经过和 DBA 的一起分析，发现该表存在一个 LONGTEXT 的字段，它占用了几乎整个表体积空间的 60%以上。

在处理这个大表的问题上，我们有考虑过水平拆分的手段。

按照某种策略（基于项目 id，基于用户 id，基于冷热项目等），但始终不能较好的将数据均匀平摊到每个分表，甚至会因为热点项目再次带来大表问题，因此并不采纳这个方案。

我们最终选择垂直拆分的方案。

原因是这个大字段，本身就是一个结构化的对象数据，结构化对象最终可以抽象成一张表。通过将这个大字段拆分到一个新表，随后完成旧表的数据迁移和清理。

制定了 DB 变更方案之后，我们要按照真实环境部署来完善方案细节。

1、新表创建：这类 SQL 操作，我们都会提单给 DBA 评估执行。

2、数据迁移（存量数据）：这里我们用定时任务来完成。

如果简单使用 UPDATE 务，会带来表锁的开销，这会直接影响线上业务；我们是不停服变更，因此绝对不能影响正常业务。

定时任务逻辑很简单：查出一条老数据，插入一条新数据。这里建议直接设定一个区间，按照主键 ID 来遍历；否则通过任何索引分页的手段，最后都会面临深度分页带来的性能问题，属于是本末倒置了。

3、开启双写（增量数据）：正常业务是会源源不断产生增量数据的，此时要确保数据在新旧表都有一份，这样才能完全兼容业务。

4、兼容 API：数据迁移是需要切换时间的，这个缓冲期需要保持对 API 的兼容，包括对新表 or 旧表的读操作，其他依赖业务的读操作等。

5、关闭双写：数据迁移完成后，老表的字段不需要再写入数据，因此可以修改 Insert 的 SQL，停止该字段写入。

6、清理旧表：确认线上业务不依赖旧表之后，DBA 可以进行磁盘碎片回收。

DB 变更操作是一个高风险动作，我们前期评估一定要充分考虑到以下场景，否则容易引发生产事故：

我正在参与腾讯云开发者社区数据库专题有奖征文。

0 人点赞