FerresDB 走向正式上線的 Rust 搜尋

說真的，FerresDB 這次更新很有料。它一次補上 5 個生產功能。包含 FerresDB、HNSW 自動調參、ONNX Runtime reranking、PITR，還有 Raft 基礎層。這不是玩具功能堆疊。這是在補正式上線會遇到的坑。

講白了，向量搜尋最難的地方，早就不是「能不能找相似資料」。而是記憶體怎麼省、出錯怎麼救、延遲怎麼穩。FerresDB 這波更新，方向很明確。它想從 demo，直接走到可營運的資料庫。

從 demo 走到正式系統

FerresDB 原本就不是空殼。它有 HNSW 型索引、WAL、定期 snapshot、BM25 混合搜尋、scalar quantization、tiered storage、WebSocket 串流、OpenTelemetry tracing，還有 API key 的 RBAC。這些東西湊在一起，才像一套真的資料庫。

這次更新的重點，是把「能跑」補成「能長期跑」。很多團隊做 RAG 或語意搜尋時，先把查詢打通。接著才發現，備份、權限、觀測、還原，才是每天會咬人的地方。FerresDB 這次就是在補這些。

我覺得這很務實。因為向量搜尋系統如果只會快，通常活不久。真正上線後，大家先問的不是 recall。是「昨天誤刪了，能不能救回來？」、「高峰期延遲會不會爆？」、「多租戶會不會互相干擾？」

• 支援 cosine、Euclidean、dot product
• Scalar quantization 可把 f32 壓成 u8
• 記憶體占用約可降到 1/4
• OpenTelemetry 可追每次搜尋
• API key 可控 collection 權限

這些功能看起來很工程。其實很合理。因為真正花時間的，通常不是模型，而是資料服務本身。你可以今天把 embedding 算完，但明天還是得面對權限、備份、觀測和延遲抖動。

“The key insight: angular boundaries are mathematically fixed. There’s no calibration step, no per-block parameters, and no warm-up phase before the index is ready.”

PolarQuant 在壓縮上換了思路

這次最有意思的儲存更新，是 PolarQuant。舊的 SQ8 會先做 calibration，再把每個維度壓縮。這樣準確率通常不錯，但啟動前要先吃一輪資料。對要快速建立 collection 的系統來說，這步驟很煩。

PolarQuant 的做法不一樣。它把向量拆成半徑和角度，再把角度量化成 u8。重點是，它不用 calibration。沒有 warm-up sample，也不用等索引「養好」才開放查詢。這種設計很適合 on-demand 建立資料集的場景。

FerresDB 也做了 Criterion benchmark，名字叫 quantization_comparison。它比較 build time、search latency、recall@10 和記憶體用量。測試維度是 128 和 384。結果很直白：PolarQuant 啟動比較快，SQ8 在高維度時可能有一點準確率優勢。

• SQ8 需要每維 calibration
• PolarQuant 跳過 calibration
• PolarQuant 建完就能用
• SQ8 在高維度可能更準

這種取捨很像真實產品選型。你如果是短生命週期工作負載，啟動快很重要。你如果是長期穩定服務，準確率可能更重要。FerresDB 沒硬講誰一定贏，它只是把選項攤開。

我覺得這比單純追求壓縮率更成熟。因為資料庫不是論文。論文可以只看指標。上線之後，啟動時間、維護成本、資料分布，全部都會變成錢。

HNSW 自動調參，少一點手工猜拳

FerresDB 的 FerresEngine 現在會自動調整 HNSW 的 ef_search。這個參數很關鍵。值高一點，recall 通常更好。代價就是 CPU 更忙，查詢也更慢。

它的做法不複雜。每 60 秒檢查一次每個 collection 的 P95 latency。若延遲還有空間，就把 ef_search 往上加。若延遲開始變高，就往下調。這種控制法很像保守版的自動駕駛。它不追極限，只求穩。

這點我蠻認同。因為很多團隊其實都卡在 HNSW tuning。參數不是不懂，是流量一直變。白天和夜晚不同，冷資料和熱資料不同，租戶 A 和租戶 B 也不同。固定值常常撐不久。

• 每 60 秒看一次 P95 latency
• 延遲低就提高 ef_search
• CPU 壓力高就降低 ef_search
• 目前值可在 stats API 看到

FerresDB 這裡採的是保守控制。它不是複雜的 PID loop。這很像資料庫圈常見的現實主義。先別亂飆。先把波動壓住。對線上服務來說，穩定常常比理論最優更值錢。

