【DB吐槽大会】第13期 - PG 膨胀收缩之痛

背景

1、产品的问题点

• 当表膨胀后普通的vacuum 无法回收已经占用的磁盘空间, (仅末尾空块可从磁盘回收).
• 使用pg_repack或vacuum full(要锁全表, 影响业务)回收磁盘占用的空间都需要额外的磁盘来临时存储重组后的数据.

2、问题点背后涉及的技术原理

• 普通的vacuum只能truncate数据文件末尾的空block, 所以我们可以将末尾的tuple移动到前面, 从而从磁盘回收末尾的block.
• 为什么只能truncate数据文件末尾的空block?

• 因为非末尾的block被清掉之后寻址会发生变化, 例如第二个数据块回收掉, 那么2号数据块后面的数据块的编号都需要减1, 而索引的ctid指向的是原来的编号, 因此会导致索引不准确. 当然, 我们可以增加1个bitmap文件存储真空块(已回收的中间blockid, 寻址时通过这个数据再进行block定位), 但是会增加寻址的复杂度, 性能可能下降.

3、这个问题将影响哪些行业以及业务场景

• 频繁更新的业务
• 《DB吐槽大会,第1期 - PG MVCC》

4、会导致什么问题?

• 如果你的环境已经拮据到无法提供额外的磁盘空间来存放整理后的数据, 那么将无法实施回收操作.

5、业务上应该如何避免这个坑

• 《PostgreSQL 通过行迁移 无需额外空间 回收垃圾膨胀磁盘空间》

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 维护成本较高, 一般用户不懂.

7、数据库未来产品迭代如何修复这个坑

• 希望内核层支持行迁移功能.
• 希望内核层支持在线收缩表空间功能: pg_repack.
• 希望尽量避免膨胀.