clickhousectl：本地多版本並行測試，DISTINCT 查詢提速 5×、Parquet 元資料快取
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
# 跨版本複製資料表結構（無需手動 DDL）
# 使用 --time 旗標量測查詢時間DISTINCT 低基數欄位效能（v26.1 改進）
| 版本 | 平均查詢時間 |
|---|---|
| ClickHouse 25.12 | ~76ms |
| ClickHouse 26.3 | ~15ms |
針對低基數欄位的 DISTINCT 查詢，v26.1 引入的最佳化帶來約 5× 加速。
Parquet 元資料快取（v26.3 引入）
新機制快取 Parquet 檔案的 footer 元資料（含結構、row group、統計資訊），使用 ETag 進行快取驗證：
| 場景 | 25.12 | 26.3 |
|---|---|---|
| 初次 S3 查詢 | ~11–12 秒 | ~11–12 秒 |
| 重複查詢（快取命中） | ~8–9 秒 | ~1–2 秒 |
快取命中時約 5× 加速，適合頻繁存取相同 S3 Parquet 資料集的工作負載。
原始來源：ClickHouse Blog — Comparing ClickHouse versions with clickhousectl
Active-Active vs Active-Passive 資料庫架構：CRDB、CRDT 與 RTO/RPO 取捨
Redis Blog (Jim Allen Wallace) · 2026-04-29
Redis 工程部落格詳細比較兩種高可用資料庫架構的技術機制，著重 Redis 本身的 Active-Active 實作——Conflict-free Replicated Database（CRDB）。
架構差異
Active-Passive：單一主節點處理所有寫入；備援節點閒置，透過心跳偵測觸發提升（promotion）流程。主要弱點：提升步驟引入 RTO（秒至分鐘），且 2.5% 的多可用區資料庫在一次協定錯誤中失效；「冷快取問題」在提升時使備援節點無法處理生產流量（2012 GitHub 事件先例）。
Active-Active：所有節點同時接受讀寫；消除提升步驟，RTO 更低；但需要衝突解析機制。
Redis CRDB 的衝突解析
Redis Active-Active 透過 CRDB 實作，在全球多個叢集之間建立雙向網狀複製（bi-directional mesh replication），各叢集使用資料型別特定的 CRDT 語義：
- 計數器：交換律遞增，並行遞增都計入
- 集合：Add-wins 語義（並行 add 優先於並行 remove）
- Hash：欄位級別獨立解析（不同欄位的並行更新不衝突）
一致性模型為強最終一致性（Strong Eventual Consistency, SEC），無需共識協定（consensus protocol）。可選用因果一致性（causal consistency），但會增加網路與記憶體負擔。
可用性指標參考
| 可用性 | 年停機上限 | 月停機上限 |
|---|---|---|
| 99.9% | ~8.76 小時 | ~43.8 分鐘 |
| 99.99% | ~52.6 分鐘 | ~4.4 分鐘 |
| 99.999% | ~5.26 分鐘 | ~26 秒 |
LLM 推理兩階段剖析：Prefill 算力瓶頸與 Decode 記憶體頻寬瓶頸
Redis Blog · 2026-04-28
此文從儲存與推理基礎設施的角度，深入分析 LLM 推理的 Prefill 與 Decode 兩個不同瓶頸，以及各自的最佳化策略。
Prefill 階段
Prefill 並行處理整段輸入提示，是算力（compute-bound）瓶頸。由於 attention 機制的複雜度，提示長度加倍大致使 attention 工作量翻四倍（quadratic scaling）。效能指標為 TTFT（Time to First Token）。Prefill 輸出 KV cache，後者作為 Decode 的起點。
Llama 3.1 70B 實測：32,768 tokens 約 472ms TTFT；122,880 tokens 約 2.2 秒。
Decode 階段
Decode 每次只生成一個 token，受記憶體頻寬（memory-bandwidth-bound）限制。每個 decode 步驟必須讀取整個累積的 KV cache，隨著輸出增長而持續膨脹。效能指標為 ITL（Inter-Token Latency）。
最佳化策略對比
| 階段 | 策略 | 效果 |
|---|---|---|
| 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 串流，導致活躍使用者體驗到輸出停頓。
原始來源：Redis Blog — Prefill vs Decode: LLM Inference Phases Explained