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、その他多くのメインストリームベクトルデータベースのベンチマーク用。
読み続けて
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.