オープンソースプロジェクト
milvus-io/milvus avatar
milvus-io/milvus

Milvusをベクトル検索の規模と配置方式から見極める

Milvus は Go と C++ で書かれたクラウドネイティブなベクトルデータベースで、数十億のベクトルに対するスケーラブルな近似最近傍探索を実現し、CPU/GPU アクセラレーションとリアルタイムのストリーミング更新に対応します。

スター 46,119フォーク 4,252GoApache-2.0

ひと目でわかる

これは何?
Milvusの分散アーキテクチャ、Milvus Lite、インデックス、マルチテナンシーをREADMEの具体例から整理します。
誰に向いている?
Milvusはテキスト、画像、マルチモーダル情報をベクトルとして検索し、規模に応じて構成を変えたいチーム向けです。単一マシンの概念実証ならMilvus Lite、運用クラスタならStandaloneや分散構成を選びます。
商用利用できる?
できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。直近 1 日以内に新しいコミットがあります。
何の言語で書かれている?
主に Go です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

768次元コレクションから始める

READMEはMilvusを大規模なベクトル検索のためのデータベースと説明しています。GoとC++で書かれ、CPUとGPUのハードウェアアクセラレーションを実装しています。対象はテキスト、画像、マルチモーダル情報のような非構造化データで、ベクトルと整数、文字列、JSONなどのスカラー値を一緒に扱う設計です。

Quickstartではpip install -U pymilvusでPython SDKを入れ、MilvusClientを作ります。例ではdimension=768のdemo_collectionを作り、insertでデータを投入し、embedding_fn.encode_queriesの結果をsearchへ渡しています。limitやoutput_fieldsを指定する流れまで示されているため、最初の試験では埋め込みモデル、次元数、返却フィールドを固定して検索結果を比較できます。

LiteとStandaloneを使い分ける

Milvus Liteはpymilvus[milvus-lite]で試せる軽量版です。client = MilvusClient("milvus_demo.db")のようにローカルファイル名を渡してデータを永続化する例がREADMEにあります。Pythonで検索処理の形を確かめたい段階では、この構成がサーバー管理を増やさずに済みます。

単一マシンの配置にはStandalone modeも用意されています。分散クラスタと同じ前提で考えると、Liteのファイル利用とStandaloneのサービス利用を取り違えます。どちらを選ぶかは、検索APIの確認だけか、複数プロセスからの接続、障害時の復旧、データ量の増加まで扱うかで決めます。READMEはStandalone Dockerの手順へリンクしていますが、ここにない運用値は公式ドキュメントで確認します。

検索ノードとデータノードを分ける

READMEが説明する分散構成は、computeとstorageを分離します。読み取りが多い場合はquery node、書き込みが多い場合はdata nodeを個別に増やせるため、負荷の種類に応じて拡張する考え方です。Kubernetesネイティブのstateless microservicesと、障害後の回復、複数query nodeへのレプリカ配置も説明されています。

この説明から高可用性を自動的に保証できるわけではありません。クラスタ構成、永続ストレージ、レプリカ数、監視は実際のデプロイ仕様に依存します。まず小規模なKubernetes環境で、書き込み中のquery、ノード再起動後のコレクション状態、再ロード時間を確認し、READMEの構成概念と実際の挙動を対応づける必要があります。

HNSWからDiskANNまでの選択

MilvusはHNSW、IVF、FLAT、SCANN、DiskANNなど複数のベクトルインデックスを扱います。量子化を用いるIVFPQやmmap、メタデータフィルタ、range searchもREADMEから確認できます。全件に近い検索を行うFLATと、検索速度やメモリ消費を調整する近似方式では、同じデータでも設計上の交換条件が変わります。

GPU indexingではNVIDIAのCAGRAへのリンクも示されています。ただしREADMEの「best-in-class」という表現はプロジェクト側の説明です。データの次元、分布、topK、フィルタ条件、更新頻度を固定して、検索品質とレイテンシを自分のデータで測るまでは、インデックス名だけで選定してはいけません。

テナント境界とhot/cold storage

READMEにはdatabase、collection、partition、partition keyの各レベルでマルチテナンシーを分離する方式が記載されています。単一クラスタに複数利用者を収容する場合でも、どの境界でデータを分け、検索時にどの条件を付けるかを決められます。アクセス制御の粒度と検索性能は、選んだ方式およびクエリの書き方に結びつきます。

頻繁に使うhot dataをメモリやSSDへ置き、低頻度のcold dataと分けるhot/cold storageも説明されています。コスト削減という言葉だけを先に採用せず、利用頻度の分類、移動条件、検索対象から外れた時の応答を確認します。READMEに数値基準はないため、保持期間とテナント別の負荷を用意した試験が必要です。

Apache 2.0と運用の確認点

MilvusのオープンソースプロジェクトはLF AI & Data Foundationの下にあり、Zillizが主要な貢献者とREADMEに記載されています。ライセンスはApache 2.0です。Zilliz CloudにはServerless、Dedicated、BYOCの選択肢が案内されていますが、管理サービスの契約やデータの所在はOSS本体の説明とは分けて確認します。

素材のreleaseにはv2.6.23、v2.6.22、v3.0.0が含まれ、更新系列が複数あります。固定した版でpymilvusの接続、認証token、collection作成、insert、searchを実行し、SDKとサーバーの対応を記録してください。READMEは性能比較へのリンクを提供しますが、そこで示されるベンチマークを自環境の保証値として扱うことはできません。

検索品質を入力データで測る

Milvusの採用試験では、同じembeddingと768次元のcollectionをLiteで作り、次にStandaloneへ移します。insert件数、searchのtopK、output_fields、metadata filterを保存し、サーバー構成だけを変えた時の差を見ます。tenantをcollectionとpartition keyの二方式で分け、誤ったtenant条件が結果へ混ざらないことを確認します。インデックスをFLAT、HNSW、DiskANNの順に試す場合も、検索速度だけでなく近似結果の欠落、更新後の可視性、再起動後のデータを同じ表で比べます。Milvus Liteのmilvus_demo.dbをコピーして再読込し、ローカルファイルの永続化とサーバー側の認証接続を同じAPI呼び出しで比較します。

編集部の結論

Milvusはテキスト、画像、マルチモーダル情報をベクトルとして検索し、規模に応じて構成を変えたいチーム向けです。単一マシンの概念実証ならMilvus Lite、運用クラスタならStandaloneや分散構成を選びます。採用前にpymilvusで768次元のコレクションを作り、insertとsearchの結果、メタデータフィルタ、データ保存先を同じ入力で確認してください。

公式情報源

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
コミュニティノート

コミュニティノート