pg_clickhouse 2026 年 4 月更新：JSONB 推下、SQL 值函式與 HTTP 串流
ClickHouse Blog · 2026-04-24
pg_clickhouse 是讓 PostgreSQL 能夠將查詢推送（pushdown）至 ClickHouse 執行的 FDW 擴充。v0.1.10 與 v0.2.0 兩版帶來 JSONB 存取運算子的推下支援、當前時間 SQL 值函式的轉譯，以及 HTTP 結果集串流，顯著降低大型查詢的 PostgreSQL 端記憶體用量。
JSONB 推下（v0.1.10）
擴充將 PostgreSQL JSONB 存取運算子轉換為 ClickHouse 的子欄位語法：
props ->> 'cid'（返回 text）→ ClickHouse 的props.cidprops -> 'key'（返回 JSONB）→ 使用toJSONString()進行比較jsonb_extract_path()與jsonb_extract_path_text()支援多層巢狀路徑存取
推下操作在 WHERE、ORDER BY、HAVING 子句中均有效。
SQL 值函式推下（v0.2.0）
當前日期/時間的 SQL 標準函式現在直接在 ClickHouse 端求值：
CURRENT_DATE→toDate(now(timezone))CURRENT_TIMESTAMP→now64(precision, timezone)clock_timestamp()、statement_timestamp()、transaction_timestamp()→nowInBlock64()
所有函式均遵守 PostgreSQL session 的時區設定。陣列函式也同步新增推下：array_cat()→arrayConcat()、array_to_string()→arrayStringConcat()、string_to_array()→splitByString()。
HTTP 結果集串流（v0.1.10）
預設緩衝區約 50 MB 每批次。以 NYC Taxi 資料集測試，v0.1.10 峰值記憶體為 601.8 MiB，v0.2.0 串流模式降至約 86 MiB（降幅 ~86%）。目前僅 HTTP driver 支援串流；binary driver 支援已列入計畫。
Redis 客戶端函式庫原生 OpenTelemetry 指標支援
Redis Blog · 2026-04-24
redis-py v7.3.0、go-redis v9.18.0 與 node-redis v5.12.0 同步發布原生 OpenTelemetry 指標整合，無需第三方 wrapper 即可將連線池狀態、命令延遲與錯誤計數輸出至標準 OTel pipeline。
指標分組與語義慣例
實作採用分組模型控制基數與效能影響。預設啟用 resiliency 與 connection-basic：
- resiliency：錯誤計數（redis.client.errors）、伺服器維護通知
- connection-basic：閒置/活躍連線數（db.client.connection.count）、連線建立時間
- connection-advanced（選用）：取得連線的等待時間、已關閉連線總數
- command（選用）：命令延遲（db.client.operation.duration），go-redis 預設啟用
- client-side-caching、pubsub、streaming（均為選用）
整合架構
客戶端函式庫掛載到進程層級的 OpenTelemetry SDK，不獨立實例化 provider，避免與應用程式自身的 OTel 配置衝突。Python 範例：
pip install redis[opentelemetry]
from redis import Redis
# 自動使用進程層級的 OTel provider
client = Redis()效能開銷
go-redis 預設設定下開銷 <0.2%；redis-py 預設約 0.5%，啟用命令延遲指標升至 7–8%（選用）；node-redis 在事件迴圈正常時可忽略，飽和時有所放大。所有函式庫預設停用，停用時無可量測開銷。
原始來源：Native OTel Metrics for Redis Client Libraries — Redis Blog
storage_engine 1.0.7：為 PostgreSQL 16–18 帶來欄式與列壓縮表存取方法
postgresql.org · 2026-04-23
storage_engine 1.0.7 為 PostgreSQL 16 至 18 提供兩種新的 Table Access Method（TAM）：欄式儲存（columnar）與列壓縮儲存（row-compressed），讓使用者在同一個 PostgreSQL 實例中按需選擇儲存格式。
Table Access Method 機制
PostgreSQL 的 TAM API（自 PG 12 引入）允許擴充程式替換表的底層儲存引擎，同時保留 SQL 語法、事務語義與複寫機制的相容性。storage_engine 利用此 API 實作欄式佈局（按欄連續儲存，利於聚合查詢）與列壓縮（以 LZ4 或 ZSTD 壓縮整列，利於 IoT / 日誌類寫入為主的工作負載）。
欄式儲存的查詢優化
欄式 TAM 在 SELECT sum(col), avg(col) 等只需存取特定欄位的查詢上，可跳過不相關欄位的 I/O。對於寬表（數十至數百欄），存取少數欄位的查詢掃描量可降低 80–90%。
版本支援
此版本涵蓋 PostgreSQL 16、17 與 18（目前 beta），擴大了早期版本 1.0.6 僅支援 PG 17 的限制，方便尚未升級的生產環境採用。
ClickHouse 取代 Elasticsearch 作為日誌分析引擎：2026 年架構比較
ClickHouse Blog · 2026-04-23
ClickHouse 工程師 Tom Schreiber 與 Lionel Palacin 發布針對日誌分析場景的架構比較，論述 ClickHouse 在哪些條件下可取代 Elasticsearch，以及遷移時需要關注的差異。
儲存效率差異
Elasticsearch 以倒排索引為核心，將每個欄位建立全文索引，對非結構化文字搜尋最佳化，但對數值型欄位（如 HTTP 狀態碼、duration_ms）的聚合查詢效率較低。ClickHouse 使用欄式儲存配合 MergeTree 排序鍵，在時序聚合查詢（如 P99 延遲、每分鐘錯誤率）的效能上有結構性優勢，且壓縮比通常高出 3–5 倍。
查詢模式適用性
Elasticsearch 在全文搜尋（BM25 相關性評分）與即時近似搜尋（approximate nearest neighbor via HNSW）上仍具優勢。ClickHouse 在大範圍時間視窗的聚合、JOIN 操作，以及資料回填（backfill）場景表現更佳。文章建議以「是否需要全文相關性排序」作為選型的主要判斷依據。
遷移考量
ECS（Elastic Common Schema）與 ClickHouse 的動態欄位之間無直接映射；日誌攝取管線（Logstash、Vector、Fluent Bit）均有 ClickHouse output plugin，但需要調整 schema 設計。ClickHouse 的 MATERIALIZED VIEW 可替代 Elasticsearch 的 ingest pipeline 進行資料轉換。
原始來源：ClickHouse vs Elasticsearch for Log Analytics — ClickHouse Blog