OpenData Vector: MIT-Licensed Vector Search on Object Storage

生成式 AI 與大型語言模型 (LLMs) 的興起，使得向量資料庫需要一種能夠線性擴展，且不會產生傳統向量資料庫那樣高昂成本開銷的概念。OpenData Vector 引入了一種新的向量搜尋方法，利用物件儲存 (object storage) 作為主要儲存層，有效地將運算與儲存解耦，為專有向量搜尋引擎提供了一個具備擴展性且採用 MIT 授權的替代方案。

The Architecture of OpenData Vector

OpenData Vector 的核心設計旨在解決向量資料庫的主要瓶頸：高效能儲存的成本與規模。透過利用物件儲存 (例如 AWS S3, Google Cloud Storage, 或 Azure Blob Storage)，系統允許使用者維護龐大的嵌入向量 (embeddings) 資料集，而無需使用通常高效能搜尋所需的高昂 SSD 基礎設施。

這種運算與儲存的解耦允許獨立擴展。如果搜尋量增加，可以增加更多運算節點來處理查詢負載，而無需在多個昂貴的磁碟上複製整個資料集。相反地，如果資料量增加，儲存成本仍將保持在低水平，因為物件儲存明顯比高效能區塊儲存 (block storage) 便宜得多。

Performance and Implementation Details

雖然物件儲存本質上比本地 SSD 慢，但 OpenData Vector 實作了緩解延遲的策略。其架構遵循將索引 (index) 與資料分離的模式，其中索引會被快取或儲存在更高效能的層級中，以確保查詢結果能快速回傳。

這種方法與 Turbopuffer 等其他高效能向量搜尋引擎中常見的架構模式類似。其目標是在透過高效的索引與記憶體管理來維持搜尋結果準確性的同時，實現高查詢吞吐量。

Community Discussion and Key Considerations

在發布之後，社群針對效能權衡與專案目前的成熟度提出了幾個關鍵問題。

The Performance Gap

其中一個主要的擔憂是 OpenData Vector 與高度優化的、硬體加速系統的比較。正如社群成員 @oliverio 所指出的，某些專有系統在硬體與韌體層級進行了顯著的優化，這可能會造成效能差距。OpenData Vector 的挑戰在於如何在保持物件儲存通用性質的同時，將這些優化實作到開源專案中。

The Cost of Object Storage QPS

另一個討論點圍繞著請求率的成本。一種常見的看法是，如果每秒查詢數 (QPS) 極高，由於與 GET 和 PUT 操作相關的請求成本，物件儲存可能會變得昂貴。

"I was under the impression that object storage was super expensive compared to "normal" SSDs if the QPS numbers got high."

為了應對這一點，基於物件儲存的系統通常會採用激進的快取層，或在資料提交到儲存層之前，先在資料庫伺服器上進行大量的預處理。透過減少對物件儲存的直接呼叫次數，這些系統可以同時維持儲存的成本效益與本地磁碟的效能。

Conclusion

對於那些希望避免供應商鎖定並保持對其嵌入向量 (embeddings) 控制權的人來說，OpenData Vector 提供了一個了一個具備吸引力的 MIT 授權替代方案。透過將向量搜尋引擎移至物件儲存，它挑戰了傳統的高昂、高效能儲存需求模型，使大規模向量搜尋對開發者與 MIT 授權的軟體專案更易於取得。