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