Milvusリファレンス・アーキテクチャ
このブログでは、特定のユースケースに基づくMilvusのリソース割り当てに関して、よくある質問を取り上げます。これらの質問には以下が含まれます：
特定のユーザー数またはRPS（requests per second）に基づき、Milvusに必要なCPUおよびメモリリソースはどのくらいですか？
READとWRITEの異なる組み合わせに基づき、Milvusに必要なCPUとメモリリソースはどのくらいか？
ワークロード特性の理解
Milvusにリソースを割り当てる最初のステップは、お客様のワークロード特性を理解することです。これらの要素はMilvusの計算能力とメモリ要件を決定する上で重要な役割を果たします。
以下はLinuxパッケージベースのリファレンスアーキテクチャのリスト例です。RPSはRequests Per Secondを意味します：
最大20 RPSまたは1,000ユーザー](https://docs.gitlab.com/ee/administration/reference_architectures/1k_users.html)API：20RPS、ウェブ：2RPS、Git（Pull）：2RPS、Git（Push）：1 RPS
最大40RPSまたは2,000ユーザー](https://docs.gitlab.com/ee/administration/reference_architectures/2k_users.html)API：40RPS、Web：4RPS、Git（Pull）：4RPS、Git（Push）：1 RPS
最大60RPSまたは3,000ユーザー](https://docs.gitlab.com/ee/administration/reference_architectures/3k_users.html)API：60RPS、Web：6RPS、Git（Pull）：6RPS、Git（Push）：1 RPS
100RPSまたは5,000ユーザーまで](https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html)API：100RPS、Web：10RPS、Git（Pull）：10RPS、Git（プッシュ）：2RPS
200RPSまたは10,000ユーザーまで](https://docs.gitlab.com/ee/administration/reference_architectures/10k_users.html)API：200RPS、ウェブ：20RPS、Git（Pull）：20RPS、Git（Push）：4 RPS
500RPSまたは25,000ユーザーまで](https://docs.gitlab.com/ee/administration/reference_architectures/25k_users.html)API：500RPS、ウェブ：50RPS、Git（Pull）：50RPS、Git（Push）：10 RPS
1000RPSまたは50,000ユーザーまで](https://docs.gitlab.com/ee/administration/reference_architectures/50k_users.html)API：1000RPS、ウェブ：100RPS、Git（Pull）：100RPS、Git（プッシュ）：20RPS
リソース要件の見積もり
Milvusに必要なリソースを見積もるには、いくつかの仮定が必要です：
1.読み込み：各WebリクエストとGitプルはREAD操作である。
2.書き込み：各GitプッシュはWRITE操作とみなされる。
3.読み書きの量と比率：ミルバスは、ユーザー数あたりのAPIコールの読み取り/書き込みの比率と同じであると仮定します。
4.クエリー/秒（QPS）：ユーザー数あたりのAPI RPS（リクエスト/秒）要件と一致しなければならない。
また、読み取り/書き込みリクエストあたりのデータサイズも見積もる必要がある。一般的なGenAIのユースケースを想定する：
ベクトル次元：1024浮動小数点数
浮動小数点数あたりのバイトサイズ：4 KB
Top_k (返されるベクトル数)：検索リクエストあたり10ベクトル
コレクション（データベーステーブル）のサイズ：100万ベクトル/書き込み要求
データベースのインデックスタイプHNSW
これらの仮定に基づき、ナプキンのバック・オブ・ナプキンで計算することで、読み取りまたは書き込み1回あたりのデータサイズを見積もることができます。ベクトル次元が1024で、各ベクトルは1024 * 4バイト = 4KBであると仮定する。 典型的なtop_k = 10ベクトル/リードと仮定する。これらの仮定で
Milvusの各読み取りオペレーションは約40KBのデータを処理します。
各Milvus書き込み操作は40MBのデータを処理すると推定される。
Milvusはinsert(全く新しいコレクションを作成する)とupsert(いくつかの行を変更する)の両方の機能を提供しています(詳細についてはブログMilvus insert, upsert, deleteを参照してください)。 各WRITE操作は、数行のupsertではなく、コレクション全体のinsertになるように過大評価します。
データベースはデータサイズだけでなく、検索と挿入の速度も考慮する必要があります。 ここでは、コレクションが一般的なHNSWインデックスを使用してインデックス化されていると仮定します。これは、検索時間がO(log n)というBig-O表記になります。
これらの仮定をもとに、ウェブベースのユーザー/RPS/リード/ライトをベクターデータベースのQPS/データサイズアーキテクチャ層に変換する：
最大1,000ユーザー = 20 QPS、100万ベクトル
最大2,000ユーザー＝100万ベクターで40QPS
最大3,000ユーザー = 100万ベクトルで60 QPS
5,000ユーザーまで = 200万ベクトルで100 QPS
10,000ユーザーまで = 200 QPS、400万ベクトル
最大25,000ユーザー = 1000万ベクトルで500 QPS
最大50,000ユーザー = 1000 QPS、2,000万ベクトル
負荷テストとベンチマーク
リソース推定の精度を保証するために、VectorDBBenchでアーキテクチャ層の負荷テストとベンチマークを行いました。Milvusアーキテクチャ](https://milvus.io/docs/architecture_overview.md)自体のデフォルトのSegment、Partition、Shard、Dataノード、Queryノード、Indexノードサイズを想定した。
Milvusのオートスケール機能により、パフォーマンスはデータサイズとクラスタリソースに比例します！以下は、異なるデータ容量とQPS要件に対して推奨されるMilvusとZilliz Cloud(フルマネージドMilvus)のリソースサイズを示した表です。
以下の表は1024_dimensionのベクトル数百万単位でデータ容量を表しています。Milvusのリソースは数CPUとGBのメモリで与えられる。 コスト比較のため、Zilliz Cloudのリソースサイズをパフォーマンスまたは容量タイプ別にコンピュートユニット(cu)単位で表示しています。
ユーザー/RPSティアごとのMilvusとZillizの推奨リソースサイズ表
| ユーザー数｜データ容量｜QPSベンチマーク｜必要RPS｜Milvusリソース｜Zillizリソース | |||||
| 3,000｜1m_1024dベクトル｜1200｜60｜8CPU、32G｜1cu-perf｜。 | |||||
| 3,000｜1m_1024dベクトル｜2400｜60｜16CPU、64G｜2cu-perf｜｜。 | |||||
| 3,000｜1m_1024dベクトル｜3600｜60｜24CPU、96G｜4cu-perf｜｜。 | |||||
| 10000｜3.7m_1024dベクトル｜360｜200｜16CPU、64G｜2cu-perf｜の場合 | |||||
| 10,000円｜3.7m_1024dベクタ｜700円｜200円｜64CPU、256G｜4cu-cap｜。 | |||||
| 25,000円｜10m_1024dベクトル｜600円｜500円｜196CPU、768G｜12cu-cap | |||||
| 250,000｜100m_1024dベクトル｜6000｜5000｜19200CPU、76800G｜1200cu-cap |
ユーザー/RPSティア数ごとの推奨MilvusおよびZillizリソースサイズの表。Milvusのスケーリングは、データサイズと必要なQPSに対して線形です。
上の表から、データサイズとQPSがある閾値に達する必要がある場合、オンプレミスではなくZillizクラウドからMilvusを実行した方がコスト効率が高くなる可能性があります。
結論
ワークロードの特性を理解し、仮定に基づいて必要なリソースを見積もり、VectorDBBenchのような負荷テストやベンチマークツールを活用することで、Milvus導入に必要なリソースを自信を持ってプロビジョニングすることができます。
クラスタサイジングガイドを参照してください。 ワークロードが進化するにつれて、最高のパフォーマンスを維持するために定期的にリソースの割り当てを見直し、調整することが不可欠であることを忘れないでください。
参考文献
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Milvusアーキテクチャ： https://docs.gitlab.com/ee/administration/reference_architectures/
ブログ Milvus パッケージング依存関係：https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
ブログ Milvus Sizing Tool：https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
シャード、パーティション、セグメントhttps://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Zilliz Cloud CU タイプ： https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
VectorDBBenchツール](https://zilliz.com/vector-database-benchmark-tool?database=ZillizCloud%2CMilvus%2CElasticCloud%2CPgVector%2CPinecone%2CQdrantCloud%2CWeaviateCloud&dataset=medium&filter=none%2Clow%2Chigh&tab=1) Milvus、Zilliz Cloud、その他多くのメインストリームベクトルデータベースのベンチマーク用。
Christy BergmanChristy Bergman is a passionate Developer Advocate at Zilliz. She previously worked in distributed computing at Anyscale and as a Specialist AI/ML Solutions Architect at AWS. Christy studied applied math, is a self-taught coder, and has published papers, including one with ACM Recsys. She enjoys hiking and bird watching.
読み続けて
Turbopuffer vs. Zilliz Cloud: A Performance and Cost Benchmark for Multi-Tenant Vector Search
Turbopuffer vs. Zilliz Cloud: A Performance and Cost Benchmark for Multi-Tenant Vector Search
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.
Long List of Awesome DeepSeek Integrations You Should Know
Discover how DeepSeek's affordable AI ecosystem challenges Silicon Valley giants with powerful integrations for developers and businesses—from RAG systems to productivity tools, all at 90% lower cost.