semadbダウンロードsemadbソースコードのダウンロード

semadb

その他のソースコード

v2.0.2

ダウンロード

ファスマルチインデックスハイブリッドベクトルデータベース /検索エンジンはありません

SEMADBは、マルチインデックス、マルチベクトル、ドキュメントベースのベクトルデータベース /検索エンジンです。明確で使いやすいJSON Restful APIを提供するように設計されています。 SEMADBの元のコンポーネントは、Semafindでの知識管理プロジェクトのために構築され、その後スタンドアロンプロジェクトに開発されました。目標は、さまざまなアプリケーションで使用できるシンプルでモダンで効率的な検索エンジンを提供することです。

ホストされたソリューションをお探しですか？ SEMADBクラウドベータはRapidapiで入手できます。

特徴⚡

ベクトル検索：ベクトル検索のパワーを活用して、同様のアイテムを見つけてAIアプリケーションを構築します。 SEMADBは、グラフベースのVamana Algorithmを使用して、最近近隣の近隣検索を効率的に実行します。
キーワード /テキスト検索：キーワードやフレーズ、カテゴリ、タグなどに基づいてドキュメントを検索します。
GEOインデックス：緯度と経度またはGEOハッシュのいずれかを介してその場所に基づいてドキュメントを検索します。
マルチベクトル検索：複数のベクトルを同時に検索して、それぞれ独自のインデックスを持つ単一のドキュメントを検索します。
量子化されたベクトル検索：量子サイザーを使用して内部ベクトル表現を変更して、メモリ使用量を削減します。
ハイブリッド検索：ベクトルとキーワード検索を組み合わせて、単一の検索リクエストで最も関連性の高いドキュメントを見つけます。ウェイトを使用して、各検索タイプの重要性を調整します。
フィルター検索：他のクエリまたはメタデータに基づいてフィルター検索結果。
ハイブリッド、フィルター、マルチベクトル、マルチインデックス検索：上記のすべての検索タイプを1つのクエリで結合します。たとえば、「現在開いている最寄りのレストラン（GEOインデックス）を見つけて（反転インデックス）、4以上の評価（整数インデックス）を持ち、この画像に似た料理を提供し（ベクトル検索）、このテキストと同様の説明（ベクター検索）を持っています」。
Simple Rest API ：データベースと対話するための完全なJSONベースのRESTFUL API。新しいクエリ言語を学習する必要はありません。カスタムクライアントまたはライブラリをインストールしてください。
リアルタイム：変更はすぐに表示され、大規模なデータセットであっても、検索結果はミリ秒で返されます。
単一のバイナリ：データベース全体が単一のバイナリに含まれています。追加の依存関係やサービスをインストールする必要はありません。
複数の展開モード：スタンドアロン、コンテナ、またはクラウド。 SEMADBは、ニーズに合わせてさまざまな方法で展開できます。
Prometheusメトリック：検索ポイント数、検索の遅延、リクエスト数などのメトリックで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実行可能ファイルは、コンテナのマウントポイントとして/ Giving /dataにあります。

Dockerを使用する場合、IPSのホスト名とホワイトリストは、Dockerのネットワーク構成に応じて調整する必要がある場合があることに注意してください。ホスト名を空白の文字列として残し、 '*'にホワイトリストを設定すると、 singleServer.yaml構成で行われたように、すべての接続にSemadbが開きます。

貢献

貢献は大歓迎です！詳細については、寄稿ガイドファイルをお読みください。寄稿ガイドには、SEMADBのアーキテクチャと開発の開始方法に関する情報も含まれています。

アルゴリズムを検索しますか？

SEMADBのコアベクトル検索アルゴリズムは、次の優れた研究論文に基づいています。

Jayaram Subramanya、Suhas、et al。「Diskann：単一のノードでの10億ポイントの最近近隣検索が高速である」神経情報処理システムの進歩32（2019）リンク。
Singh、Aditi、et al。「FreshDiskann：ストリーミング類似性検索のための高速かつ正確なグラフベースのANNインデックス。」 Arxiv Preprint arxiv：2105.09613（2021）リンク。
Gollapudi、Siddharth、et al。「フィルター処理されたディスカン：フィルターを使用したおおよその最近傍検索のグラフアルゴリズム。」 ACM Web Conference2023。2023リンクの議事録。

文字列やテキストなどの他のインデックスは、倒立インデックスアプローチに従います。逆インデックスは、単語や数字などのコンテンツからデータベースファイル、ドキュメントまたはドキュメントのセットにあるコンテンツからマッピングを保存するデータ構造です。逆インデックスの目的は、高速のフルテキスト検索、文字列プレフィックスルックアップ、整数範囲検索などを許可することです。

パフォーマンス

