semadb下載 - semadb源代碼下載

semadb

其他源碼

v2.0.2

下載

沒有大驚小怪的多指數混合矢量數據庫 /搜索引擎

SEMADB是一種多指數，多矢量，基於文檔的矢量數據庫 /搜索引擎。它旨在提供清晰易用的JSON RESTFUL API。 SEMADB的原始組件是為Semafind的一個知識管理項目而建立的，然後才將其發展為獨立項目。目的是提供一個簡單，現代，高效的搜索引擎，可用於各種應用程序。

尋找託管解決方案？ SemadB Cloud Beta可以在RapidApi上找到。

功能⚡

向量搜索：利用向量搜索的功能找到相似的項目並構建AI應用程序。 SEMADB使用基於圖的VAMANA算法來執行有效的近似鄰居搜索。
關鍵字 /文本搜索：基於關鍵字或短語，類別，標籤等的文檔搜索
地理指數：根據其位置搜索通過緯度和經度或地理哈希的位置搜索文檔。
多向量搜索：同時跨多個向量搜索每個文檔，每個文檔都有自己的索引。
量化矢量搜索：使用量化器更改內部向量表示以減少內存使用情況。
混合搜索：組合向量和關鍵字搜索以在單個搜索請求中找到最相關的文檔。使用權重調整每種搜索類型的重要性。
過濾搜索：基於其他查詢或元數據的過濾搜索結果。
混合，過濾器，多向量，多指數搜索：將上述所有搜索類型組合在單個查詢中。例如，“找到我的最近的餐廳（GEO索引），這些餐廳（倒數索引）的評分為4個或更多（整數索引），並提供與此圖像相似的菜餚（向量搜索），並且具有與此文本（矢量搜索）相似的描述”。
簡單的REST API ：完全基於JSON的，用於與數據庫進行交互的RESTFUL API。無需學習新的查詢語言，安裝自定義客戶端或庫。
實時：立即可見更改，即使對於大型數據集，搜索結果也會以毫秒為單位返回。
單個二進制：整個數據庫包含在單個二進制中。無需安裝其他依賴項或服務。
多個部署模式：獨立，容器或云。 SEMADB可以通過多種滿足您需求的方式部署。
普羅米修斯指標：通過搜索點數，搜索延遲，請求數量等，監視SEMADB的健康狀況。
群集模式：將數據分配給多個服務器並將搜索分配給所有參與機器的地方。
自動損失：基於哈希算法的多個服務器自動碎片數據。
多租戶：具有不同計劃的多個用戶可以使用相同的SEMADB實例。每個用戶都可以擁有自己的收藏和索引。
清晰的源代碼：目標是允許任何人選擇一個隨機文件，並希望了解發生了什麼。有些文件的評論多於代碼。

入門

要從源頭開始，請按照說明進行安裝。這是運行SEMADB所需的唯一依賴關係。我們試圖使SemadB盡可能地保持獨立，並與最新的GO版本保持最新。

SEMADB從YAML文件中讀取所有配置， config夾中包含一些示例。您可以使用：

SEMADB_CONFIG=./config/singleServer.yaml go run ./

如果您使用VS代碼作為編輯器，則已經有預先製作的任務可以執行相同的操作，但也可以在調試模式下在本地啟動集群。

運行服務器後，您可以使用示例文件查看可以向服務器提出的一些示例請求。要充分利用它，請安裝REST客戶端擴展名，該擴展名使您可以直接在編輯器中提出請求並顯示結果。

Docker＆Podman

您可以使用以下存儲庫容器映像運行最新版本的SEMADB：

docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:main

它將運行主分支。還有針對特定版本的標籤版本。請參閱存儲庫穩定和生產準備版本的容器註冊表。

您可以在本地構建和運行容器圖像：

docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb

數據持久性： SEMADB將數據存儲在磁盤上的目錄中，該目錄在配置文件中指定為rootDir 。默認情況下，數據目錄為./data ，並且semadb可執行文件位於/給出/data作為容器中的安裝點。

請注意，使用Docker時，可能需要根據Docker的網絡配置來調整IPS的主機名和白名單。將主機名作為空白字符串和將白色列入'*'設置為“*”為singleServer.yaml配置中完成的每個連接打開semadb。

貢獻

歡迎捐款！請閱讀貢獻指南文件以獲取更多信息。貢獻指南還包含有關SemadB架構以及如何開始開發的信息。

搜索算法？

SEMADB的核心矢量搜索算法基於以下出色的研究論文：

Jayaram Subramanya，Suhas等。 “ Diskann：在一個節點上快速準確的十億點最近鄰居搜索。”神經信息處理系統的進步32（2019）鏈接。
辛格，阿迪蒂等。 “ FreshDiskann：用於流式傳輸相似性搜索的快速準確的基於圖的ANN索引。” ARXIV預印型ARXIV：2105.09613（2021）鏈接。
Gollapudi，Siddharth等。 “過濾 - 迪斯克安：圖形算法，用於用過濾器的大約最近的鄰居搜索。” ACM網絡會議論文集，2023。2023鏈接。

