clickhousectl 本地多版本對比：DISTINCT 查詢 5× 加速（v26.1）、Parquet 元資料快取 5×（v26.3）
ClickHouse Blog（Mark Needham）· 2026-04-29
ClickHouse 官方 CLI 工具 clickhousectl 新增本地多版本並行執行能力，允許工程師在同一台機器上同時啟動不同版本的 ClickHouse 實例以對比查詢效能。
基本操作
curl https://clickhouse.com/cli | sh
chctl local install 25.12
chctl local install 26.3
# 自動偵測並分配未衝突的 port
# --time 旗標：量測查詢執行時間（秒）DISTINCT 低基數欄位效能（v26.1 改進）
| 版本 | 平均查詢時間 |
|---|---|
| ClickHouse 25.12 | ~76ms |
| ClickHouse 26.3 | ~15ms（~5×） |
針對低基數欄位的 DISTINCT 查詢，v26.1 引入的最佳化帶來約 5× 加速，適用於 GROUP BY、DISTINCT 等聚合操作頻繁的 analytics 工作負載。
Parquet 元資料快取（v26.3 引入）
新機制快取 Parquet 檔案的 footer 元資料（schema、row group 統計、column chunk 資訊），以 ETag 進行快取驗證：
| 場景 | 25.12 | 26.3 |
|---|---|---|
| 初次 S3 查詢 | ~11–12 秒 | ~11–12 秒 |
| 重複查詢（快取命中） | ~8–9 秒 | ~1–2 秒（~5×） |
快取命中時約 5× 加速，適合頻繁存取相同 S3 Parquet 資料集的工作負載。初次查詢時間不變，因為 footer 讀取仍需發生一次。
原始來源：ClickHouse Blog — Comparing ClickHouse versions with clickhousectl
Active-Active vs Active-Passive：Redis CRDB 的 CRDT 衝突解析與 RTO/RPO 取捨
Redis Blog · 2026-04-29
Redis 工程部落格深度比較兩種高可用資料庫架構，著重 Redis 的 Active-Active 實作——Conflict-free Replicated Database（CRDB）。
架構核心差異
Active-Passive：單一主節點處理所有寫入；備援節點閒置，透過心跳偵測觸發提升（promotion）流程。提升步驟引入 RTO（秒至分鐘），且研究顯示 2.5% 的多可用區資料庫在一次協定錯誤中失效；「冷快取問題」使提升後的備援節點無法立即處理生產流量（參見 2012 GitHub 事件）。
Active-Active CRDB：所有節點同時接受讀寫；雙向網狀複製（bi-directional mesh replication）；消除提升步驟，RTO 更低；需要衝突解析。
Redis CRDB 的 CRDT 語義
- 計數器：交換律遞增——所有並行遞增都計入，天然無衝突
- 集合：Add-wins 語義——並行的 add 優先於並行的 remove
- Hash：欄位級別獨立解析——不同欄位的並行更新不產生衝突
一致性模型為強最終一致性（Strong Eventual Consistency，SEC），無需 Paxos / Raft 等共識協定。可選配因果一致性（causal consistency）確保特定 key 的操作排序，但增加網路與記憶體負擔。
RTO/RPO 參考
Active-Active 的 RTO 下限取決於流量重路由時間（通常毫秒級），而非提升時間（秒至分鐘）。RPO 在設計良好的 Active-Active 部署中可趨近於零，相比 Active-Passive 非同步複製的數秒至數分鐘 lag 有根本改善。
使用決策框架
選擇 Active-Passive：單寫入一致性要求嚴格、用戶集中於單一地區、可接受短暫容錯切換中斷。選擇 Active-Active：需要 99.999% 可用性、全球分散式用戶、容忍最終一致性、不可接受提升流程。混合模式：區域間 Active-Active + 區域內 Active-Passive，兼顧全球可用性與本地一致性。
原始來源：Redis Blog — Active-Active vs Active-Passive database architecture
LLM 推理兩階段剖析：Prefill 算力瓶頸、Decode 頻寬瓶頸與 KV 快取力學
Redis Blog · 2026-04-28
此文從儲存與推理基礎設施角度，深入分析 LLM 推理的 Prefill 與 Decode 兩個不同瓶頸，以及各自對應的最佳化路徑。
Prefill 階段：算力瓶頸（compute-bound）
Prefill 並行處理整段輸入提示，建立 KV cache。由於 attention 機制的 O(n²) 複雜度，提示長度加倍大致使 attention 計算量翻四倍。效能指標為 TTFT（Time to First Token）。
Llama 3.1 70B 實測：32,768 tokens → 472ms TTFT；122,880 tokens → ~2.2 秒。
Decode 階段：頻寬瓶頸（memory-bandwidth-bound）
Decode 每次只生成一個 token，必須讀取整個累積的 KV cache，隨輸出增長持續膨脹。效能指標為 ITL（Inter-Token Latency）。大型請求批次中，KV cache 可達模型權重大小的數倍，成為記憶體壓力的主要來源。
各階段最佳化策略
| 階段 | 策略 | 效果 |
|---|---|---|
| Prefill | FlashAttention | 重組計算模式，相同輸出，更快計算 |
| Prefill | Semantic Caching（Redis LangCache） | 相似查詢命中快取，跳過整個推理 |
| Decode | Speculative Decoding | Llama 3.3 70B 上 3.55× 加速 |
| Decode | INT4 KV Cache 量化 | LLaMA3-8B decode 延遲降低 57% |
| Decode | W8A8 量化 | decode 改善 40–60% |
工作負載分類與診斷
RAG 應用（長輸入、短輸出）以 Prefill 為瓶頸；程式碼生成（短輸入、長輸出）以 Decode 為瓶頸；聊天機器人兩者皆需關注。Prefill 請求可阻塞 Decode 串流，導致活躍使用者看到輸出停頓——一個早期 vLLM 框架的策略即因此問題而知名。診斷方法：TTFT 衡量 Prefill，ITL = (end-to-end latency - TTFT) / (output tokens - 1) 衡量 Decode。
原始來源：Redis Blog — Prefill vs Decode: LLM Inference Phases Explained