背景
1、产品的问题点
MVCC, 旧版本与新版本在同类文件中.
垃圾回收不及时将导致:
数据文件膨胀.
如果新行不在同一个page内, 则发生了行迁移, 那么即使index字段的值没有变化, INDEX指向也需要变化, 导致index IO, 以及index膨胀.
2、问题点背后涉及的技术原理
解决并发事务读到的tuple版本可能不同的需求.
有的产品会使用专门的undo来存储历史版本.
3、这个问题将影响哪些行业以及业务场景
高频更新, 高频插入+删除的场景.
例如传感器的最新值更新, 出租车的位置更新, 配送员的位置更新, 游戏账号的实时更新等场景.
当然不是说有更新就一定有膨胀问题, 而是垃圾回收不及时会产生膨胀问题. 那么什么时候可能垃圾回收不及时呢?
- 因为有未结束的2pc, 有未结束的事务, 有执行中的query, 这些query或事务可能是long long ago就开在那的. 这些已删除的老版本可能是在这些事务之后被删除的, 可能还要被访问到. 所以autovacuum不能清除它们.
- 或者 autovacuum回收太慢(比如你花钱雇了个工人, 但是他在休息.)
- 或者 autovacuum回收时index被扫描了若干遍. 《PostgreSQL 垃圾回收参数优化之 - maintenance_work_mem , autovacuum_work_mem》
- 或者 磁盘性能太烂
- 或者 autovacuum worker数量太少
4、会导致什么问题?
膨胀后存储空间增加、IO的范围增加、内存消耗增加. 性能下降.
5、业务上应该如何避免这个坑
- snapshot too old参数配置.
- 设置参数, 不让autovacuum休息或者少休息.
- 设置参数或监控, 别产生长事务, 2pc, long long ago query.
- 调大存放临时dead tuple head的内存, 别让一次垃圾回收过程收集的dead tuple head存储超过内存maintenance_work_mem or autovacuum_work_mem
- 分区, 同样也是解决上面这个问题.
- 使用IO延迟较小的ssd.
6、业务上避免这个坑牺牲了什么, 会不会引入新的问题
需要IO延迟更低的硬盘.
需要牺牲长事务.
需要增加监控项, 发生膨胀后需要vacuum full或在线repack, 增加了维护成本.
7、数据库未来产品迭代如何修复这个坑
基于undo的存储引擎. 例如zheap, zedstore等引擎.
