SmithDB中的全文搜尋：為物件儲存設計倒排索引

SmithDB支援對代理追蹤進行全文搜尋和JSON過濾，中位延遲僅為400毫秒，儘管其底層資料是儲存在物件儲存中的大型巢狀JSON文件。這一效能得益於為物件儲存量身定製的倒排索引設計。

代理追蹤資料具有獨特特徵：每個事件的輸入和輸出欄位佔絕大多數字節，常見payload大小超過1MB，甚至達到數百MB。此外，隨著LLM上下文視窗增大和代理執行時間延長，payload持續增長。這導致傳統搜尋索引的經濟性被顛覆——文件極大，索引與源資料比例高達1:1.9。同時，詞頻遵循Zipfian分佈，少數高頻詞出現頻率極高，而長尾詞僅出現一兩次。查詢模式包括路徑存在（json_key）、鍵值搜尋（json_key_search）和全文搜尋（search），每種模式對索引有不同的要求。

物件儲存的約束使得索引設計必須最小化請求次數。傳統搜尋引擎如Tantivy基於mmap，假設隨機I/O廉價，不適合物件儲存約100ms的往返延遲。SmithDB的搜尋引擎整合在基於Vortex的列式引擎中，要求doc ID與Vortex行索引對齊。

第一個版本的索引直接使用Vortex預設編碼，將術語和值儲存為兩列，但遇到了問題：沒有按術語的編碼控制，導致高頻詞迫使整個列使用更寬的位寬；行組基於固定術語數量，導致大小嚴重不均；合併時需要解壓並重組位置列表，成本高昂。

第二個版本改變了組織單元：從“每個行組N個術語”變為按位元組預算劃分行組，並自定義每列的位元組佈局。每個行組佔用相近的位元組數，由術語頻率決定，而非術語數量。位置列表採用緊湊的位編碼，併為高頻詞保留額外空間。合併時只需連線段切片，無需重新計算偏移量。這顯著減少了物件儲存請求和合併成本。

目前，SmithDB的倒排索引在生產環境中處理數百萬文件，P50延遲維持400ms。未來計劃包括支援更復雜的短語查詢和進一步最佳化壓縮。