近年來，以大型語言模型為核心的 AI 答案引擎，逐漸成為搜尋服務的新形態。Perplexity 作為這類服務的代表，每個查詢並非只回傳網頁標題與摘要，而是需要從大量網頁中取出完整內容片段與向量嵌入，再交給模型生成答案。這種讀取模式與傳統搜尋截然不同：傳統搜尋引擎回傳的是簡短 metadata，而 AI 檢索必須提取 chunked passages 與 dense vector embeddings，平均每筆記錄約五十 kilobytes。Perplexity 原本使用 Amazon DynamoDB 作為核心搜尋服務層，但在生產流量超過每秒二十萬次請求、每個使用者查詢會產生一百到一百二十個目標頁面 key、並由檢索服務拆成十到二十個 key 的平行批次讀取時，DynamoDB 的延遲與成本問題越來越嚴重。AWS 按照實際傳輸的位元組數計費，大量批次讀取讓費用快速膨脹；同時，DynamoDB 對內部運作完全不透明，工程團隊無法控制 partition 的放置位置、記憶體快取策略或副本路由，導致無法預期的尾端延遲 spike。這些 spike 來自未命中快取的讀取、跨可用區域的網路跳躍，以及落後副本的回應。更進一步，每當 chunking 演算法或 embedding 模型更新，系統需要重新處理大量網頁，這些高容量寫入直接進入 DynamoDB，與線上使用者請求互相干擾，形成 noisy neighbor 效應。
為了解決這些問題，Perplexity 將原本單一的儲存層拆分為三個各自專注的系統：Pillar、Lorry 與 CobbleDB。Pillar 負責持久化狀態管理，執行在 YTsaurus 之上，使用高容量機械硬碟，保存網頁 metadata、段落與向量表示等版本化 table family。YTsaurus 的原子事務確保爬蟲更新、狀態變更與匯出佇列能夠一起提交，不會出現部分寫入的狀況。Lorry 是一個無狀態的佇列消費者，負責將 Pillar 匯出的資料整理成對齊 partition 的批次檔案，存放至 Amazon S3，同時把 metadata 通知送給 CobbleDB。CobbleDB 的工作節點會自行從 S3 拉取這些批次並匯入，因此熱門的服務節點完全不會接觸到高容量的寫入管線，兩者徹底隔離。這個架構讓資料從持久化層到服務層的流動變成非同步、批次化，也讓線上讀取路徑不再受背景重新處理任務影響。換句話說，原本 DynamoDB 同時承擔寫入與讀取，如今寫入路徑被導向 Pillar 與 Lorry，CobbleDB 只專注於服務即時查詢。
CobbleDB 本身是 Perplexity 用 Rust 自行開發的分散式 key-value store，專門針對批次查詢最佳化。每個 partition 擁有三個副本，分散在不同的計算節點上。核心 daemon 使用 RocksDB 作為嵌入式儲存引擎，搭配 memory-mapped 快取與本機 NVMe 固態硬碟。查詢路由由無狀態的 router 負責，它會將頁面識別碼進行雜湊，對應到特定 partition，並協調讀取執行。為了降低網路成本，router 會優先將請求導向同一可用區域內的副本；如果目標副本回應時間偏高，router 會採用 speculative hedge 策略，同時對另一個節點上的副本發出並發讀取，以爭取較快的回應。在單一節點內，CobbleDB 透過 RocksDB 的 batched MultiGet 介面一次取得多個 keys，避免逐 key 往返的網路與磁碟開銷。值得注意的是，CobbleDB 完全捨棄分散式交易與同步共識演算法，因為搜尋服務可以容忍輕微的複製延遲，副本各自以非同步方式套用更新，這大幅降低了運作複雜度，也讓系統得以用較少的資源達到高吞吐。
從實際生產數據來看，這套架構帶來了顯著改善。批次讀取的中位數延遲從 31.4 毫秒下降到 5.60 毫秒，p90 從 56.7 毫秒降到 9.77 毫秒，p99 尾端延遲也從 123 毫秒降到 24.2 毫秒，整體讀取延遲約減少五倍。在合成基準測試中，即使 payload 高達 100 kilobytes，系統仍能維持每秒五十萬次請求的吞吐量。儲存成本方面，由於將持久化資料放在成本較低的機械硬碟與 S3，熱資料層只保留需要快速服務的內容，整體儲存費用降低至少兩成。不過，這並非沒有代價。取代全託管雲端資料庫後，節點生命週期管理、備份驗證、partition 再平衡等工作全部轉移到內部 site reliability engineering 團隊身上；應用程式也必須接受最終一致性，因為不同副本匯入批次檔案的時間點並不一致。Perplexity 執行長 Aravind Srinivas 透露，CobbleDB 約四萬行 Rust 程式碼，由兩名系統工程師搭配一群自主 AI coding agents 在兩個月內完成，這些 agents 負責整合測試、建置監控與營運 runbook。Perplexity 也計畫在未來將 CobbleDB 開源，讓其他面對類似讀取模式的團隊可以參考或直接採用。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。