【DB吐槽大会】第27期 - PG 单一 block size

背景

1、产品的问题点

• PG 仅支持单一 block size, 编译集群时指定, 后期无法改变, 而且软件和数据库数据文件的block size不同时, 无法启动.

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

• 数据库的数据存储在以block为单位组织的数据文件中, 每个block内存储tuple的内容, tuple通过itemid (line point)在block内进行内部寻址. 而外部寻址则通过block id进行.
• 当我们要寻找99号数据块第3条记录时, 即ctid=(99,3), 这条记录如果被索引引用, 假设block size=8KB, 那么在数据文件中即偏移对应的size即可定位到第99号数据块.
• 寻址相关代码都是写死的, 仅支持一个block size定义.

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

• TP 和 AP混合型业务.
• 企业内既有偏TP的业务也有偏AP的独立业务, 还有 append only 高速写入的场景, 例如时序, IOT

4、会导致什么问题?

• 使用同一实例管理ap+tp业务时, 无法达到最好的效率.

• TP业务的小事务, 访问数据块内的少量事务, 使用小的block size可以提高访问效率, 节省shared buffer内存.
• AP业务属于低并发的大事务, 需要访问更多片的数据, 通常大的block size可以提高压缩比, 提高大片数据的读写吞吐.

• 不同业务采用不同block size的实例管理, 会导致管理更加复杂, 每个实例需要搞清楚数据块大小, 并且使用对应的PG二进制来管理这个实例.

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

• 多套编译好的PG软件, 根据业务模型的需求, 选择不同的PG软件去初始化集群.

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

• 在企业中使用不同数据块大小的PG软件, 会导致管理成本增加.
• 在进行大版本升级时都要注意大小版本的二进制兼容性, 否则会导致升级不成功.

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

• 内核层支持多种BLOCK SIZE, 可以表级别进行设置, 满足混合业务需求. 一套二进制软件可以管理多种block size的数据库, 降低企业管理负担.