分析型資料庫一定要多叢集？EDB WarehousePG 有不同做法

EDB 產品資訊 PostgreSQL 產品資訊 2026 年 3 月 3 日

在雲端資料倉儲的用量計價模式下，高併發 BI 查詢容易讓成本快速累積，每次儀表板刷新或查詢都會增加支出。

隨著資料量與使用者需求成長，傳統多叢集架構在管理與效能優化上挑戰加大，分析團隊往往花更多時間控管成本，而非專注於提供洞察。

為何 BI 工作負載擴展方式不同？

雲端資料倉儲是為了處理大規模資料工程與排程分析而設計，目的是在執行批次 ETL 或機器學習任務時能有效利用資源。用量計價的模式可以讓系統在任務執行時使用資源，完成後自動釋放，降低不必要的成本。

商業智慧（BI）系統的使用節奏

BI 與傳統排程分析不同。業務人員全天刷新儀表板、資料科學家執行探索性查詢、財務分析師生成報表，AI agent 也同時提供對話式分析。這種同時操作的模式對系統資源與效能管理帶來極大挑戰。

不同平台在處理高併發 BI 使用者時的資源分配方式差異很大：有些平台會啟動多個叢集，有些只需要少量叢集；排隊時間可能從瞬間到 30 秒以上；查詢失敗率最高可達 4%。

即便是相同工作負載，成本也可能因自動擴展方式不同而差異高達 73%。這些都顯示，高併發 BI 的架構設計對成本與效能影響非常明顯。

併發對 AI 世代的重要性

BI 不只來自人類使用者，AI agent 也會自動查詢資料庫，增加更多併發負載。

每個 AI agent 像超級使用者，數秒內執行數百筆查詢，並根據結果決定是否發出更多查詢。即便資料倉儲能跟上，高併發 BI 也會讓成本迅速飆升，迫使分析團隊將時間花在控管資源，而非專注於產出洞察。

架構為何影響高併發工作負載？

雲端資料倉儲原本針對間歇性任務設計，能在突發需求時快速擴充運算資源，任務完成後再自動釋放。這對批次 ETL、機器學習訓練或週期性分析非常適合，彈性架構與用量計價相輔相成。

但高併發 BI 工作負載並非突發，而是可預測的持續需求。即便有 AI agent 參與，整體查詢模式仍高度可預測：你大致知道上班時間內有多少分析師與 agent 同時查詢資料。

問題在於：當為突發負載設計的平台遇到可預測的高併發查詢時，成本反而難以控制。使用者越多，啟動的叢集越多，帳單越高，即便實際使用模式沒有改變。

簡單來說：彈性架構會帶來彈性成本，而非彈性的工作負載反而造成錯配。

Postgres 替代方案：可預測的效能與成本

Postgres 為基礎的資料倉儲採取了完全不同的方法。基於 MPP（Massively Parallel Processing）大規模平行處理架構，經過數十年驗證技術，可以在不需要多叢集協調的情況下處理高併發工作負載。

圖 1：MPP 架構透過將資料列與運算分散到多個獨立的 segment 主機上來擴展效能

Segment 協調器會建立最佳執行計畫，指示每個 segment 如何並行處理其專屬的資料區塊（例如 16 個 segment 各自處理 16M 列資料表中的 1M 列）。

獨立基準測試顯示這種方法效果非常顯著。初步結果指出，Postgres 架構在高併發、高容量分析工作負載下可節省成本高達 62%，在併發擴展效率上比主流雲端資料倉儲高出 63%，同時維持可預測的成本結構與一致的使用者體驗。完整基準結果將在未來幾週公開。

對於關鍵業務操作來說，穩定性至關重要。MNTN，一個管理 PB 級資料的領先連網電視廣告技術平台，多年來一直使用 Postgres 資料倉儲。他們對效能一直滿意，但需要一個開源替代方案以及企業夥伴，來保證營運不中斷並提供快速支援。EDB Postgres AI for WarehousePG 就是他們的解決方案。MNTN 的資料主管 Greg Spiegelberg 表示：「效能穩定，系統可靠，支援快速，正如應有的。我很安心，即使半夜遇到問題，也有人能協助我，不必自己手動修改開源程式碼來恢復資料庫。」

EDB WarehousePG：單叢集處理高併發 BI

當你掌握每天的儀表板刷新、定期報表週期以及分析師查詢模式時，高併發 BI 工作負載其實是可預測的，無需冒高風險去更換基礎架構。

差異在於可預測性：

用量型平台（Consumption-based）：針對突發、不可預測的負載優化，你按使用量付費，但「實際使用量」會受到隱藏變數影響，例如平台自動擴縮的積極程度、叢集保持活躍的時間、查詢是排隊還是立即執行，以及為應對併發需求啟動了多少叢集。
容量型平台（Capacity-based）：針對已知負載優化，你根據併發需求配置運算核心，無論執行 1,000 筆還是 100,000 筆查詢，成本都保持固定。當平台需要啟動 3~5 個額外叢集應對高峰併發時，容量型成本不受影響。

對大多數已建立 BI 工作負載的企業而言，可預測性往往比彈性更重要。

轉換到容量型平台不代表必須拆掉現有架構。WarehousePG 基於 Postgres，團隊可立即使用熟悉的 SQL 技能。對於已在使用 Greenplum 的組織，轉換只需簡單的二進位替換（binary swap），可在數小時內完成，而非數月。

歐洲泛歐市場基礎設施 Euronext FX 就採用了這種轉換，藉此避免被既有 Greenplum 供應商綁定。Euronext FX 全球 CTO Grigoriy Zeleniy 表示：「我們很高興能與 EDB Postgres AI 合作。它對 Greenplum 工作負載的支援，讓我們能掌控開源軟體的部署位置與方式。」WarehousePG 提供了無縫二進位替換，並在四個全球資料中心提供卓越企業支援與開源控制。

在 GDPR、資料存放地要求以及日益嚴格的法規監管下，這種掌控力非常重要。組織必須確切知道資料存放位置與存取權限，同時不犧牲效能與可預測性。

除了成本可預測性，WarehousePG 的 MPP 架構可處理大量報表與高併發 BI，並透過工作負載管理優先處理關鍵查詢。內建向量化功能（pgvector）支援 AI 特徵工程與模型訓練，可直接在資料上操作，不需將資料移到其他基礎架構。即時資料流（streaming ingestion）支援即時日誌與事件分析，跨資料湖的聯邦查詢打破資料孤島，無需複雜 ETL 流程。

推薦閲讀：EDB Postgres 向量搜尋怎麼做？核心技巧公開