其他索引（例如字符串或文本）遵循倒置索引方法。倒置索引是一個數據結構，該數據結構將內容（例如單詞或數字）存儲到數據庫文件中的位置，或在文檔或一組文檔中。倒置索引的目的是允許快速全文搜索，字符串前綴查找，整數範圍搜索等。

表現

SEMADB具有Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz商品工作站，帶有16GB RAM的SEMADB在標準基準中獲得了良好的召回率，類似於報告的結果：

	V1		v2		V2-PQ		V2-BQ
數據集	記起	QPS	記起	QPS	記起	QPS	記起	QPS
手套100角	0.924	973.6	0.853	773.9	0.526	628.6
DBPEDIA-OPENAI-100K角			0.990	519.9	0.920	240.8	0.766	978.6
手套25角	0.999	1130.3	0.992	914.4	0.989	805.8
Mnist-784-Euclidean	0.999	1898.6	0.999	1267.4	0.928	571.6	0.667	2369.7
NYTIMES-256角	0.903	1020.6	0.891	786.7	0.438	983.6
SIFT-128-EUCLIDEAN	0.999	1537.7	0.991	1272.9	0.696	967.4

結果是使用ANN基準獲得的。每秒（QPS）的查詢在內存緩存中使用，其單個線程類似於其他方法，但並不能很好地表明整體性能。完整的管道將較慢，因為請求的端到端旅程具有HTTP處理，編碼，查詢，解析，驗證，驗證，群集路由，遠程過程調用，磁盤加載數據的開銷。但是，從理論上講，單個碎片中搜索算法的原始性能與研究論文中報導的相似。

版本1（V1）是SEMADB的原始純矢量搜索實現。版本2（v2）是多指數，混合，關鍵字搜索等實現的實現，它具有更高的解碼開銷，將數據派遣到索引和使用量化器。使用產品量化（V2-PQ）和二進制量化（V2-BQ）的版本2使用相應的量化方法來減少內存使用量。我們希望召回率較低，因為量化方法是有損的，搜索是近似的。

限制？

冷磁盤啟動可能真的很慢。鏈的底部位於所有數據存儲的磁盤上。有兩個緩存：內存中緩存和操作系統文件緩存。 OS緩存不在我們的控制中，並且在讀取或寫入文件時被填充。提出請求後，索引圖將遍歷，並將點從磁盤加載到操作系統緩存，並解碼為內存中的點集。搜索操作通常會從磁盤上執行隨機讀取，因為它遍歷相似性圖。因此，在冷啟動過程中，根據硬件的不同，可能需要很長時間（1秒，10秒或更長時間）。因此，強烈建議使用固態磁盤（SSD），因為它們提供隨機讀數更好。對於單個應用程序部署，這不是主要問題，因為我們期望在操作過程中將一部分數據 /索引在內存或操作系統中緩存。另一種選擇是在磁盤上使用定製圖形的存儲佈局，以便更好地與相似性圖中的節點的鄰居保持一致。

自動水平縮放：可以調整SEMADB中的服務器數量，但僅在啟動時同步。使用的會合散列將移動1/n的數據量轉移到新服務器，或將刪除的服務器數據移回其餘數據。由於這僅在啟動時發生，因此它更旨在提前或在活載荷下進行擴展。由於跨服務器的競賽條件，實時自動縮放量很難安全地執行。一些陷阱是：在配置方面落後的服務器將數據發送到舊服務器，而數據傳輸進行了用戶請求，必須處理用戶請求，任何錯誤路由的數據最終都必須到達正確的服務器，如果網絡分配了網絡，則必須從拆分腦場景中恢復。許多分佈式數據庫都包含其他機械，這些機械添加了處理這些功能的重大復雜性，例如版本的鍵，向量時鐘等。目前，您可以調整服務器並重新啟動群集以重新分發數據。

無需寫高可用性：SEMADB已針對搜索繁重的工作負載進行了優化。收集和點寫操作需要所有涉及的（已分發數據的服務器）才能參與。在搜索路徑中，可以容忍故障，因為它是隨機搜索，並且由於無法可用的碎片而偶爾會下降性能。我們卸載在物理服務器中保持健康的系統故障，以至於Kubernetes等容器編排工具。我們假設SEMADB的配置狀態將被積極維護，因此，設計中不包含設計中的任何同伴發現或共識算法。這種設計選擇再次簡化了SEMADB和AIDS的架構，並隨著快速發展而進行。原始設計包括與同行發現的共識機制，例如Raft和完全獨立的分佈式系統，但這被認為是過度的。