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。未來計劃包括支持更復雜的短語查詢和進一步優化壓縮。