ClickHouse Managed Postgres 八月更新:儲存告警、Logs 視圖與 RE2 正規表示式擴充
ClickHouse Blog · 2026-08-06
ClickHouse 於 2026 年 8 月 6 日在官方部落格公布 Managed Postgres(ClickHouse Cloud 上代管的 PostgreSQL 服務)本月更新,內容涵蓋容量告警通知、可觀測性介面、備份效能與三個擴充套件。這次更新沒有調整核心版本號,而是針對既有服務疊加維運與擴充功能,目標是把原本要另外拉 Prometheus 或日誌工具才看得到的維運資訊,直接搬進主控台。
容量告警與備份
新版加入了儲存用量告警:當服務磁碟使用率達到 85% 時系統會發出通知,每個服務每個日曆日只會觸發一次,避免洗版;若使用率繼續攀升到 90%,服務會自動擴容,但擴容瞬間會有短暫的 cutover downtime。通知管道支援主控台收件匣、Email 與 Slack,可在雲端主控台的通知設定頁面依服務個別調整,未來規劃再加入 replica lag、uptime 與 failover 事件的通知。
備份效能方面,官方調整了現行 WAL-G 的設定,讓大型執行個體能吃滿更高的 CPU 與磁碟吞吐量,使 10 TB 以上的伺服器備份與還原時間變得可預期。部落格同時預告未來會以 Rust 重寫的 WAL-RUS 取代 WAL-G,目的是降低資源使用量,但目前這版仍是在既有 WAL-G 架構上做調校,尚未換底層實作。
可觀測性:Logs 視圖到 Prometheus 端點
主控台新增 Logs 視圖,可直接在瀏覽器內對 PostgreSQL 伺服器日誌做全文檢索,並按嚴重程度與時間範圍過濾,不必再另外接 log shipper。搭配既有的 Metrics 儀表板(CPU、記憶體、磁碟、IOPS、連線數與逐表儲存空間),使用者可以在同一個畫面比對資源用量與慢查詢。
對已經有自建監控的團隊,ClickHouse 開放了相容 OpenMetrics 格式的 /metrics Prometheus 端點,可以直接讓既有 Prometheus 抓取指標,不需要額外依賴主控台。另外也新增了 慢查詢模式 API,以 REST 介面回傳查詢摘要(call 次數、平均/總執行時間、處理列數),方便寫進自家的告警或報表管線。
三個 Postgres 擴充套件
這次一併更新的還有三個開源擴充套件,分別處理正規表示式效能、跨系統查詢與監控資料匯出。pg_re2 把 Google 的 RE2 函式庫包裝成 PostgreSQL 擴充(需要 PostgreSQL 13 以上),透過 CREATE EXTENSION re2; 安裝後即可用與 ClickHouse 相同語法的正規表示式函式,官方宣稱效能比 Postgres 原生正規表示式快上 9 倍。
- pg_re2:RE2 正規表示式引擎,語法與 ClickHouse 對齊,取代原生較慢的 regex 執行路徑。
- pg_clickhouse:Foreign Data Wrapper,讓 Postgres 可以直接查詢 ClickHouse 資料表;這次更新加入 pg_re2 函式下推、聚合函式下推,以及子查詢 join 下推優化,對 TPC-H 這類分析型 benchmark 有明顯幫助。
- pg_stat_ch:把 Postgres 的查詢模式資料送到 ClickHouse 做監控,這次改用 Apache Arrow 做批次傳輸、加入取樣支援,並把底層 client 從 clickhouse-cpp 換成 clickhouse-c API,同時補上 C++ 例外與訊號對應以避免異常中斷。
原始來源:ClickHouse Blog、pg_re2 GitHub、Managed Postgres Notifications 文件
ClickHouse 26.7:融合 GROUP BY 與 LIMIT 的查詢執行、JOIN 執行期剪枝與向量量化索引
ClickHouse Blog · 2026-08-06
ClickHouse 於 2026 年 8 月 6 日發布 26.7 版本,官方部落格列出 61 項新功能、112 項效能優化與 329 項錯誤修正。這篇筆記整理幾個牽涉查詢執行機制改動的重點:GROUP BY 與 LIMIT 的融合排序聚合、JOIN 的執行期剪枝、向量搜尋的量化索引,以及型別與引擎層的幾個變動。
GROUP BY … ORDER BY … LIMIT 的融合執行
26.7 把兩個既有優化接起來:optimize_aggregation_in_order 在分組鍵是資料表排序鍵前綴時,能以有序方式做聚合、省掉雜湊表;新加入的 optimize_aggregation_in_order_limit 則把查詢裡的 LIMIT 一路下推進這個有序聚合流水線,讓執行可以提早終止,不必掃完整張表。這個機制只在分組鍵確實對齊排序鍵前綴、且 ORDER BY 使用同樣欄位時才會生效。
SET optimize_aggregation_in_order = 1;
SET optimize_aggregation_in_order_limit = 1;JOIN 的執行期剪枝與雜湊表壓縮
JOIN 這次的改動分成兩塊。第一塊是執行期過濾剪枝:build 端(右表)建好雜湊表後產生的 runtime filter,會回頭用主鍵與 skip index 分析,在 probe 端(左表)讀資料前就先剔除不可能命中的 granule,需要開啟 enable_join_runtime_filters、enable_join_runtime_filters_index_analysis 與 use_skip_indexes_on_data_read 三個設定。第二塊是雜湊表列參照壓縮:所有 key 型別的列參照現在都改成 8 bytes 的緊湊索引值,先前這個優化只用在 ANY JOIN。此外還加入 DPsub 動態規劃演算法,可自動決定多表 JOIN 的執行順序,透過 query_plan_optimize_join_order_algorithm = 'dpsub' 開啟。
| 改動 | 效能提升 | 其他影響 |
|---|---|---|
| GROUP BY + LIMIT 融合 | 313 倍(2.814s → 0.009s) | 記憶體降 592 倍、掃描列數降 339 倍 |
| JOIN 執行期剪枝 | 6.2 倍(0.597s → 0.097s) | 掃描列數降 4.6 倍、記憶體降 8.8 倍 |
| 雜湊表列參照壓縮 | 中位數 12%(1–3 億列 JOIN) | UInt64 key INNER JOIN 快 21%、省 38% 記憶體 |
| 詞組全文檢索 | 40 倍(1.343s → 0.033s) | 尖峰記憶體從 280 MiB 降到 42 MiB |
向量搜尋的量化索引 QBit
QBit 這次新增了多種量化手段。Int8 量化把向量以 8 個位元平面儲存,讓查詢時能動態選擇要用 1 到 8 個位元參與比對,內部用 256 個針對高斯分布設計的非均勻分桶;QBit 型別新增第三個參數可做 strided storage,把向量維度切成可獨立讀取的群組,查詢時能同時減少讀取的位元數與維度數,I/O 大約只剩等效 Float32 資料量的 3%。另外還加入 randomHadamardTransform 做正交、保範數的隨機旋轉,讓量化前的資訊分布更均勻。
量化編碼(quantization codec)會在寫入時自動連帶存一份量化版本,查詢先用量化資料做近似篩選、再用全精度資料對候選結果重新排序,支援 int8、rabitq(1-bit)、turboquant(2-bit)、mrl、pq 幾種方法,其中 1-bit 編碼可以把索引體積壓到原本的 1/16。
CREATE TABLE vecs (
id UInt32,
v Array(BFloat16) CODEC(Quantized('rabitq', 384))
) ORDER BY (id);
SET vector_search_use_quantized_codes = 1;
SELECT id FROM vecs ORDER BY L2Distance(v, target) LIMIT 10;型別、引擎與 UDF driver
DateTime64 的可表示範圍從原本 1900–2299 年擴大到西元 0000 年到 9999 年,長時間跨度的歷史資料或時間序列不必再另外拆型別處理。新增的 Remote / RemoteSecure 資料表引擎可以把遠端 ClickHouse 叢集包成一張持久化的資料表定義,支援 host{1..3}:9000 這種叢集樣式與 TLS。url() 則統一成單一函式/引擎,依 URL scheme(S3、GCS、Azure、HDFS、HTTP、本機檔案)自動分派到對應的後端讀取邏輯。
另一個值得留意的機制變動是 Executable UDF Driver。過去 ClickHouse 只能使用固定、預先設定好的可執行檔當作 UDF;新的 driver 架構讓使用者能在 SQL 裡直接夾帶任意語言的程式碼片段,交由伺服器端設定的 driver 負責用 Docker、nsjail 或 gVisor 等機制安全執行——使用者提供的程式碼不可信,但 driver 本身屬於受信任的基礎設施。官方範例以 GVisorC driver 示範,設定檔宣告記憶體與 CPU 限制後,即可用 CREATE FUNCTION ... ENGINE = GVisorC() AS '...' 建立函式,目前這個機制屬於概念驗證性質,並非預設安裝項目。