Perplexity自建CobbleDB取代DynamoDB！延遲降八成

「核心資料庫由兩名工程師加數百個AI代理、兩個月寫完。」這句話若放在兩年前，多半被當成行銷話術。但Perplexity在9月14日發出的技術文章，把數字一併攤在陽光下：批次讀取延遲中位數從31.4毫秒降到5.60毫秒，p99從123毫秒降到24.2毫秒，內部成本模型估算，各承諾方案級距都比DynamoDB便宜至少20%。而且，他們打算開源。

先說背景。Perplexity的搜尋API，單次請求包含100到120個頁面鍵，取用時再拆成10到20個鍵的小批次，平均每筆項目約50KB。這種反覆讀取，在DynamoDB按讀寫位元組計價的邏輯下，容量消耗驚人。持續爬取、更換切塊方式或嵌入模型，又會產生大量寫入。更麻煩的是耦合：舊管線把每個處理完的頁面直接寫進DynamoDB，一次大規模重處理就變成熱儲存更新海嘯，根本沒辦法在一兩天內對整個資料庫跑MapReduce，去試新的切塊方法或換嵌入模型。

真正讓工程團隊決定動手的，是調校空間。他們要的操作很窄：給一批頁面識別碼，快速回傳準備好的內容。但他們想控制哪台機器持有分區、多少記憶體配給快取、由哪個複本處理請求。這些，在託管服務的API背後調不到。於是新架構把責任拆成三塊。Pillar維護持久化文件狀態，底層是YTsaurus，用便宜硬碟儲存，因此能存下比過去更多的文件，還追蹤切塊與嵌入版本，讓多種表示法並存。Lorry是無狀態服務，把Pillar的匯出轉成依分區對齊的批次檔。CobbleDB專責查詢時的讀取。

CobbleDB本身是分散式鍵值儲存，鍵是雜湊過的網址，值是該頁預先切好的段落與每段的向量嵌入。資料分區散在各資料節點，每個分區有三個複本。節點以RocksDB儲存，快取走記憶體，未快取走本機NVMe。無狀態查詢路由器把鍵雜湊到分區並平行送出請求，優先送往同一可用區的節點以降低跨區延遲。若某節點回應慢，系統可改查另一個複本。他們刻意不做的事也寫得清楚：熱儲存不需要交易，也不需要同步複本，文件寫入到可被讀取之間存在短暫落差是可接受的。省掉這些，負擔與成本同步下降。

延遲改善的完整數據是：中位數31.4降到5.60毫秒、p90從56.7降到9.77毫秒、p99從123降到24.2毫秒，倍率落在5.08倍到5.80倍之間。測量條件為每次查詢約10到15個鍵、平均項目50KB、約每秒20萬次請求，另做過每秒50萬次的負載測試且未見劣化。但Perplexity自己標明了限制：這仍是觀察性的前後對照，兩套系統在不同時間服務實際生產流量，而不是在受控條件下處理相同請求。成本方面的20%，也是基於內部對儲存大小、寫入容量單位與讀取容量單位的估算。換句話說，方向明確，但數字不是實驗室裡的完美對照。

市場為什麼在意？因為這不是孤例。鏈新聞9月13日才報導OpenAI用兩名工程師加上Codex完成系統遷移。三天內第二起同樣形狀的案例：極小的人類團隊、大量代理、處理的是基礎設施等級的重寫。對加密貨幣與Web3行業來說，這類基礎設施重寫的意義在於，AI代理開始被放進工程迴圈的多個環節：審查程式碼與基礎設施變更、指出容易被忽略的阻礙、準備針對性的修正與測試、追蹤持續整合與審查關卡、監控推出與備份還原演練。分界線也寫得清楚：架構由工程師決定，具重大後果的變更由工程師審查，生產環境操作由人類明確授權。代理處理的是這些決策之間的持續檢查與後續跟進。

看到這裡很多人會問：這跟一般人有什麼關係？關係在於成本結構。如果AI代理能把基礎設施重寫的人力門檻壓到這種程度，未來雲端服務的計費模式、託管服務的黏著度、甚至開源資料庫的生態，都可能被重新洗牌。Perplexity表示計畫在不久後將CobbleDB開源，這或許是下一個值得觀察的節點。分析人士認為，當頭部AI應用開始把自研基礎設施對外開放，受影響的不只是Amazon的帳單，而是整個資料層的競爭格局。

說實話，真正值得關注的，不是那四萬行Rust。而是兩名工程師加數百個AI代理，兩個月內完成核心資料庫。這代表一種新的工程組織形態正在成形：人類負責架構與風險，代理負責檢查與跟進。對機構來說，這可能意味著基礎設施團隊的規模與技能組合需要重新定義。對散戶與開發者來說，開源若成真，或許有機會直接試用這套延遲更低、成本更省的鍵值儲存。當然，觀察性數據不等於受控實驗，成本估算也不等於實際帳單。但方向已經很清楚：AI代理不再只是寫文案，它們正在改寫資料庫。

總結來說，這件事真正說明了兩點。第一，託管服務的調校限制，正在逼出新一代自研基礎設施。第二，AI代理在工程領域的實際產出，已經從輔助角色走向核心交付。未來市場將繼續觀察：CobbleDB是否真的開源、開源後的採用曲線，以及這種「小團隊加大量代理」的模式，是否會出現在更多基礎設施重寫案例中。

FAQ

Q1：Perplexity為什麼要離開Amazon DynamoDB？
A1：文章列出三個約束：DynamoDB按讀寫位元組計價，Perplexity單次搜尋API請求包含大量頁面鍵，反覆讀取消耗容量；託管服務API背後無法調整分區、快取記憶體與複本請求分配；舊管線耦合導致大規模重處理時無法快速對整個資料庫跑MapReduce。

Q2：CobbleDB的延遲改善數據是多少？
A2：批次讀取延遲中位數從31.4毫秒降到5.60毫秒，p90從56.7降到9.77毫秒，p99從123降到24.2毫秒，倍率落在5.08倍到5.80倍之間。測量條件為每次查詢約10到15個鍵、平均項目50KB、約每秒20萬次請求，另做過每秒50萬次負載測試且未見劣化。

Q3：Perplexity的AI代理在專案中負責什麼？
A3：代理被指派的第一項任务是建立對既有進行中工作的準確模型，稽核專案頻道與活躍討論串，把待辦事項連結到對應的拉取請求與負責人。之後在工程迴圈的多個環節運作，包括審查程式碼與基礎設施變更、指出容易被忽略的阻礙、準備修正與測試、追蹤持續整合與審查關卡、監控推出與備份還原演練。