如何定期清理数据库中的历史数据?

企业的数据库在运行相当长一段时间后,都会出现历史数据的堆积,这些数据包含了过时、重复、错误、缺失(空字段)的数据,长期占据着宝贵的数据库空间。而在上云热潮的推动下,绝大多数企业已经将他们的业务数据和服务迁移到了云端。这种转变为企业带来更大灵活性的同时,也带来了管理和维护历史数据的挑战。

拿笔者公司的数据库来说,通常数据库的空间使用率告警阈值设置为 85%,到达该阈值就会触发告警,然后就需要检查是否有历史数据可清理,如果没有,那就需要申请对数据库磁盘进行扩容。

公司的这个流程,其实也是很多企业的数据库空间管理流程,随着业务发展,存储空间告急,告警的频率必然越来越频繁,并且出于成本考虑,也无法持续无休止地购买存储空间。因此,检查和清理历史数据就成了提升数据库存储空间的有效手段,同时也可以避免因为历史数据的堆积引发的一系列数据库性能问题。

清理历史数据的有效方案

对于业务数据本身而言,它可能并不是长期有效的,我们需要把过期的历史数据从业务库中清理出来,保存到其他数据库实例进行长时间存储,同时在业务库中删除这部分数据以空出空间存储新的业务数据。

整体的方案有了,如何去执行呢?如果仅仅是通过人肉检查和清理,那将耗费大量的时间,并且可能会带来一些失误,导致误删重要数据。最重要的是,清理历史数据是一项周期性的任务,我们需要让这项任务每隔一段时间自动化地去执行,让存储空间源源不断地被空出来。

看上去复杂,实则一点也不简单,但是如果用 NineData 的数据归档功能就可以轻松搞定。

简单演示下配置方法

1. 首先,我们要确保需要归档的表中有时间字段。这一点很重要,系统需要基于这个时间字段来判断数据是否需要归档。建议每张表的设计中都添加如下两个字段,有利于数据归档和数据订正等场景,提高表的可维护性。

`created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`updated_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'

2. 创建归档任务,选择归档+清理作为归档策略,选择源和目标数据源(长时间存储用),频率选择周期执行,并选择自动执行任务的周期和启动时间。


3. 选择需要进行归档的表名和目标表名,目标表名为存放归档数据的表;时间字段是归档数据的判断依据,例如订单产生时间等;保留天数即选择需要归档多少天以前的数据,如果需要归档一年以前的数据,就在这里输入 365。

扫描二维码关注公众号,回复: 17383044 查看本文章


4. 该功能还支持设置过滤条件,只有符合过滤条件的数据才会被归档。单击映射与过滤,在数据过滤条件中输入运算表达式即可。在下图的场景下,只有 dept_no = 0 的行会被归档。


5. 单击创建任务后,就进入审批流程阶段,系统会先对任务进行预检查,审批通过后就可以执行归档任务了。


总结

根据上面的流程配置完成后,数据归档任务会基于配置的周期定期扫描数据库,找出满足归档条件的数据,并将其移动到归档存储中,然后再清理业务库中的已归档数据。这样,业务库中只保留活跃的、经常访问的数据,不仅提高了数据库的性能,还可以节省存储空间,降低存储成本。

对于性能影响方面的顾虑,笔者经过实际测试,发现 NineData 会根据主键索引和唯一索引自动分批执行任务,对于数据库的影响非常小。

仅需进行一次数据归档任务的配置,就可以实现数据库空间的自动化运维管理,再也无需手动干预,轻轻松松简化 DBA 的数据清理工作,同时还提高了数据库操作的合规性,帮助企业实现降本增效,何乐而不为呢?

猜你喜欢

转载自blog.csdn.net/NineData/article/details/136673174