【DB吐槽大会】第1期——PG MVCC

简介: 大家好,这是DB吐槽大会,第1期 - PG MVCC

背景

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等引擎.

相关文章
|
关系型数据库 数据库 PostgreSQL
|
存储 SQL 固态存储
【DB吐槽大会】第2期 - PG 32位xid
大家好,这是DB吐槽大会,第2期 - PG 32位xid
|
SQL 存储 数据库
【DB吐槽大会】第10期 - 不支持 flashback query
大家好,这里是DB吐槽大会,第10期 - 不支持 flashback query
|
SQL 存储 关系型数据库
【DB吐槽大会】第17期 - PG 不支持online DDL
大家好,这里是DB吐槽大会,第17期 - PG 不支持online DDL
|
容灾 关系型数据库 数据库
【DB吐槽大会】第24期 - PG 不支持Partial PITR
大家好,这里是DB吐槽大会,第24期 - PG 不支持Partial PITR
|
SQL Oracle 关系型数据库
【DB吐槽大会】第65期 - PG 没有内置进程池
大家好,这里是DB吐槽大会,第65期 - PG 没有内置进程池
|
存储 JSON Oracle
【DB吐槽大会】第15期 - PG 没有全局临时表
大家好,这里是DB吐槽大会,第15期 - PG 没有全局临时表
|
存储 缓存 关系型数据库
【DB吐槽大会】第6期 - PG Double Cache
大家好,这里是DB吐槽大会,第6期 - PG Double Cache
|
关系型数据库 数据库 索引
【DB吐槽大会】第32期 - PG 没有全局索引
大家好,这里是DB吐槽大会,第32期 - PG 没有全局索引
|
SQL 算法 关系型数据库
【DB吐槽大会】第21期 - PG 没有持久化Shared Buffer
大家好,这里是DB吐槽大会,第21期 - PG 没有持久化Shared Buffer