德哥邀你鞭策数据库第1期 - PG MVCC

digoal2024年04月23日约 3 分钟

文中参考文档在github需点击阅读原文打开, 同时推荐2个学习环境:

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity

关注公众号, 持续发布PostgreSQL、PolarDB、DuckDB等相关文章.

拉上兄弟和闺蜜来参加现场鞭策：

第一期视频回放地址: https://www.bilibili.com/video/BV1Rv411N7Lt/

1、产品的问题点
MVCC, 旧版本与新版本在同类文件中.
垃圾回收不及时将导致:
数据文件膨胀.
如果新行不在同一个page内, 则发生了行迁移, 那么即使index字段的值没有变化, INDEX指向也需要变化, 导致index IO, 以及index膨胀.

2、问题点背后涉及的技术原理
解决并发事务读到的tuple版本可能不同的需求.
有的产品会使用专门的undo来存储历史版本.

3、这个问题将影响哪些行业以及业务场景
高频更新, 高频插入+删除的场景.
例如传感器的最新值更新, 出租车的位置更新, 配送员的位置更新, 游戏账号的实时更新等场景.
当然不是说有更新就一定有膨胀问题, 而是垃圾回收不及时会产生膨胀问题. 那么什么时候可能垃圾回收不及时呢?

《如何使用5why分析法发现数据库膨胀现象背后的本质?》

因为有未结束的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等引擎.

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:

文章中的参考文档请点击阅读原文获得.