ClickHouse 對決 Elasticsearch：50 億筆日誌的儲存與查詢效能實測
ClickHouse Blog · 2026-04-23
ClickHouse 於 2026 年 4 月 23 日發布一份大規模日誌分析基準測試，以 OpenTelemetry 格式的日誌資料集（1B、10B、50B 行）直接比較 ClickHouse 與 Elasticsearch 的儲存效率與查詢效能。這份報告針對目前日誌分析領域最常見的選型疑問提供了量化依據。
架構差異
兩者的根本差異在於索引策略。Elasticsearch 為每個欄位建立倒排索引（inverted index），並在 _source（原始 JSON）與 doc_values（欄位索引）之間維護雙份資料；ClickHouse 則採用稀疏主鍵索引（sparse primary index），索引大小從 1B 行的 6.47 MiB 到 50B 行的 320.56 MiB，遠低於 Elasticsearch 的全欄位索引。ClickHouse 的查詢引擎為向量化執行（vectorized execution），搜尋結果直接餵入聚合管線，不需跨系統跳轉。
儲存壓縮
ClickHouse 使用鏈式專用與通用編碼器（lz4、zstd、delta、gcd），在 1B 行資料集上達到 16.33× 整體壓縮比。以下是跨規模的原始對比：
| 資料集規模 | ClickHouse | Elasticsearch | 比例 |
|---|---|---|---|
| 1B 行 | 49.49 GiB | 245.06 GiB | 4.95× 少 |
| 10B 行 | 496.84 GiB | 2.40 TiB | 4.95× 少 |
| 50B 行 | 2.43 TiB | 12.01 TiB | 4.95× 少 |
就欄位索引部分（排除 Body 大文字欄位後），ClickHouse 欄位檔案在 1B 行的體積（39.33 GiB）仍比 Elasticsearch 的 doc_values（102.49 GiB）少 2.61 倍，且前者含全部欄位，後者已排除 Body。
查詢效能
冷查詢（資料從磁碟載入）在各規模的平均加速比為 4～6 倍；熱查詢（有快取）縮小至 1.7～2.6 倍。優勢在組合查詢（搜尋 + 聚合）上最為顯著：
| 規模 | ClickHouse 冷查詢 | Elasticsearch 冷查詢 | 加速比 |
|---|---|---|---|
| 1B | 1.54 s | 9.55 s | 6.20× |
| 10B | 7.41 s | 30.6 s | 4.13× |
| 50B | 26.2 s | 111.4 s | 4.25× |
趨勢分析查詢（Q8–Q9）與服務分組查詢（Q6–Q7）在大規模資料集上差距最大，因為這類查詢在全文匹配後需要大量下游聚合計算，正好是 ClickHouse 向量化引擎的強項。Elasticsearch 的下游聚合則需額外跨層傳遞。
寫入效能方面，50B 筆 OpenTelemetry 日誌的載入時間 ClickHouse 不到 4 小時，Elasticsearch 則需數日。
原始來源：ClickHouse Blog – Do you still need Elasticsearch for log analytics?
ClickHouse Cloud 索引分片：把 PB 級索引分散到整個副本群
ClickHouse Blog · 2026-04-21
ClickHouse Cloud 近期推出索引分片（Index Sharding）功能，解決 PB 級資料表在多副本叢集中因索引記憶體線性膨脹而造成的效能瓶頸。此功能於 2026 年 4 月 21 日正式公開說明。
問題根源
在傳統架構下，每個副本（replica）都需將完整的主鍵索引（primary key index）載入記憶體。一張 100 GB 的主鍵索引，若叢集有 12 個副本，則整個叢集總計消耗 1.2 TB 的冗餘索引記憶體——這些記憶體本可用於查詢處理。隨著副本數線性增加，冗餘量同步成長，成為 PB 規模下的關鍵限制。
架構機制
索引分片的核心思想是：「把索引分析工作分散到所有副本，每個副本只持有索引的一個分片（slice），整個副本群合起來覆蓋全部索引。」當查詢抵達時，發起節點（initiator）使用一致性雜湊（consistent hashing）將索引分析任務分派給各副本，各副本分析自己負責的資料分區（parts），回傳匹配的 granule 範圍，發起節點再合併結果。整個過程中沒有任何單一節點需要載入完整索引。
效能測試
測試環境：50 億行資料表、17,000 個 parts、10 個副本。各索引類型的加速倍數如下：
| 查詢類型 | 原始延遲 | 分片後延遲 | 加速比 |
|---|---|---|---|
| 主鍵範圍查詢 | 1.0 s | 0.23 s | 4.3× |
| Bloom Filter 查找 | 8.5 s | 1.1 s | 7.7× |
| 向量搜尋 | 6.5 s | 0.9 s | 7.2× |
| 全文索引搜尋 | 3.1 s | 0.53 s | 5.8× |
將副本從 10 增加到 20，可獲得額外 1.4～1.7 倍的提升，顯示分片機制能隨副本數水平擴展。記憶體消耗從「副本數 × 索引大小」的線性模型，轉為整個叢集總記憶體等於索引大小本身的常數模型，從根本上改變了規模擴張的成本結構。
PostgreSQL 新型 Table Access Method：storage_engine 1.0.7 帶來欄位壓縮與行批次壓縮
PostgreSQL News Archive · 2026-04-23
storage_engine 1.0.7 是一個 PostgreSQL 擴充套件，提供兩種高效能 Table Access Method（TAM），適用於 PostgreSQL 16、17 及 18，針對分析（OLAP）與混合事務/分析（HTAP）工作負載設計。
兩種 Access Method
colcompress（欄位導向壓縮儲存）採用欄位儲存格式，支援向量化執行、Chunk 層級 min/max 剪枝（pruning）、平行掃描，以及類似 MergeTree 的排序順序。rowcompress（行導向批次壓縮儲存）則以行為單位進行批次壓縮，支援平行掃描、透過刪除位元遮罩（deleted bitmasks）實作的 DELETE/UPDATE，以及 LRU 解壓縮快取。
效能基準
在 PostgreSQL 18、100 萬行資料的串列執行測試中：
- 聚合查詢：最高比標準 heap 快 10 倍
- 壓縮後體積：比標準 heap 小 3～5 倍
- GIN 索引與 JSONB 查詢：完整支援
PostgreSQL 的 Table Access Method API 自 13 版引入，允許第三方套件替換預設的 heap 儲存引擎，但直至近幾年才陸續出現具備欄位儲存能力的實作。storage_engine 的 colcompress 採用 MergeTree 風格的排序，讓稀疏索引掃描能在欄位格式下發揮效力；rowcompress 則在保留行格式相容性的同時，透過批次壓縮降低 I/O 放大。