背景
1、产品的问题点
- PG 分析场景IO消耗较大, 计算有巨大性能提升空间
2、问题点背后涉及的技术原理
- PG 内置的存储引擎为heap引擎, 行存储模式. 行存模式适合OLTP类业务, 点查、更新等效率高.
- 即使只统计某列的数据也要扫描整行(不访问toast时除外, 不过分析统计通常都是定长类型, 不会存储到toast里面去).
- 行存模式下无法使用CPU批量计算的特性(向量化) , vops是改过的向量化引擎, 采用瓦片式存储(一个瓦片N个值(类似数组), 从而实现向量化计算)
3、这个问题将影响哪些行业以及业务场景
- HTAP业务, 带分析需求的业务.
4、会导致什么问题?
- 导致IO浪费,
- 导致存储空间浪费(行存的压缩比较低),
- 同时无法有效利用CPU的批量计算特性, 性能有巨大提升空间
5、业务上应该如何避免这个坑
- 可以安装一些外部的列存插件, 例如citus. zedstore.
- 将需要分析的数据转换为列存储(通常时间比较久远的日志表可能分析需求多于点查需求, 可以考虑改成列存储)
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 外部插件的稳定性、代码质量、持续性无法保障.
- 无法自动完成行列转换
7、数据库未来产品迭代如何修复这个坑
- 希望内核支持列存引擎.
- 希望内核支持更加自动化的行存和列存管理
- 可选存储1份还是2份数据
- 1份, 指定列存储或行存储
- 2份, 既存储行又存储列存储
- 可选同步还是异步合并到列存储
- 同步合并, 事务结束时等待列存储数据合并完成
- 异步合并, 行存储日志持久化即可, 后台将数据合并到列存储.
