第27期吐槽:block size既大又小！谁把成年人惯成这样的？
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第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的数据库, 降低企业管理负担.
本期彩蛋-招商中,有需要的小伙伴可联系嵌入...
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: