【DB吐槽大會】第56期 - PG 分析場景IO消耗較大, 計算有巨大性能提升空間

背景

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份, 既存儲行又存儲列存儲

• • 可選同步還是異步合并到列存儲

• • • 同步合并, 事務結束時等待列存儲資料合并完成
    • 異步合并, 行存儲日志持久化即可, 背景将資料合并到列存儲.

https://github.com/digoal/blog/blob/master/202109/20210928_08.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76