POSETTE 2026：PostgreSQL 效能不穩，問題常常出在儲存層
clickhouse.com · 2026-08-20
原本的問題
Sai Srirampur 在 POSETTE 2026 的議程上，分析了規模達到數百 GB 到 TB 等級的 PostgreSQL 部署常見的五種效能症狀：UPDATE/UPSERT 造成的緩慢寫入、P95 讀取延遲從毫秒級跳到秒級、autovacuum 追不上寫入速度、checkpoint 搶佔 I/O 造成延遲抖動，以及邏輯複製落後。他的核心論點是，這些看起來互不相關的問題，根源常常是同一個：儲存層太慢。
採用的方法
為了驗證這個論點，他架設了八組規格完全相同的 PostgreSQL 叢集，四組用本地 NVMe、四組用 EBS gp3，全部跑在 m6id.4xlarge（16 vCPU、64 GiB RAM、16 GiB shared_buffers）上。測試資料是 482 GiB 的 pgbench_accounts 表，共 33 億筆資料；負載是 64 個 client、16 條 worker thread 對隨機 aid 發出 UPDATE，持續跑 5 分鐘，EBS 端維持 baseline gp3 3,000 IOPS 的配置。
\set aid random(1, 3300000000)
UPDATE pgbench_accounts SET abalance = abalance + 1 WHERE aid = :aid;
實際效果
| 指標 | NVMe | EBS gp3 |
|---|---|---|
| TPS | 16,030 | 1,734 |
| 交易延遲中位數 | 4.0 ms | 36.9 ms |
| 頁面讀取延遲 | 0.3 ms | 19 ms |
| WAL fsync 延遲 | 1.5 ms | 11 ms |
| VACUUM（10 GB bloat） | 366 秒 | 964 秒 |
| 邏輯複製回補（10 GB） | 139 秒 | 238 秒 |
結果差距相當明顯：NVMe 的 TPS 是 EBS 的 9.24 倍，交易延遲中位數也從 36.9 ms 降到 4.0 ms。延遲拆解顯示，EBS 上光是頁面讀取就要 19 ms、WAL fsync 要 11 ms，換成 NVMe 後分別只剩 0.3 ms 與 1.5 ms，兩邊真正花在 CPU 運算的時間反而差不多（約 2 ms）。後端等待事件的統計也對得上：EBS 的 64 個連線裡有 29 個卡在 IO:DataFileRead（約 45%），NVMe 只有 9 個（約 14%）。
Srirampur 也提醒，改用本地 NVMe 不是沒有代價——沒有雲端儲存內建的複寫保護，必須自己補上。他建議搭配跨可用區的 quorum 式同步複製（例如 ANY 1 (standby1, standby2)）與 WAL-G 之類工具做 WAL 歸檔，並引用 Instacart、Datadog 作為採用這種架構的實例。
原始來源：ClickHouse Blog
Shopify 用一顆 ClickHouse 引擎，收攏全球規模的 observability 資料
clickhouse.com · 2026-08-20
原本的問題
Shopify 原本的 observability 基礎設施分散在多個供應商手上，metrics、logs、traces 各自獨立存放。這種架構帶來三個麻煩：成本隨基礎設施成長不成比例地暴衝、資料分散導致關聯不同訊號時得跨平台手動拼接、以及對供應商的產品路線圖失去主導權，直接牽動 production 維運工具的可用性。
採用的方法
Shopify 內部打造了一個叫 Observe 的統一平台，把 metrics、logs、traces、profiles、exceptions 全部收斂到同一個 ClickHouse engine 上。資料管線用 Kafka 做緩衝，再同步批次寫入確保資料不遺失；schema 設計上用 materialized view 追蹤欄位與值的分佈，把高頻使用的 key 從 Map(String, String) 提升成有型別的獨立欄位。
為了讓跨訊號查詢跑得動，他們另外做了一層 correlation 機制：一個把 trace ID 這類高價值識別碼跨資料集串起來的 materialized view，讓關聯查詢速度提升 10 倍。維運面則寫了一個自訂的 Kubernetes operator，用宣告式的方式管理 schema 變更與遷移，取代人工介入。
實際效果
| 指標 | 數值 |
|---|---|
| 穩定狀態攝入量 | 每秒 5,000 萬筆事件 |
| 黑五/網一尖峰攝入量 | 每秒 1 億筆（約 110 GB/s 未壓縮） |
| 查詢效能提升（開箱） | 16 倍 |
| 查詢效能提升（尖峰） | 30 倍以上 |
| 查詢延遲目標 | 60 秒以內 |
| 租戶數 | 約 20 個 |
| 硬碟空間節省（排序優化） | 20%–40% |
數字上看，系統在穩定狀態下每秒攝入 5,000 萬筆事件，黑色星期五到網路星期一的尖峰衝到每秒 1 億筆（未壓縮流量約 110 GB/s）。查詢效能相較舊架構「開箱即有 16 倍改善，尖峰時甚至衝到 30 倍以上」，所有查詢型態的延遲都被壓在 60 秒以內，目前平台上跑了約 20 個獨立租戶。
Shopify 也坦言，自建這套系統過程中學到很多維運經驗，但如果是現在才做同樣的決策，他們可能會直接選擇 ClickHouse Cloud 而非自架。
原始來源：ClickHouse Blog
DuckDB v2.0 換掉用了多年的 YACC/Bison Parser，改用 PEG
duckdb.org · 2026-08-20
背景
DuckDB 原本的 SQL parser 源自 PostgreSQL，用 YACC/Bison 這套工具產生 LALR(1) parser。隨著 DuckDB 自己的 SQL 方言 DuckSQL 不斷擴充，官方在 v2.0 的公告文章裡寫道：「看似很小的文法新增，可能會跟既有規則互相干擾，產生 shift/reduce 或 reduce/reduce 衝突」。文法規則彼此糾纏，讓每一次擴充都變得越來越難維護。
核心改動
v2.0 把整個 parser 換成基於 PEG（Parsing Expression Grammar）的實作。PEG 用「有序的替代選項」取代 LALR 的衝突判定機制，官方舉的例子是 SelectFrom <- SelectFromClause / FromSelectClause，/ 運算子會依序嘗試每一個選項，不會像 LALR 那樣產生衝突。
PEG 這種寫法本身可能導致指數級的回溯，官方因此引入 packrat parsing 技術，把已經解析過的結果記憶下來重複利用。官方給的實測例子是一條帶有 19 個不成對括號的查詢，舊 parser 要花 10.6 秒，新 parser 只要 0.001 秒。
影響範圍
新架構讓 extension 可以直接在執行期新增自己的文法規則，重複使用既有的 DuckDB 轉換邏輯，不必再像以前一樣自行實作一套 fallback parser。這次換 parser 也讓幾個新語法得以落地：
- 可以省略 SELECT 的 expression statement
- 用來連線遠端資料庫的 CONNECT 陳述式
- EXTERNAL RESOURCE 管理語法
- COPY TO 搭配 PARTITION BY 與 ORDER BY
官方也強調，這次換 parser 對外的 AST 輸出維持不變，既有查詢不需要修改就能繼續照常運作。
原始來源：DuckDB Blog