你可能會問，這種自動調參會不會太粗？會。但我覺得比完全手動好。因為手動調參常常只在壓測當下準。真正上線後，流量一變，參數就失真。

PITR、reranking，還有那些最容易漏掉的事

這次更新裡，最像「正式上線必備」的功能，是 point-in-time recovery。FerresDB 現在能用 WAL 和 snapshot 做時間點還原。這跟 PostgreSQL 的思路很接近。你可以回到某個時間點，不用整個退回到最後一次完整備份。

這對操作失誤很有用。比如批次 upsert 寫錯，或是誤刪某個 namespace。只要 WAL 還在，還原就有機會救回來。這種功能平常沒人喊。出事時大家都會找它。

另一個很實際的功能，是 reranking。FerresDB 透過 ONNX Runtime 跑 cross-encoder，把 HNSW 找出的候選結果再排一次。流程很標準。先撈較多候選，再用模型重排，最後回傳 top matches。這對 RAG 很重要。

FerresDB 的預設是撈 5 倍的候選數，再送進 reranker。這個倍率蠻合理。太少，排序沒材料。太多，延遲會上去。它還會回報 rerank latency，讓你知道模型成本到底多高。

• PITR 可回到指定時間點
• /api/v1/admin/restore/points 可列出還原點
• rerank 預設抓 5 倍候選
• ONNX Runtime 不用再開 Python 服務

如果你做過語意搜尋，應該很懂這個差別。第一階段檢索負責找得到。第二階段 rerank 負責排得對。很多系統死在只做第一段。結果是找得到一堆東西，但答案順序很爛。

多租戶、圖遍歷、Raft，開始像真的服務

FerresDB 也補了多租戶控制。namespace allowance 可以讓 API key 只看特定 namespace。若開啟物理隔離，每個 namespace 會放在自己的目錄。這種分法很聰明。因為授權和資料布局，本來就不是同一件事。

它還加了 graph traversal。點與點之間可以連結，連結也會寫進 WAL。之後可以用 BFS 只在連通子圖裡搜尋。這對 citation graph、相關文件探索、或群組內語意搜尋都很實用。

最後是 Raft 基礎層。這代表它開始碰分散式狀態複寫。講白了，這是從單機搜尋引擎，往可規劃的叢集服務走。這一步很硬。也很必要。

• allowed_namespaces 可限制可見範圍
• 物理隔離可把 namespace 分開存
• 圖遍歷用 BFS 走連結節點
• Raft 為複寫和協調打底

這組功能放在一起，就很像一套準備上線的資料庫。壓縮省記憶體，調參穩延遲，PITR 防操作失誤，reranking 顧品質，Raft 顧叢集。每一項都不花俏，但都很實際。

我會把這種更新看成一個訊號。FerresDB 不再只想證明自己能做向量搜尋。它想證明自己能在真實環境裡活下來。

這反映了 Rust 資料庫的現況

這次更新也說明一件事。Rust 在基礎設施領域，已經不是旁觀者。以前很多 Rust 資料庫專案，只強調速度。現在開始補觀測、備份、權限、還原和分散式協調。這才像真正的服務。

向量搜尋的問題，也變了。現在不是「能不能算最近鄰」。而是「能不能在 10 倍流量下維持延遲」、「能不能在誤操作後救回來」、「能不能讓多租戶共存」。這些問題很土，但很真。

我猜 FerresDB 下一步，重點會落在叢集操作。不是單純再加搜尋指標，而是看 Raft 複寫、namespace 隔離、rolling restart 能不能撐住。那才是資料庫的硬仗。

如果你正在選 RAG 或語意搜尋的後端，這版 FerresDB 值得看。重點不是功能多。重點是這些功能，對不對得上你遲早會遇到的事故。

如果你想追 Rust 和 AI 基礎設施，我會先看這種專案。它不只是在跑 benchmark。它在學怎麼當一個能被營運的服務。

結語：這版值得拿來做選型參考

我的判斷很直接。FerresDB 現在已經不是「可以玩玩看」的階段。它開始像一套能放進生產環境評估的 Rust 向量資料庫。當然，Raft 和多租戶還要經過更多實戰驗證，但方向是對的。

如果你在評估向量資料庫，我會先問三件事：能不能救資料、能不能穩延遲、能不能支援多租戶。FerresDB 這次補的，剛好就是這三塊。接下來就看它能不能把這些功能磨到更穩。