Chroma と Milvus の比較

どちらもベクトルDB / ストレージに分類しています。数値はGitHub APIから取得したもので、評価は本サイトによるものです。

基本情報の比較

検索を動かすまでの摩擦が最も少ない選択肢です。サーバーの構築もクラスタのサイジングも不要です。そのためプロトタイプや小規模な本番負荷には非常に適しています。一方で、どの規模で手狭になるかは、遭遇してから慌てるのではなく事前に計画しておくべき論点です。

ストレージと計算を分離し、インデックス構築とクエリを独立にスケールさせる設計です。数十億ベクトル規模で必要になるアーキテクチャがここにあります。その能力は運用負荷と引き換えであり、数百万ベクトル未満の規模ではより単純な選択肢のほうが適しています。

1ファイルで検索を動かす — chromadb.Client()でインメモリのクライアントを作り、collection.add()に文書を渡せばトークン化・埋め込み・インデックス作成まで自動で行われます。
メタデータ条件を同じクエリで併用 — collection.query()はwhereによるメタデータの絞り込みと、where_documentの$containsによる本文の部分一致を同じ呼び出しで指定できます。
クライアントサーバー構成へ移行 — chroma run --path /chroma_db_pathを実行するとサーバーモードで起動し、単一プロセスで足りなくなってもAPIは変えずに済みます。
PythonとJavaScriptの双方から参照 — Pythonクライアントはpip install chromadb、JavaScriptクライアントはnpm install chromadbで導入し、同じchroma runのサーバーに接続すれば同一のコレクションを読み書きできます。書き込む側と検索する側で言語を揃える必要がありません。

サーバーを立てずに試す — pymilvus[milvus-lite]を入れてMilvusClientにローカルファイル名を渡せば単体で動き、uriとtokenを差し替えるだけで自ホストのクラスタやZilliz Cloudへ接続先を移せます。
全文検索とベクトル検索を併用 — 同一コレクションに疎ベクトルと密ベクトルを格納でき、BM25による全文検索やSPLADE、BGE-M3などの学習済み疎埋め込みの結果をrerank関数で統合できます。
用途に合わせてインデックスを選ぶ — HNSW、IVF、FLAT、SCANN、DiskANNに加え、IVFPQなどの量子化やmmap、NVIDIA CAGRAによるGPUインデックスまで選択できます。
読み取りと書き込みを別々に増強 — 計算とストレージが分離されているため、読み取り中心の負荷にはquery node、書き込み中心の負荷にはdata nodeを個別に追加でき、レプリカで耐障害性も高められます。
1クラスタでテナントを分離 — database、collection、partition、partition keyの各粒度で分離を設定でき、RBACとTLS、ホットデータをメモリやSSDに置くホット/コールド階層を組み合わせて運用します。