2026-09-09 — ClickHouse 公布 CostBench 端對端持續負載測試,並推出 pg_chdb 加速雲端儲存匯入 Postgres

CostBench 首波端對端測試出爐:持續寫入負載下 ClickHouse Cloud 效能/每美元優勢達 412 至 1,996 倍

clickhouse.com · 2026-09-08

背景:查詢端測試低估了持續寫入的真實成本

ClickHouse 於 2026 年 9 月 8 日發布 CostBench 基準測試的首波端對端(end-to-end)結果,涵蓋資料寫入、維護查詢就緒層到執行查詢的完整路徑。此前僅比較查詢端(query-side)成本效益的測試,顯示對照系統比 ClickHouse 差 32 至 101 倍,但這類測試建立在資料已預先寫入完成的靜態資料集之上,排除了持續寫入所需的維護成本。CostBench 改用持續負載(continuous load)模式,讓寫入與查詢同時進行,藉此還原即時分析場景下的真實成本結構。

測試方法:113.2 億筆美股報價、每秒 100 萬列的持續灌入

基準測試以單一 AWS EC2 m6i.8xlarge 執行個體作為統一寫入用戶端,對 ClickHouse Cloud、Snowflake、BigQuery 與 Redshift Serverless 四套系統送出相同的資料流,僅替換各平台的寫入介面(destination adapter),其餘來源解碼、速率控制與查詢排程邏輯完全一致。資料集為 National Best Bid and Offer(NBBO)美股報價,共 113.2 億列、12 欄位窄表,以每秒 100 萬列的目標速率持續寫入,主動寫入時間長達約 31.4 小時。事件層資料以 (sym, t)(股票代號、時間戳)排序,預聚合層則改以 (sym, day) 為鍵。

測試期間,四套系統必須同時完成以下三項工作:

• 將持續到達的新資料寫入欄式儲存
• 維持有利於查詢裁剪(pruning)的實體佈局,例如排序與分群
• 隨新資料到達即時更新每日預聚合結果

查詢工作負載與計分公式

查詢分兩類:互動式聚合查詢 A1–A4 讀取已維護的每日預聚合結果,分別為單一股票歷史總覽、八檔股票觀察清單、歷史價格區間排行,以及每 10 分鐘執行一次的全市場活動統計;選擇性下鑽查詢 D1–D2 則直接讀取事件層資料,包含每小時 OHLCV K 線(含 VWAP、波動率、價差、報價筆數)以及每小時執行一次的單列風險與流動性指標。所有查詢都涵蓋當下已寫入的完整歷史,沒有截止日期限制,藉此模擬資料量持續成長下的查詢行為。

效能/每美元分數的計算方式如下:

score = (fresh-data-path cost + normalized query-serving cost) × total query runtime

其中新鮮資料路徑成本(fresh-data-path cost)包含完整寫入成本,加上事件層與預聚合層的維護成本;查詢服務成本(query-serving cost)以累積執行時間乘上讀取端運算單價正規化,消除各平台計費週期差異;總查詢執行時間則是主動寫入期間累積的端對端執行時間。分數越低代表效能/每美元表現越好。

效能數據:成本差距從查詢端 32–101 倍擴大到端對端 412–1,996 倍

加入完整新鮮資料路徑後,ClickHouse Cloud 在三項指標——新鮮資料路徑成本、查詢服務成本、累積執行時間——均為四套系統中最低。三個對照系統的端對端效能/每美元比 ClickHouse Cloud 差 412 至 1,996 倍,相較先前僅比較查詢端時的 32–101 倍差距明顯擴大。ClickHouse 指出,這是因為在測試系統中,只有 ClickHouse Cloud 能在持續寫入期間同時保持事件層與預聚合資料的即時更新,降低了查詢引擎本身需要承擔的運算量。

ClickHouse 說明,由於測試時長有限,資料庫儲存成本佔比極小,因此計分公式中將其排除,只計入新鮮資料路徑成本與查詢服務成本。完整基準定義、通過驗證的執行紀錄、成本明細與重現步驟已公開在 CostBench 儲存庫,包含各項查詢的具體檔案。

