開源資料庫領域迎來了一個新的競爭者，那就是 HelixDB，這是一個用 Rust 編寫的圖譜向量資料庫，專為 RAG（檢索增強生成）和人工智慧應用而設計。引起社群關注的是其大膽的效能宣告以及獨特的圖譜和向量功能結合方式。
 |
|---|
| 這個 HelixDB 的 GitHub 頁面展示了其作為一個面向 AI 應用的開源圖譜向量資料庫的結構 |
效能宣告引發質疑
HelixDB 的開發者聲稱他們的資料庫比 Neo4j 快1000倍，比 TigerGraph 快100倍，同時在向量處理方面與 Qdrant 相當。這些斷言促使社群成員要求提供證據，一位使用者直接要求提供基準測試來支援這些宣告。HelixDB 團隊承認他們確實進行了這些基準測試，但在宣佈專案之前尚未釋出這些資料，並承諾將詳細的效能資料新增到他們的文件中。
HelixDB 的主要特點
- 快速高效：聲稱比 Neo4j 快1000倍，比 TigerGraph 快100倍，在向量處理方面與 Qdrant 相當
- RAG優先：原生支援圖和向量資料型別
- 圖-向量整合：支援節點之間、向量之間或節點與向量之間的關係
- 儲存：由 LMDB（閃電記憶體對映資料庫）提供支援
- ACID相容：確保資料完整性和一致性
- 向量維度：目前沒有上限，未來可能限制在約64,000維
- 查詢語言：具有型別安全的自定義DSL
- 許可證：AGPL（Affero通用公共許可證）
向量能力和維度
該資料庫似乎具有強大的向量支援，開發者確認目前對向量維度沒有上限。他們提到將來可能會實施約64,000維的上限，類似於 Qdrant 和 Pinecone 等其他向量資料庫。團隊還透露計劃在未來幾個月內實施二進位制量化，以提高高維向量的效能，表明他們瞭解向量操作中的效能權衡。
圖譜向量整合使其與眾不同
HelixDB 與 KuzuDB 等競爭對手的區別在於其整合圖譜和向量功能的方法。據開發者介紹，HelixDB 支援向量的增量索引，允許更新而無需對所有向量進行完全重新索引。這解決了一些現有解決方案的痛點，即向量索引與圖譜結構完全分離，更新時需要全面重新索引。
「與任何圖譜資料庫的使用方式基本相同，但額外的好處是能夠透過建立這些明確的關係，將向量作為節點處理。」
自定義查詢語言引發討論
HelixDB 的自定義查詢語言引發了不同反應。一些使用者表達了對學習新領域特定語言(DSL)的擔憂，特別是關於將其用於 LLM 查詢生成的能力。開發者為這一選擇辯護，解釋說沒有現有語言能夠正確封裝圖譜和向量功能，他們希望建立一種型別安全的查詢語言。他們提到正在努力將其語法整合到 LLaMa 的 CPP 程式碼中，以確保 LLM 能夠生成語法正確的查詢。
瀏覽器相容性和嵌入式使用
幾位使用者詢問了透過 WebAssembly（WASM）在瀏覽器中執行 HelixDB 以實現隱私應用，以及將其用作類似 SQLite 的嵌入式資料庫的可能性。團隊承認，他們當前的儲存引擎 LMDB 是瀏覽器相容性的障礙，但提到他們計劃開發自己的支援 WASM 的儲存引擎。目前，HelixDB 不能作為嵌入式資料庫執行，這限制了一些潛在的使用場景。
路線圖專案
- 擴充套件向量資料型別功能，用於 RAG 應用
- 增強查詢語言，實現更強大的型別檢查
- 實施端到端查詢測試套件
- 構建確定性模擬測試引擎
- 新增二進位制量化以提高效能
- 實現 BM25 稀疏搜尋
- 開發自主圖形向量儲存引擎（替代 LMDB）
- 建立自主網路協議和序列化庫
未來發展和路線圖
HelixDB 團隊概述了幾個即將推出的功能，包括使用 BM25 進行稀疏搜尋，一些社群成員建議考慮 SPLADE 模型以增強搜尋能力。他們的路線圖還包括擴充套件向量功能、增強查詢語言、實施測試套件、構建確定性模擬測試引擎，並最終開發自己的圖譜向量儲存引擎來替代 LMDB。
隨著 HelixDB 進入日益競爭激烈的向量和圖譜資料庫領域，其效能宣告和結合這些功能的獨特方法確實引起了關注。社群似乎持謹慎樂觀態度，許多人表示有興趣嘗試該資料庫並提供反饋。HelixDB 如何從長期來看與已建立的參與者和其他新進入者區分開來仍有待觀察，但其對開發者體驗和人工智慧應用效能的關注似乎正在引起潛在使用者的共鳴。