【重新發現PostgreSQL之美】- 46 既要又要還要

背景

場景:

• 實時分析行業SaaS, 低代碼場景滿足客戶個性化分析的訴求.
• 單個使用者的資料總量T級别.
• 業務資料需要實時寫入.
• 使用者分析師拖拽式試錯, 産生合理的分析模闆. 結果則需要實時高并發查詢(例如為不通屬性使用者定制的動态頁面, 需要實時識别使用者的屬性(即分析結果)), 結果還有二次分析訴求.

挑戰:

• 既要又要還要:

• • 使用者拖拽式試錯, 需要實時分析計算能力.
  • 分析架構固定後, 需要實時查詢, 結果有高并發訴求.
  • 業務資料實時寫入, 用業務+大資料庫成本高, 同步延遲高、一緻性等問題突出.
  • 單個使用者的資料總量T級别, 不大不小. 用大資料成本高.
  • 如果拖拽後的固定結果使用普通視圖, 那麼它隻是SQL語句, 不存儲結果資料, 也無法支援索引, 查詢視圖時耗費計算, 效率低, 無法支援高并發.
  • 如果存儲結果, 那麼對于采用邏輯複制的資料庫, 需要等事務結束用戶端才能apply事務, 隻讀執行個體延遲高. 物化視圖重新整理是大事務, 是以這種場景無法通過隻讀執行個體擴充性能.

PG解決方案:

• 并行計算+JIT滿足TB級别拖拽式實時分析需求.
• 物化視圖, 已經算好, 查詢效率高.
• 支援在物化視圖上建立索引, 效率高.
• 定時任務增量重新整理物化視圖, 可以反映基表變更實時資訊.
• 流複制隻讀執行個體, 流式複制, 不需要等事務結束, 解決隻讀執行個體延遲高問題.
• 支援物化視圖與基表采用不一緻的存儲引擎, 例如基表要高并發dml使用行存儲, 物化視圖如果要大量二次分析可以使用列存儲. 使得可以适合最好的效率.

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