原始來源:ClickHouse Blog、CostBench GitHub

ClickHouse 推出 pg_chdb:以隨需啟動的嵌入式引擎加速 Postgres 雲端儲存匯入匯出

clickhouse.com · 2026-09-08

背景:既有跨雲匯入方案的取捨

ClickHouse 於 2026 年 9 月 8 日發布 chdb Postgres 擴充套件(pg_chdb),已在 PGXN 上架,讓 Postgres 能直接對 S3、GCS、Azure Blob Storage、HDFS 等雲端儲存進行匯入匯出。ClickHouse 指出既有方案各有取捨:`aws_s3` 擴充套件格式支援有限,僅支援 Postgres COPY 原生可處理的格式;`pg_duckdb` 把完整的 DuckDB 引擎直接編譯進 Postgres 後端行程,較為佔用資源;`pg_lake` 則需要在 Postgres 主機上另外常駐一個服務。`chdb` 使用 chDB 函式庫——一個 in-process 的 ClickHouse 引擎——作為底層執行核心。

架構設計:隨需啟動、用完即丟的 helper 行程

與 `pg_duckdb` 把引擎直接嵌入後端行程不同,`pg_chdb` 將 chDB 函式庫嵌入一支獨立的 helper 應用程式,依需要才啟動,並透過檔案描述符——`STDIN`、`STDOUT`、`STDERR`,外加一支專門傳遞設定資訊的描述符——與 Postgres 後端溝通。當 helper 行程執行完命令、把結果以 ClickHouse Native 格式直接傳給後端後,便會清理資源並結束,不會像常駐式引擎那樣持續佔用後端行程記憶體。

目前提供三種匯入路徑:

-- 1. 以函式直接查詢
SELECT * FROM chdb_query($$
  SELECT * FROM s3('s3://datasets-documentation/my-test-bucket-768/some_prefix/some_file_1.csv');
$$) AS (id int, months int, days int);

-- 2. 以 COPY 觸發 chdb_hook
COPY times FROM 's3://datasets-documentation/my-test-bucket-768/some_prefix/some_file_1.csv';

-- 3. 建表時自動載入(支援萬用字元)
CREATE TABLE reviews () WITH (
    copy_from = 's3://datasets-documentation/amazon_reviews/amazon_reviews_2015.snappy.parquet'
);

格式支援與效能:NYC Taxi 資料集實測

`chdb` 支援的格式遠多於既有方案,涵蓋 TSV、CSV、JSON、BSON、Prometheus、Protobuf、Avro、Parquet、Arrow、XML、CapnProto、Markdown、MsgPack、ORC 等,壓縮格式則支援 gzip、zstd、lz4、bz2、snappy、brotli。

效能測試以 NYC Taxi 資料集(1M rows,寬表)為對象,從 AWS S3 匯入,每項測試取三次執行的平均值。ClickHouse Managed Postgres 使用 r8id.xlarge(4 vCPU、32 GB RAM),`aws_s3` 因不支援 ClickHouse Managed Postgres,改在同規格的 db.r8g.xlarge AWS RDS 上測試。結果顯示 `chdb` 速度最快且表現最穩定,`pg_duckdb` 與 `pg_lake` 在 CSV、JSON、Parquet 匯入上耗時約為 `chdb` 的 2 至 3 倍;`aws_s3` 速度接近 `chdb`,但格式支援範圍窄得多。

後續規劃

ClickHouse 列出目前尚未涵蓋的項目,做為後續開發方向:

• 完整的型別對應(type mapping)
• 基於憑證鏈(credential chain)的存取控制
• COPY (query) TO 語法支援
• COPY 時的 WHERE 條件過濾
• 更多 COPY 選項
• Iceberg 格式支援
• 直接查詢檔案而不建表

原始來源:ClickHouse Blog、pg_chdb GitHub