冷热数据分离方案设计

冷热数据分离方案设计

引用

CSDN

1.

https://blog.csdn.net/wumi0002/article/details/137469242

在数据库性能优化中，冷热数据分离是一种常见的解决方案。本文通过一个工单处理系统的案例，详细介绍了如何通过冷热数据分离来优化查询性能，包括数据识别、迁移触发、数据分离实现等关键步骤。

问题场景

1. 有一个工单处理系统，数据库采用的是MySQL。运行一段时间后，工单表中的数据达到了几千万，工单处理明细表的数据达到了亿级，导致工单列表页面查询要10s左右才能响应。
2. 每天大概产生3万条新工单数据，业务人员会查询未处理的工单，并将工单指派给自己进行处理。
3. 已闭环的工单不会再更改，一般闭环超过一个月的工单就很少查询。

需求描述

优化未闭环工单的查询响应时长，在1s内响应。

设计思路

1. 工单有两类状态，一个是已闭环，一个是未闭环。业务人员经常查询的是未闭环的工单，而一般闭环超过一个月的工单就不再查询，且这部分数据不会再变动。所以我们将这部分不经常查询且已经固定的数据称之为冷数据，而经常查询且会变更的数据称之为热数据。
2. 区分数据之后，我们就可以将冷热数据进行分开存储，将冷数据放到一个新的MySQL数据库中，这样热数据的数据量在几百万以内，加上索引的一些优化，可以达到性能要求。

核心功能

针对这个场景，我们先识别出要实现的核心功能有哪些？

1. 如何识别出哪些是冷数据？
2. 如何触发数据迁移？
3. 如何实现冷热数据分离？
4. 历史冷数据如何迁移？
5. 如何使用冷热数据？

实现方案

如何识别出哪些是冷数据？

工单表中有【状态】、【关闭时间】字段，通过判断【状态】= 已闭环 and 【当前时间】- 【关闭时间】>= 1个月的数据则为冷数据。

如何触发数据迁移？

常见的数据迁移有两种方式，一种是及时触发，一种是定时触发。

• 及时触发有两种实现方式。

1. 一种是侵入到业务代码中，当业务达到数据迁移条件之后，调用数据迁移的方法。优点是迁移实时性高；缺点是代码侵入强，对于业务复杂或者陈旧的系统不友好，代码耦合。
2. 另一种是通过监听MySQL日志的方式，当数据表发生变动后，会发布一个消息出来，服务再去消费这个消息，进行数据迁移。优点是迁移的实时性高，不侵入业务代码，可完全独立；缺点是要引入三方中间件，增加了架构的复杂性。

这两种方式都无法进行基于时间的判断。

• 定时触发就是通过定时任务实现，每隔一段时间去扫描数据表，过滤满足迁移条件的数据进行迁移。优点是可以进行基于时间的判断，比如判断闭环时间是否超过一个月；缺点是会迁移会有延迟。

结合这个案例的场景，因为冷数据要是满足闭环时间超过一个月的条件，所以我们通过定时触发的方式来实现数据迁移。

实现实现冷热数据分离？

数据迁移核心步骤有三步：

1. 标记冷数据。
   在工单表中添加字段data_flag，当满足冷数据条件时，设置data_flag = 1，表示该数据为冷数据。
2. 将冷数据迁移至新库中。
3. 将冷数据从旧库中删除。

• 如何保证迁移的数据正确、不丢失、不重复？

由于这里要操作两个数据库，无法保证事务性，任意一步都有可能失败，当每一步发生异常的时候，我们应该如何补救呢？

若第一步失败，则在下次定时任务执行的时候，重新标记冷数据。
若第二步失败，则在下次定时任务的执行的时候，查询所有data_flag = 1的数据再做第二步迁移，这里面将包含新标记的冷数据，也包含以前标记但是迁移失败的数据。
若第三步失败，此时冷数据已经迁移至新库中但是还保留在旧库中，那我们在下一次定时任务执行的时候，再做一次第二步的迁移，所以第二步操作要保证幂等性，在插入冷数据之前先判断是否已经插入过。

经过以上的处理，我们就可以保证迁移的数据正确、不丢失、不重复。

• 大数据量情况下如何提升迁移速度？

创建一个线程池，按照线程数量，将待迁移的数据以创建时间为维度进行分区，每个线程负责迁移不同区间的部分数据，确保每个线程处理的数据互不重叠。

历史冷数据如何迁移？

通过定时任务，识别出所有的冷数据，并通过线程池，批量进行迁移。

如何使用冷热数据？

业务上将冷热数据的查询区分开来，要么查询热数据，要么查询冷数据。

方案使用场景

1. 数据归档之后就不再修改。
2. 不同时读取冷热数据。