【DB吐槽大会】第29期 - PG 表空间容易达到文件系统天花板

背景

1、产品的问题点

• PG 表空间容易达到文件系统天花板

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

• PG的表空间创建在文件系统之上, 每个表空间对应1个目录. 表空间的大小取决于文件系统的大小.
• 数据库中占用空间较大的table、index存放在表空间内, 最小粒度为分区粒度.

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

• 通用

4、会导致什么问题?

• 表空间使用率监控比较复杂, 需要监控表空间目录占用空间, 同时需要监控文件系统剩余空间.

• 比较难做计划, 因为文件系统可能被表空间以外的其他文件占用.

• 文件系统使用率达到上限后, 这个表空间也将达到上限, 需要通过挪动表、索引(move tablespace)或者扩展底层文件系统来增加剩余空间.
• 如果服务器的存储由很多块盘组成, 要利用所有的存储空间, 需要为每块盘创建一个文件系统, 对应1个表空间.
• 扩展底层文件系统涉及到增加块设备, 文件系统的resize. 管理比较复杂
• 大表可能超过文件系统的大小, 只能通过分区+多个文件系统(多个表空间)解决.

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

• 在块设备和文件系统之间加一层卷管理系统, 例如 lvm , zfs(zpool)
• 每个盘对应一个表空间, 提前规划好表空间的使用

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

• 每个盘对应1个表空间, 意味着1个表只能存储在1个盘上, 没有充分利用多个块设备的并行带宽.
• 使用lvm或zfs增加了管理复杂度, 在线扩展受限于块设备、卷管理、文件系统是否支持online resize/extend.
• 使用lvm或zfs可以采用条带形式组织多个块设备, 但是增加了一个管理层, 增加了复杂度, 而且并行的带宽会有一定的损耗.

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

• 在表空间和文件系统之间, 增加一层数据文件, 在数据文件内重新组织数据和表(索引)的映射关系.

• 类似于Oracle, 但是这个方法也有问题, 例如数据文件的水位问题, 会导致空间浪费, 对于一个机器跑多个实例会造成较大的磁盘浪费. 适合比较固定的业务.

• 其他方法.