AIアプリケーションに適したMilvusデプロイメントモードの選択方法
Milvusは、オープンソースのベクトルデータベースであり、10億スケールのベクトル埋め込みを保存、索引付け、検索する。また、大規模言語モデル(LLMsにおける幻覚の問題を軽減するための一般的かつ効果的な手法である、検索拡張生成(RAG)の不可欠なコンポーネントでもある。)
Qdrant](https://zilliz.com/comparison/milvus-vs-qdrant)、Weaviate、Chromaのような他のオープンソースのベクトル検索プロジェクトとは異なり、Milvusは、データセットのサイズ、ユースケース、ビジネス要件に応じた3つの主要な導入オプションを開発者に提供しています。複数の選択肢があることはメリットであるが、一方で少々圧倒されることもある。多くの開発者は、特定のAIアプリケーションに最適なデプロイメント・モードを選択する方法がわからない。このブログポストでは、プロジェクトに適したMilvusバージョンを選択するための明確で詳細なガイドを提供します。
Milvus Lite vs. スタンドアロン vs. 分散
Milvusには3つのデプロイオプションがあります:Milvus Lite、スタンドアロン、分散**..
Milvusライト
Milvus LiteはPythonライブラリであり、Milvusの超軽量版です。Pythonやノートブック環境でのラピッドプロトタイピングや小規模なローカル実験に最適です。pip install pymilvusと実行するだけで、pymilvus` パッケージから直接インストールできます。別のサーバーを起動する必要はなく、ローカルファイルを使ってデータの永続化を行うので、セットアップも使用も簡単である。
Milvus スタンドアロン
Milvus StandaloneはMilvusのシングルノード展開オプションであり、クライアントサーバモデルを使用します。MilvusはMySQLに相当し、Milvus LiteはSQLiteに相当します。すべてのMilvus StandaloneコンポーネントはDockerイメージにバンドルされているため、サーバデプロイは簡単です。十分なメモリを持つマシン上で単一のMilvus Standaloneインスタンスを実行することで、大規模なスケーリングを必要としないほとんどのプロジェクトでうまく機能する。さらに、Milvus Standaloneはプライマリバックアップモードにより高可用性を提供し、本番環境において信頼できる選択肢となります。
Milvus Distributed
Milvus DistributedはMilvusの分散モードで、大規模なベクターデータベースシステムやベクターデータプラットフォームを構築するエンタープライズユーザーに最適です。クラウドネイティブアーキテクチャを採用し、パフォーマンスを最適化するために読み書き分離が可能です。Milvus Distributedの主要コンポーネントには、ビルトインのバックアップと追加インスタンスが装備されているため、1つのパーツに障害が発生しても、他のパーツがシームレスに引き継ぐことができ、システムが中断されることはありません。このレベルの冗長性は信頼性を高め、継続的可用性を保証します。3つの導入オプションの中で、Milvus Distributedは最も高いスケーラビリティと可用性を提供する。また、コンポーネントレベルの弾力性も備えており、Proxy、クエリノード、インデックスノードを特定のビジネス負荷要件に基づいて個別に拡張することができます。
以下の表は、Milvus Lite、Milvus Standalone、Milvus Distributedの主な機能を要約し、比較したものです。
| Milvus Lite | Milvus Standalone | Milvus Distributed | SDK | Python | |
| Python、Go、Java、Node.js、C#、RESTful|Python、Go、Java、Node.js、C#、RESTful|SDK|Python|Python、Go、Java、Node.js、C#、RESTful | |||||
| データ型**|密ベクトル 疎ベクトル 2値ベクトル ブール型スカラー 整数型スカラー フロート型スカラー 文字列配列 JSON|密ベクトル 疎ベクトル 2値ベクトル ブール型スカラー 整数型スカラー フロート型スカラー 文字列配列 JSON|密ベクトル 疎ベクトル 2値ベクトル ブール型スカラー 整数型スカラー フロート型スカラー 文字列配列 JSON|密ベクトル 疎ベクトル 2値ベクトル ブール型スカラー 整数型スカラー フロート型スカラー 文字列配列 JSON | |||||
| 検索 | ベクトル検索(ANN検索)フィルタリングされたベクトル検索範囲検索ハイブリッド検索スカラー式クエリ プライマリ・キー・クエリ(取得) | ベクトル検索(ANN検索)フィルタリングされたベクトル検索範囲検索ハイブリッド検索スカラー式クエリ プライマリ・キー・クエリ(取得) | ベクトル検索(ANN検索)フィルタリングされたベクトル検索範囲検索ハイブリッド検索スカラー式クエリ プライマリ・キー・クエリ(取得) | **基本的なCRUD | |
| 基本的なCRUD機能** | ✔️ | ✔️ | ✔️ | ||
| RBAC (ロール・ベースのアクセス制御) シャーディング パーティション パーティション・キー 物理リソースのグルーピング | |||||
| 物理リソースのグループ化| Consistency| 強い| 強い境界の陳腐化 セッションの最終的な| 強い境界の陳腐化 セッションの最終的な| Consistency| 強い| 強い境界の陳腐化 セッションの最終的な |
表Milvus Lite、Milvus Standalone、Milvus Distributed_ の比較
各開発段階に適したMilvus導入の選択方法
適切なMilvusデプロイメントオプションの選択は、アプリケーションの開発ステージによって異なります。これらのステージには、ラピッドプロトタイピング、初期本番デプロイメント、大規模本番デプロイメントが含まれます。各ステージについて詳しく見ていきましょう。
AIアプリケーションのラピッドプロトタイピングのためのMilvus Lite
パーソナルアシスタント、セマンティック検索エンジン、またはエンドツーエンドのRAGのようなAIアプリケーションを開発し、プロトタイピングする場合、通常、アプリの速度と柔軟性は、パフォーマンスや安定性よりも優先されます。そのため、Milvus Liteは現段階では理想的な選択肢です。ノートブック環境内でエンドツーエンドの機能を素早く構築し、有効性のテストに重点を置いた軽量な実験を行うことができます。
大規模データセットでの検証のためのMilvusスタンドアロンへの移行
Milvus Standaloneは、大規模なデータセットで結果を検証する必要がある場合の次の論理的なステップです。Milvus Liteとスタンドアロンはシームレスに連動するように設計されており、ローカルでのプロトタイピングからサーバーベースの検証への移行が容易です。Milvus Lite、Standalone、Distributedは同じクライアントインターフェースを共有しているため、ローカルでも大規模データ検証でも同じビジネスロジックを再利用することができます。さらに、Milvus Standaloneは複数ユーザをサポートしているため、アジャイル開発チームが単一のインスタンスを使用して共同作業を行ったり、データを共有したりすることが容易になります。
Milvus Standaloneの早期本番導入に向けて
アプリ制作の初期段階では、プロジェクトが立ち上げられたばかりで、まだ製品市場適合性を見出していないため、ビジネスリクエストやデータ量は比較的少ないです。インフラよりも、ビジネスの有効性と競争力に焦点を当てる必要があります。Milvus Standaloneはこのフェーズに適しています。オンラインサービスの場合、Milvusを高可用性のプライマリバックアップモードで展開することで信頼性を確保できます。テスト環境の場合、通常はシングルノードの展開で十分です。
注意: Milvus Standalone はテーブル間の物理リソースの分離を提供しません。クリティカルでパフォーマンス重視のアプリケーションが2つある場合は、別々の Milvus Standalone インスタンスを使用してデータを分離する方が良いでしょう。これはリソースの非効率化につながるかもしれませんが、現段階ではMilvus分散セットアップを管理するよりも費用対効果が高いことに変わりはありません。
特定のデバッグタスクのためにMilvus Liteを使用し続けることは可能ですが、Milvus Standaloneがデプロイされている本番環境での使用はパフォーマンスおよび安定性のリスクをもたらす可能性があるため避けてください。
大規模本番環境へのMilvus Distributedの導入
データが1台のサーバで処理しきれなくなったり、急速に拡大したりした場合、将来のスケーラビリティに備える必要があります。この段階では、Milvus Distributed が不可欠となります。
このベストプラクティスでは、当初はMilvus StandaloneとMilvus Distributedの両インスタンスを同時に稼働させ、徐々にデータトラフィックをStandaloneからDistributedにシフトさせていきます。Milvus Distributedが安定稼働するまで、少なくとも1ヶ月はシステムを監視するようにしてください。
このフェーズでは、運用管理の強化も必要になります。Milvus DistributedはPrometheusをネイティブサポートしており、Attuのような管理ツールを提供しています。Milvusは幅広い専用の運用ツールやエコシステム統合を提供していますが、大規模な分散システムを管理することは困難です。オープンで活発なMilvusコミュニティに参加し、サポートを求めたり、コードを提供したり、イベントに参加したり、その他多くの貴重な貢献をすることをお勧めします。
ベクターデータセットのための適切な配置を選択する方法
Milvusはプロジェクトに合わせて拡張できるように設計されており、データセットの発展的な需要に合わせて様々なデプロイメントモードを提供しています。ここでは、Milvus Lite、Standalone、Distributedの違いを明確にするために、Milvus Lite、Standalone、Distributedをそれぞれと比較し、さらに重要な点として、Chroma、Weaviate(https://zilliz.com/comparison/milvus-vs-weaviate)、Qdrant(https://zilliz.com/comparison/milvus-vs-qdrant)のような市場にある他のオープンソースベクターデータベースと比較する方法を説明します。
Chroma**は、昨年から開発者の間で、特に小規模なプロジェクト向けに人気を集めています。Milvus Lite**と同様、Chromaは軽量なベクトル・データベースである。数十万以下のベクターを扱うアプリケーションに最適です。Chromaは、ベクターデータの挿入や類似検索などの基本的な機能を備えており、迅速なプロトタイピングのための軽量なオプションとなっている。しかし、その限定された機能セットと生産準備の欠如は、Milvus Liteでさえ、より堅牢な機能を提供することを意味します。
生産準備の整ったソリューションとしては、Milvus StandaloneとDistributed、そしてWeaviateとQdrantがより強力な選択肢となります。WeaviateはAIアプリケーションとの統合でよく知られており、様々なアップストリームモデルをネイティブサポートしています。一方、Qdrantは、ベクトル検索性能に重点を置いたコアベクターデータベース機能に焦点を当てている。しかし、オープンソースのベクトルデータベースベンチマークツールであるVectorDBBenchによると、Milvusは検索性能でQdrantを上回っており、この分野でのトップコンテンダーとなっている。
以下は、各ベクターデータベースに適したデータスケールの内訳である:
図2- ベクトルの保存と検索におけるMilvus対Chroma対Qdrant対Weaviate](https://assets.zilliz.com/Figure_2_Milvus_vs_Chroma_vs_Qdrant_vs_Weaviate_for_vector_storage_and_retrieval_5877bdd81a.png)
Milvus LiteとChromaは、最大100万ベクター**のデータスケーリングに最適です。使いやすさを追求し、シンプルさのためにシステム機能を犠牲にしています。
Milvusスタンドアロン、Weaviate、Qdrant**:100万から数千万ベクトルまでのデータ規模に最適。これらのデータベースは、強力なシステム機能と使いやすさのバランスが取れており、初期段階の生産に適している。
Milvus Distributed**:数千万からそれ以上のデータスケールを扱うように設計されています。Milvusコミュニティは10億スケールのユースケースをサポートすることを検証しており、現在では数百億のベクトルを含む状況に対して実装されている。
Chroma、Weaviate、Qdrantのような他のベクターデータベースにも強みはありますが、Milvusが提供するような柔軟性、スケーラビリティ、長期的なサポートには及ばないことが多いです。プロジェクトの規模が大きくなるにつれ、ベクターデータベースの切り替えはコストと複雑さを伴います。Milvusは多様な導入オプションがあり、様々なデータスケールの混合ワークフローをサポートし、データベースソリューションが手狭にならないようにします。
Milvus Lite、スタンドアロン、分散基盤コンポーネント
Milvusは、基盤となるコンポーネントを共有しているため、3つの導入モードにおいて一貫したユーザーエクスペリエンスと均一な進化を提供します。この設計により、Milvus Liteを軽量なタスクに使用する場合でも、Milvus Distributedを大規模なオペレーションに使用する場合でも、同じコア機能の恩恵を受けることができます。
下図は、Milvusの各展開モードがカバーする機能コンポーネントを示しています:
図2- 基盤コンポーネントにおけるMilvus Lite vs. スタンドアロン vs. 分散](https://assets.zilliz.com/Figure_2_Milvus_Lite_vs_Standalone_vs_Distributed_on_underlying_components_bb98880a4f.png)
Milvus Liteは主に検索エンジンをカプセル化し、データ挿入、永続化、インデックス構築、メタデータ管理などの重要なタスクのローカル実装も提供します。Milvus Liteは、単純なツールではなく、強力なライブラリと考えてください。Chromaのような基本的なライブラリと比較して、Milvus Liteの検索エンジンは優れたパフォーマンスとクエリ機能を提供し、ベクトル埋め込みに最適です。FAISS](https://zilliz.com/learn/faiss)やHNSWLibに代わるものをお探しなら、主流のvector searchアルゴリズムライブラリをネイティブに統合し、パフォーマンスと機能の両面で大規模な最適化を行ったMilvus Liteが有力な候補となるでしょう。
Milvusスタンドアロンには、ロードバランシングとマルチノード管理(コーディネータ)を除く、Milvusシステムの全ての機能コンポーネントが含まれています。これらのコンポーネントは同じDocker環境内で動作し、効率的なローカル通信を促進し、サーバーのレイテンシを最小限に抑えます。
Milvus Distributedはフルレンジの機能コンポーネントを誇ります。スタンドアロンモードとディストリビューションモードには、Proxy、Query Node、Data Node、Index Nodeが含まれ、機能は同じですが、Milvus Distributedはより柔軟なデプロイが可能です。各機能コンポーネントは、より高い負荷に対応するために複数回デプロイすることができ、複数のコンポーネントを同じ物理ノードにデプロイしてリソースを共有することも、異なるノードにデプロイしてリソースを分離することも可能です。さらに、Distributed モードでは、各コンポーネントの独立したスケーリングが可能なため、さまざまな負荷特性に適応し、リソース利用率を効果的に向上させることができます。
要約
この投稿では、Milvusが提供する3つのデプロイメントオプションについて検討しました:Milvus Lite、スタンドアロン、分散です。各デプロイメントモードは、異なる開発ステージ、データサイズ、ユースケースに合わせて調整されており、Milvusがプロジェクトと共にスケールすることを保証します。
Milvus Lite**は、Python環境内での迅速なプロトタイピングや小規模な実験に最適です。セットアップと使用が簡単で、テストと開発のための軽量かつ強力なソリューションを必要とする開発者に最適です。
Milvusスタンドアロン**は、プロトタイピングから本番環境に移行する準備ができている開発者のための次のステップです。このシングルノードのデプロイオプションは、パフォーマンスとリソース効率のバランスをとりながら、初期の本番環境に必要なすべてのコンポーネントを提供します。データサイズが中程度で、ユーザーの要求が高まっているプロジェクトに適しています。
Milvus Distributed**は、高可用性、拡張性、柔軟性を必要とする大規模な本番環境向けに設計されています。大量のデータを扱う企業やアプリケーションに最適で、ベクターデータベースがビジネスニーズと共に成長することを保証します。
その他のリソース
Milvus ドキュメント](https://milvus.io/docs)
検索拡張世代(RAG)とは](https://zilliz.com/learn/Retrieval-Augmented-Generation)
あなたのGenAIアプリのためのトップパフォーマンスAIモデル|Zilliz](https://zilliz.com/ai-models)
ジェネレーティブAIリソースハブ|Zilliz](https://zilliz.com/learn/generative-ai)
ベクトルデータベース学習センター](https://zilliz.com/learn)
読み続けて

Storage Cost Isn’t the Whole Story: Why We Disagree with Turbopuffer’s Trade-offs
A real-world benchmark comparing Turbopuffer and Zilliz Cloud on cost, latency, recall, and consistency for production-scale vector search workloads.

Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.

Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.
