當許多工程師在面對數據量成長時，直覺反應往往是增加硬體資源或在前面加上 Redis 快取層。然而，當數據量從萬級跳升至十億級時，傳統的關聯式資料庫（RDBMS）會遇到根本性的效能瓶頸。AI 軟體測試平台 Momentic 的經驗提供了一個很好的案例：他們如何透過將快取系統從 PostgreSQL 遷移至 ClickHouse，在處理 200 億筆紀錄的情況下，依然將平均回應延遲控制在 250 毫秒。
為什麼 PostgreSQL 在大規模數據下會失效
PostgreSQL 是一款強大的通用型資料庫，但它在處理極大規模且高頻率讀寫的快取場景時，會面臨兩個主要問題。首先是索引成本，PostgreSQL 使用 B-tree 索引，隨著數據量增加，索引的維護成本與查詢開銷會同步成長。其次是鎖競爭（Lock Contention），在高併發的讀寫環境中，資料庫為了確保一致性會產生鎖定機制，這導致讀取與寫入操作互相等待，造成系統資源飆升且延遲增加。
從行式儲存轉向列式儲存
為了突破瓶頸，Momentic 選擇了 ClickHouse。這裡需要理解一個核心概念：PostgreSQL 是行式儲存（Row-oriented），適合處理單筆紀錄的完整讀寫；而 ClickHouse 是列式儲存（Column-oriented），專為分析大規模數據而設計。
ClickHouse 的關鍵優勢在於它使用稀疏索引（Sparse Index）而非 B-tree 索引。稀疏索引不會記錄每一筆資料的位置，而是將資料分成稱為顆粒（Granules）的區塊。當查詢條件明確時，ClickHouse 能迅速跳過不相關的區塊，僅掃描極少數的顆粒。這使得查詢效能不再隨數據量線性增長，而是保持在極高效率。
解決數據分佈不均的挑戰
在實作過程中，Momentic 發現並非所有查詢都能享受稀疏索引的紅利。對於特徵分支（Feature Branches）的查詢，由於 key 值分布集中，能精確定位數據區塊。但對於主分支（Main Branches），由於涉及的紀錄數量龐大，查詢時可能會掃描幾乎所有數據分片（Data Parts），導致記憶體使用量劇增且產生 I/O 尖峰。
為了優化這個問題，他們引入了物化視圖（Materialized Views）。物化視圖在本質上是一種預計算機制，它提前計算好每個測試 ID 對應的提交時間戳記，讓查詢能直接跳轉到正確的數據區塊，避免全表掃描。
簡化寫入邏輯與移除冗餘層
在 PostgreSQL 時期，一次測試運行需要執行三次獨立查詢來維護快取。但在 ClickHouse 中，這種碎片化的查詢模式效率較低。Momentic 改用一種更簡潔的策略：大量使用 INSERT 寫入，並搭配 ClickHouse 的 ReplacingMergeTree 引擎。
ReplacingMergeTree 的特性是在背景非同步地對具有相同主鍵的資料進行去重（Deduplication）。工程團隊不再頻繁地 SELECT 檢查再 UPDATE，而是直接將新數據與需延長生存時間（TTL）的數據重新 INSERT 進去，由資料庫在後台處理重複項。這種高效的寫入模式讓他們甚至能直接移除原有的 Redis 層，因為 ClickHouse 的讀取速度已足以應對高基數（High Cardinality）的快取需求。
確保遷移零風險的影子查詢策略
對於生產環境的資料庫遷移，直接切換（Cutover）風險極高。Momentic 採取了影子查詢（Shadow Querying）的漸進式方案。
首先，他們實作雙寫（Dual Writes），所有寫入操作同時發送到 PostgreSQL 與 ClickHouse。此時，正式流量依然由 PostgreSQL 承擔，但系統會同步對 ClickHouse 發出相同的查詢請求。接著，將兩個資料庫的返回結果進行比對（Diff），確保 ClickHouse 的邏輯正確性。在確認數據一致後，才逐步將流量切換至 ClickHouse，並在切換後保留一段時間的雙寫，以便在發生意外時能迅速回滾。
最終成果
透過這次架構重構，Momentic 成功將快取規模擴展至 200 億筆紀錄，每日處理超過 200 萬次查詢，且平均延遲維持在 250 毫秒。這證明了在面對海量數據時，選擇適合儲存引擎（列式儲存）並利用其特性（稀疏索引與物化視圖）重新設計數據流，比單純增加硬體資源更為有效。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。