背景
1、产品的问题点
- PG 不支持rotate表
2、问题点背后涉及的技术原理
- 什么是rotate表?
- 指定一个表的最大记录条数, 最大空间使用上限, 当记录数或者空间达到使用上限后, 覆盖老的记录.
- 通常在文档数据库, KV缓存数据库中常见.
- KV通常都有记录的生命周期需求, 设置TTL成为KV数据库的标配.
- 文档数据库早期的业务场景也包含了监控类业务, 因为监控指标多种多样, 通过schemaless切入进去很容易, 而且监控数据本身也有生命周期的诉求, 业务库并不需要保留所有的监控记录, 可以用比较小的实例就能满足大多数监控场景诉求(因为一般也不会为监控系统投入那么多钱, 估计给的机器也比较烂).
3、这个问题将影响哪些行业以及业务场景
- 保存有限时间的日志类的业务场景
- 监控日志、业务日志
4、会导致什么问题?
- 没有rotate表时, 需要人为清理.
- 如果设计不合理或者等数据量大到一定程度再大量清理的话, 可能导致空间膨胀, 产生大量wal的问题.
- 当然, 也可以采用insert新表 + drop 老表来解决产生大量wal日志的问题.
5、业务上应该如何避免这个坑
- 创建任务, 监控表的大小, 到达记录条数或空间上限后, 删除老的记录
- 使用分区表, 达到阈值后删除老的分区, 增加新的分区
- 不能做到精确控制
- 创建任务, 使用多个表轮换
- 切换表名时是DDL操作, 虽然更换表名很快, 但是会造成短暂的排他锁, 如果加锁时遇到有长查询堵塞, 操作不当可能引擎雪崩. (建议加DDL超时)
- 例子
- 《PostgreSQL rotate table 自动清理调度 - 约束，触发器》
- 《PostgreSQL APP海量FEED LOG实时质量统计CASE(含percentile_disc) - 含rotate 分区表》
- 《PostgreSQL 数据rotate用法介绍 - 按时间覆盖历史数据》
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 管理复杂度增加, 而且容易踩到坑(前面说了)
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面支持rotate表功能.
- 可以设置记录的存活时间、记录数据上限、空间占用上限等维度
- 希望存储结构和清理机制可以避免WAL的产生与膨胀问题.
- 例如以分片形式存储和清理.
- 同时希望有抽稀的能力, 例如明细保留7天, 7天以前的按分钟统计稀疏保留. 这种通常出现在一些监控或金融、IOT等dashboard类场景.
