Milvusとは何かCNCFが育てる大規模ベクトルDB

2026年6月3日

MilvusはZilliz社が2019年に公開し、現在はCNCF（Cloud Native Computing Foundation）のインキュベーションプロジェクトとなっているオープンソースのベクトルデータベースです。コンピュート、ストレージ、メタデータを分離したクラウドネイティブ志向のアーキテクチャを採用し、10億〜100億ベクトル規模の検索を視野に入れた設計が大きな特徴で、Kubernetes前提の運用にもなじむ作りになっています。本稿ではMilvusのコンポーネント構成と、規模化のためのインデックス選択を整理します。

この記事の目次

分離アーキテクチャの全体像
多彩なインデックスとGPU対応
ハイブリッド検索とスパースベクトル
運用上の注意とエコシステム
まとめ

分離アーキテクチャの全体像

Milvusは「Access Layer」「Coordinator Service」「Worker Node」「Storage」の四層構造を取ります。クエリはproxyが受け取り、rootcoord/querycoord/datacoordがそれぞれメタデータ、検索ノード、データノードを調整し、実体はMinIOやS3互換オブジェクトストレージとetcd、Pulsar/Kafkaに保持されます。この分離により、書き込みワークロードと検索ワークロードを独立にスケールできる点が他のモノリシックなベクトルDBと一線を画します。

v2.4以降はインメモリ専用のMilvus Lite、シングルバイナリ向けのStandalone、本格運用向けのClusterという三モードを提供し、PoCから本番までを段階的に進められる構成になりました。Zillizが提供するマネージドサービスZilliz Cloudでは、サーバレス型のクラスタも選択でき、ピーク時だけ計算ノードをスケールアウトする運用がやりやすくなっています。

多彩なインデックスとGPU対応

Milvusの強みはインデックスの種類の多さで、HNSW、IVF_FLAT、IVF_PQ、IVF_SQ8、DISKANN、SCANN、そしてGPU専用のGPU_IVF_FLAT、GPU_CAGRAなどを切り替えられます。NVIDIA RAPIDSと共同開発したCAGRAインデックスは、グラフ系インデックスをGPU上で構築・検索する設計で、数億ベクトル規模でも数ミリ秒の応答を狙えます。

DISKANNのようなディスク主導インデックスはSSD上に大半のデータを置きつつメモリ使用量を抑えられるため、コストを重視するワークロードに適します。コレクションを分割するパーティション機能、テナント単位で分けるデータベース機能と組み合わせ、用途に応じて最適なインデックスを使い分けられる柔軟性がMilvusならではの強みです。

ハイブリッド検索とスパースベクトル

Milvusはv2.4でスパースベクトルをファーストクラスでサポートし、SPLADEやBM25由来の疎な表現と密な埋め込みを同一コレクション内に保持できるようになりました。hybrid_searchAPIは複数のベクトルフィールドを並行検索し、RRFや重み付き平均で結果を融合する設計で、語彙的一致と意味的一致のバランスを取りやすい構造です。

また、JSONフィールドや動的フィールドの導入により、ベクトル本体に紐づくメタデータを事前スキーマなしに格納でき、ECサイトの属性検索や、エンタープライズ文書検索の細かい属性指定にも対応しやすくなっています。属性インデックスとベクトルインデックスをまたぐクエリオプティマイザもバージョンを重ねるごとに洗練されており、大規模データセットでもフィルタ付きクエリのレイテンシが安定しやすい設計です。

運用上の注意とエコシステム

クラスタモードのMilvusはコンポーネント数が多いため、KubernetesのオペレータやHelmチャートを使った宣言的なデプロイが推奨されます。etcdの世代管理、Pulsarのトピック数、オブジェクトストレージのスループットといった周辺コンポーネントの監視が運用品質を大きく左右する点はLong-running運用での要注意ポイントです。

エコシステムとしてはLangChain、LlamaIndex、Haystackといった主要RAGフレームワークが公式コネクタを提供し、Attu/Birdwatcherといった管理GUIも整備されています。競合のWeaviateやQdrantと比較すると、Milvusは「最大規模での運用実績」と「インデックスの選択肢の広さ」が突出しており、エンタープライズ検索のバックエンドとして採用されるケースが目立ちます。