Intel(R) Core(TM) i7-6700 CPU @ 3.40GHzコモディティワークステーションは、報告された結果と同様に、標準ベンチマーク全体で良いリコールを実現します。

	V1		V2		v2-pq		V2-BQ
データセット	想起	QPS	想起	QPS	想起	QPS	想起	QPS
Glove-100-Angular	0.924	973.6	0.853	773.9	0.526	628.6
dbpedia-openai-100k-angular			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

結果は、アンベンチマークを使用して取得されます。クエリあたりのクエリ（QPS）は、他のメソッドと同様の単一のスレッドでメモリキャッシュを完全に使用しますが、全体的なパフォーマンスの適切な兆候ではありません。リクエストのエンドツーエンドの旅のため、完全なパイプラインは遅くなります。HTTP処理、エンコード、解析、解析、検証、クラスタールーティング、リモート手順呼び出し、ディスクからのデータの読み込みなどのオーバーヘッドがあります。これは、ハードウェア、特にSSD対ハードディスクにさらに依存します。ただし、単一のシャード内の検索アルゴリズムの生のパフォーマンスは、理論的には、研究論文で報告されているものと似ています。

バージョン1（V1）は、SEMADBの元の純粋なベクトル検索実装です。バージョン2（V2）は、マルチインデックス、ハイブリッド、キーワード検索などの実装であり、デコードのオーバーヘッド、インデックスへのデータの派遣、量子化器の使用のオーバーヘッドがはるかに高くなっています。製品量子量化（V2-PQ）とバイナリ量子化（V2-BQ）を備えたバージョン2それぞれの量子化方法を使用して、メモリ使用量を削減します。量子化方法が損失し、検索が近似しているため、リコールが低くなると予想されます。

制限？

コールドディスクの起動は本当に遅い場合があります。チェーンの下部には、すべてのデータが保存されるディスクがあります。プレイには2つのキャッシュがあります：インメモリキャッシュとオペレーティングシステムファイルキャッシュ。 OSキャッシュは私たちのコントロールにありませんが、ファイルが読み取られたり書かれたりすると、入力されます。リクエストが行われると、インデックスグラフが移動し、ポイントがディスクからオペレーティングシステムキャッシュにロードされ、メモリ内のポイントセットにデコードされます。検索操作は、類似性グラフを通過する際にディスクからランダムな読み取りを実行することがよくあります。したがって、コールドスタート中は、ハードウェアに応じて長い時間（1秒、10秒以上）かかる場合があります。ソリッドステートディスク（SSD）は、ランダムな読み取りをより良く提供するため、このために強くお勧めします。単一のアプリケーションの展開の場合、これは、操作中にデータ /インデックスの一部がメモリまたはオペレーティングシステムによってキャッシュされると予想されるため、大きな懸念ではありません。別の方法は、カスタムグラフ指向のストレージレイアウトをディスクに使用して、ブロック /ページを類似グラフのノードのネイバーとより適切に整合することです。

自動水平スケーリング：SEMADBのサーバーの数は調整できますが、起動と同期するだけです。使用されるRendezvousハッシュは、1/nのデータを新しいサーバーに移動するか、削除されたサーバーデータを残りのサーバーに戻します。これはスタートアップでのみ発生するため、ライブ負荷よりも事前に展開を事前にスケーリングまたはダウンすることに向けられています。ライブ自動スケーリングは、サーバー全体のレース条件のためにデータベースが動作している間、安全に実行するのが難しいです。いくつかの落とし穴は次のとおりです。構成が古いサーバーにデータを送信する構成に遅れをとっているサーバー、データ転送は行われているが、ユーザー要求を処理する必要がありますが、誤ったルーティングされたデータは最終的に正しいサーバーに到達する必要があります。多くの分散データベースには、バージョンされたキー、ベクトルクロックなど、これらのハンドルに大きな複雑さを加える追加の機械が組み込まれています。現時点では、サーバーを調整してクラスターを再起動してデータを再配布することができます。

書き込みはありません。収集およびポイント書き込み操作には、関与するすべての関係（分散データ）が必要です。検索パスでは、障害は確率的検索であり、利用できないシャードによるパフォーマンスの時折の低下であるため、障害を許容することができます。物理的なサーバーの障害を介して健康なシステムを維持して、Kubernetesなどのコンテナオーケストレーションツールにオフロードします。 SEMADBの構成された状態が積極的に維持され、その結果、設計にピア発見またはコンセンサスアルゴリズムが含まれていないと仮定します。この設計の選択により、SEMADBとAIDSのアーキテクチャが急速に発展します。オリジナルの設計には、ラフトなどのコンセンサスメカニズムや、ピアディスカバリーを備えた完全に自己完結型の分散システムが含まれていましたが、これはやり過ぎと見なされました。