背景

1、产品的问题点

• PG 分析场景IO消耗较大, 计算有巨大性能提升空间

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

• PG 内置的存储引擎为heap引擎, 行存储模式. 行存模式适合OLTP类业务, 点查、更新等效率高.
• 即使只统计某列的数据也要扫描整行(不访问toast时除外, 不过分析统计通常都是定长类型, 不会存储到toast里面去).
• 行存模式下无法使用CPU批量计算的特性(向量化) , vops是改过的向量化引擎, 采用瓦片式存储(一个瓦片N个值(类似数组), 从而实现向量化计算)

• • 《PostgreSQL VOPS 向量计算 + DBLINK异步并行 - 单实例 10亿 聚合计算跑进2秒》
  • 《PostgreSQL 向量化执行插件(瓦片式实现-vops) 10x提速OLAP》

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

• HTAP业务, 带分析需求的业务.

4、会导致什么问题?

• 导致IO浪费,
• 导致存储空间浪费(行存的压缩比较低),
• 同时无法有效利用CPU的批量计算特性, 性能有巨大提升空间

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

• 可以安装一些外部的列存插件, 例如citus. zedstore.
• 将需要分析的数据转换为列存储(通常时间比较久远的日志表可能分析需求多于点查需求, 可以考虑改成列存储)

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

• 外部插件的稳定性、代码质量、持续性无法保障.
• 无法自动完成行列转换

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

• 希望内核支持列存引擎.
• 希望内核支持更加自动化的行存和列存管理

• • 可选存储1份还是2份数据

• • • 1份, 指定列存储或行存储
    • 2份, 既存储行又存储列存储

• • 可选同步还是异步合并到列存储

• • • 同步合并, 事务结束时等待列存储数据合并完成
    • 异步合并, 行存储日志持久化即可, 后台将数据合并到列存储.