亿级大表垂直拆分:上云业务的工程实践
原创 修改于 2023-10-14 10:59:09 6810 举报 文章被收录于专栏:后台技术汇1、前言
伴随着不断扩张的业务量,在数据库层面一般会经历数据拆分。解决问题的第一步,就是重新评估 DB 表结构设计的合理性。
2、大表问题
我实际遇到的是怎么样的情况呢?下面我简单介绍下(做了脱敏处理):
过去对表结构设计时,研发由于忽略了业务原子性,使用了一个大字段(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 变更期间,由于强同步配置,难免造成从库的数据延迟问题。
3、大表的垂直拆分
数据库拆分原则:就是指通过某种特定的条件,按照某个维度,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面以达到分散单库(主机)负载的效果。
数据库拆分,分为水平和垂直拆分两种;
- 水平拆分的典型场景就是大家熟知的分库分表;
- 垂直拆分则倾向于表重构,按照业务维度进行数据切割。
上文讲了大表背景下导致的种种问题,基于上述原因,我们团队决定趁着重构的机会,进行一次大表垂直拆分:大字段迁移。
经过和 DBA 的一起分析,发现该表存在一个 LONGTEXT 的字段,它占用了几乎整个表体积空间的 60%以上。
在处理这个大表的问题上,我们有考虑过水平拆分的手段。
按照某种策略(基于项目 id,基于用户 id,基于冷热项目等),但始终不能较好的将数据均匀平摊到每个分表,甚至会因为热点项目再次带来大表问题,因此并不采纳这个方案。
我们最终选择垂直拆分的方案。
原因是这个大字段,本身就是一个结构化的对象数据,结构化对象最终可以抽象成一张表。通过将这个大字段拆分到一个新表,随后完成旧表的数据迁移和清理。
4、解决方案
制定了 DB 变更方案之后,我们要按照真实环境部署来完善方案细节。
1、新表创建:这类 SQL 操作,我们都会提单给 DBA 评估执行。
2、数据迁移(存量数据):这里我们用定时任务来完成。
如果简单使用 UPDATE 务,会带来表锁的开销,这会直接影响线上业务;我们是不停服变更,因此绝对不能影响正常业务。
定时任务逻辑很简单:查出一条老数据,插入一条新数据。这里建议直接设定一个区间,按照主键 ID 来遍历;否则通过任何索引+分页的手段,最后都会面临深度分页带来的性能问题,属于是本末倒置了。
3、开启双写(增量数据):正常业务是会源源不断产生增量数据的,此时要确保数据在新旧表都有一份,这样才能完全兼容业务。
4、兼容 API:数据迁移是需要切换时间的,这个缓冲期需要保持对 API 的兼容,包括对新表 or 旧表的读操作,其他依赖业务的读操作等。
5、关闭双写:数据迁移完成后,老表的字段不需要再写入数据,因此可以修改 Insert 的 SQL,停止该字段写入。
6、清理旧表:确认线上业务不依赖旧表之后,DBA 可以进行磁盘碎片回收。
5、总结与思考
DB 变更操作是一个高风险动作,我们前期评估一定要充分考虑到以下场景,否则容易引发生产事故:
- 存量数据迁移
- 系统的老逻辑也要保持兼容
- 增量数据双写
- 注意灰度情况的监控,及时修复双写的业务漏洞
- 迁移过程可能引发的性能危机
- 甚至有可能依赖业务接口,这样可能导致接口并发量上去
- 适当设置线程休眠,可以缓解带来的性能问题
- 迁移数据里程碑
- 因为迁移过程是一端长期而缓慢,要记录好时间节点,避免漏同步或者重复同步的问题