ClickHouse Cloud 索引分片：一致性雜湊分散索引分析至所有副本，主鍵查詢加速 4.3×、Bloom Filter 7.7×
ClickHouse Blog · 2026-04-21
ClickHouse Cloud 推出索引分片（Index Sharding），將索引分析工作分散至所有副本，打破傳統上單節點必須載入完整索引的記憶體瓶頸。
問題背景
ClickHouse 的跳躍索引（Skipping Index，包括 Bloom Filter、Min-Max Index、向量索引）儲存於磁碟，查詢時需載入至記憶體進行分析以確定哪些資料 granule 需讀取。在傳統副本架構中，每個副本都需要完整載入所有索引——三個副本的叢集，100 GB 索引需消耗 300 GB 累計記憶體；12 個副本則高達 1.2 TB。
索引分片架構
索引分片以一致性雜湊（Consistent Hashing）將資料 parts 分配給副本。查詢初始節點在接收請求後，將索引分析工作分派至各副本——每個副本僅分析自身持有的 part 子集——並收集各副本回傳的 granule 範圍，合併後再執行資料讀取。副本數量增加時，每節點的索引記憶體消耗反而降低，且分析工作可並行化，同時帶來更好的快取局部性（locality of reference）。
效能測試結果（500 億列、10 副本）
- 主鍵查詢：4.3× 加速
- Bloom Filter 查詢：7.7× 加速
- 向量搜尋：7.2× 加速
- 全文搜尋：5.8× 加速
從 10 個副本擴展至 20 個副本，額外帶來 1.4× 至 1.7× 的進一步加速。
啟用條件
索引分片在以下條件同時成立時自動啟用（閾值可設定）：資料表 part 數量 ≥ 10；所有索引的合計大小 ≥ 1 GB（預設值）。滿足條件時無需任何設定變更，Cloud 服務自動套用。
Redis Active-Active 與 Active-Passive：CRDB 的 CRDT 衝突解析語義與 RTO/RPO 取捨
Redis Blog · 2026-04-29
Redis 工程部落格深度比較兩種高可用資料庫架構，著重 Redis 的 Active-Active 實作——Conflict-free Replicated Database（CRDB）的具體衝突解析語義。
Active-Passive 的限制
傳統主-備模式中，所有寫入必須路由至主節點，備份節點閒置，透過心跳偵測觸發提升（promotion）流程。提升步驟引入 RTO（秒至分鐘），「冷快取問題」使提升後的備援節點無法立即處理生產流量（2012 年 GitHub 事件為典型案例）。研究顯示 2.5% 的多可用區資料庫在一次協定錯誤中失效。
Active-Active CRDB 架構
CRDB 在每個參與區域部署一個完整的 Redis 實例，每個實例均可獨立接受讀寫。資料以非同步方式在實例間交換，並以每個操作的向量時鐘（Vector Clock）追蹤因果關係。一致性模型為強最終一致性（Strong Eventual Consistency，SEC），無需 Paxos / Raft 等共識協定。
CRDT 衝突解析語義
- 計數器：交換律遞增——所有並行遞增都計入，天然無衝突。
- 集合（Set）：Add-Wins 語義——並行的 add 優先於並行的 remove；若 A 區域新增一個元素、B 區域同時刪除，合併後元素保留。
- Hash 欄位：欄位級別獨立解析——不同欄位的並行更新不產生衝突；同一欄位的並行更新以 Last-Write-Wins（LWW）解決。
- List：各地區的 push 操作在合併後的排列中依時間戳排序，每個操作均保留。
地理故障轉移
Redis 4.23 新增的用戶端側地理故障轉移允許 Redis client 函式庫偵測到當前區域不可用時，自動透明地路由至另一個 Active 節點，毋需 DNS TTL 等待。Active-Active 的 RTO 下限取決於流量重路由時間（通常毫秒級），而非提升時間（秒至分鐘）。
原始來源：Redis Blog — Active-Active vs Active-Passive database architecture
LLM 推理兩階段剖析：Prefill 算力瓶頸與 Decode 頻寬瓶頸的最佳化路徑
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 | 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 為瓶頸；聊天機器人兩者皆需關注。診斷方法：TTFT 衡量 Prefill，ITL = (end-to-end latency - TTFT) / (output tokens - 1) 衡量 Decode。Prefill 請求可阻塞 Decode 串流，導致活躍使用者看到輸出停頓——稱為 head-of-line blocking，是早期推理框架的已知問題。
原始來源：Redis Blog — Prefill vs Decode: LLM Inference Phases Explained