在軟體工程中，當系統規模成長到一定程度時，最初選擇的資料庫模型往往會成為效能瓶頸。Datadog 的工程團隊最近分享了他們如何將一個關鍵的生產系統 Stream Router 從 Key-Value 儲存模型遷移至關聯式資料庫 PostgreSQL 的實戰經驗。這次遷移不僅將最慢的操作從 45 分鐘降低到 1 秒，更大幅降低了運算成本。
技術背景與痛點
Stream Router 是 Datadog 指標管線中負責管理路由的 API。最初它採用的是 FoundationDB，這是一種 Key-Value (KV) 儲存模型，也就是將資料以簡單的鍵值對形式儲存。
對於初學者來說，KV 模型在簡單讀寫時速度極快，但它缺乏關聯式資料庫的 外鍵 (Foreign Keys) 機制。外鍵是用來定義兩張表之間關聯關係的約束，能確保資料的一致性並簡化複雜查詢。
當 Datadog 的路由表規模擴大後，KV 模型的缺陷顯現：由於沒有外鍵，程式碼必須在記憶體中手動重建資料之間的關係。這意味著系統需要從資料庫抓取數萬筆條目到 Pod 處理程序中，在應用層模擬關聯式資料庫的邏輯。這導致了嚴重的效能問題，某些操作需要進行數千次循序往返的網路請求，導致處理時間飆升至 45 分鐘，且觸發了資料庫的交易大小限制。
AI 驅動的重構策略
面對龐大的程式碼庫重構，Datadog 並非讓 AI 自動生成所有程式碼，而是採取了一種以測試驅動開發 (TDD, Test-Driven Development) 為核心的協作模式。他們使用了 Claude (大型語言模型) 與 Cursor (AI 整合開發環境) 來加速過程。
具體的執行流程分為三個階段。首先，利用 Claude 分析並描述每個關鍵函式的意圖，確保 AI 理解業務邏輯。接著，工程師提供舊版實作、新版資料表結構 (Schema) 以及一個目前會失敗的測試案例 (Failing Test)，要求 AI 產生能通過測試的新程式碼。最後，透過測試結果反饋給 AI 進行修正，直到測試通過。
這種做法將 AI 定位為高效的實作工具，而將正確性的判定權交給測試套件，避免了 AI 產生幻覺或邏輯錯誤導致的生產事故。
確保遷移成功的關鍵基建
這次遷移之所以能順利完成，依賴於三項關鍵的工程實務。
第一是高度的模組化。Stream Router 的 API 設計與底層儲存解耦，使得團隊能將底層從 FoundationDB 切換到 PostgreSQL 而不需要修改其他呼叫端。
第二是完善的測試套件。這是整個流程的信任基礎。沒有強大的測試，工程師將無法快速驗證 AI 生成的程式碼是否正確，重構將變成一場豪賭。
第三是平行基礎設施與驗證機制。他們採取了類似藍綠部署 (Blue/Green Deployment) 的策略，讓新舊兩套系統同時運行並處理相同的請求。透過功能開關 (Feature Flags) 切換流量，並部署一個專屬的驗證服務 (Validator Service) 定期比對兩者的回應。一旦發現結果不一致，系統會立即發出警報。
AI 的限制與人類工程師的價值
儘管 AI 大幅提升了速度，但 Datadog 發現 AI 在處理深度優化時仍有不足。例如，AI 產生的 SQL 查詢雖然結果正確，但缺乏效能優化，會產生不必要的網路往返。
針對進階的資料庫技巧，如 批次處理 (Batching)、UNNEST 技巧或 通用資料表運算式 (CTE, Common Table Expressions)，AI 無法自主發現最優解。這些部分仍需要資深工程師手動撰寫優化版本。有趣的是，一旦工程師提供優化後的範例，AI 就能學習該模式並將其應用到後續的函式中。
此外，由於在迭代過程中餵給 AI 大量的測試輸出日誌，導致 Token 消耗量極高，這提醒我們在實務中應精簡上下文資訊。
遷移成果
這次遷移帶來了顯著的量化提升。操作時間從 45 分鐘縮短至約 1 秒，延遲從數百毫秒降至個位數。儲存空間縮小了 40 倍，CPU 與記憶體使用量下降，資料庫成本更是降低了 90%。
這次經驗證明，AI 在大規模重構中的真正價值不在於自動化，而是在於當你擁有強大的測試套件與模組化架構時，它能極大地縮短從設計到實作的循環時間。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。