VectorDB-Bench を使用して、milvus スタンドアロン クラスターで次のパフォーマンス検証を実行しました。 milvus スタンドアロン クラスターのネットワークとサーバー接続は次のとおりです。

このセクションでは、Milvus スタンドアロン データベースのテストから得た観察結果を共有します。 。これらのテストのインデックス タイプとして DiskANN を選択しました。 。約 100 GB のデータセットの取り込み、最適化、インデックス作成には約 5 時間かかりました。この期間の大半では、20 個のコア (ハイパースレッディングを有効にすると 40 個の vCPU に相当) を搭載した Milvus サーバーが最大 CPU 容量の 100% で動作していました。DiskANN は、システム メモリ サイズを超える大規模なデータセットで特に重要であることがわかりました。 。クエリフェーズでは、1 秒あたりのクエリ数 (QPS) レートが 10.93、リコールが 0.9987 でした。クエリの 99 パーセンタイル レイテンシは 708.2 ミリ秒と測定されました。

ストレージの観点から見ると、データベースは、取り込み、挿入後の最適化、およびインデックス作成の各フェーズで約 1,000 オペレーション/秒を発行しました。クエリフェーズでは、32,000 オペレーション/秒が要求されました。

次のセクションでは、ストレージ パフォーマンス メトリックを示します。

VectorDB-benchの結果は以下の通りです。

スタンドアロン Milvus インスタンスのパフォーマンス検証から、現在の設定では次元数が 1536 の 500 万ベクトルのデータセットをサポートするには不十分であることが明らかです。ストレージには十分なリソースがあり、システムのボトルネックにはならないと判断しました。

このセクションでは、Kubernetes 環境内での Milvus クラスターの展開について説明します。この Kubernetes セットアップは、Kubernetes マスター ノードとワーカー ノードをホストする VMware vSphere デプロイメント上に構築されました。

VMware vSphere および Kubernetes のデプロイメントの詳細については、次のセクションで説明します。

このセクションでは、Milvus データベースのテストから得られた観察結果を紹介します。 * 使用されたインデックス タイプは DiskANN です。 * 以下の表は、1536 次元で 500 万のベクトルを扱う場合のスタンドアロン展開とクラスター展開の比較を示しています。クラスター展開では、データの取り込みと挿入後の最適化にかかる時間が短くなることがわかりました。スタンドアロン設定と比較して、クラスター展開ではクエリの 99 パーセンタイル レイテンシが 6 分の 1 に削減されました。 * クラスター展開では 1 秒あたりのクエリ数 (QPS) レートは高くなりましたが、望ましいレベルには達しませんでした。

以下の画像は、ストレージ クラスターのレイテンシや合計 IOPS (1 秒あたりの入出力操作数) など、さまざまなストレージ メトリックを示しています。

次のセクションでは、主要なストレージ パフォーマンス メトリックを示します。

スタンドアロン Milvus と Milvus クラスターの両方のパフォーマンス検証に基づいて、ストレージ I/O プロファイルの詳細を示します。 * I/O プロファイルは、スタンドアロン展開とクラスター展開の両方で一貫していることがわかりました。 * ピーク IOPS で観測された差は、クラスター展開内のクライアント数が多いことに起因します。

VectorDB-Bench を使用して PostgreSQL (pgvecto.rs) に対して次のアクションを実行しました。PostgreSQL (具体的には pgvecto.rs) のネットワークとサーバー接続に関する詳細は次のとおりです。

このセクションでは、特に pgvecto.rs を使用して PostgreSQL データベースをテストした結果と観察結果を共有します。 * テスト時点では DiskANN が pgvecto.rs で利用できなかったため、これらのテストのインデックス タイプとして HNSW を選択しました。 * データ取り込みフェーズでは、768 次元の 1,000 万ベクトルで構成される Cohere データセットをロードしました。このプロセスには約 4.5 時間かかりました。 * クエリフェーズでは、1 秒あたりのクエリ数 (QPS) が 1,068、リコールが 0.6344 でした。クエリの 99 パーセンタイル レイテンシは 20 ミリ秒と測定されました。実行時間のほとんどを通じて、クライアントの CPU は 100% の能力で動作していました。

以下の画像は、ストレージ クラスターのレイテンシ合計 IOPS (1 秒あたりの入出力操作数) など、さまざまなストレージ メトリックを示しています。

VectorDBBench を使用した Milvus と PostgreSQL のパフォーマンス検証に基づいて、次のことがわかりました。

pgvecto.rs は 1 秒あたりのクエリ数 (QPS) が 1,068、リコールが 0.6344 であったのに対し、Milvus は QPS が 106、リコールが 0.9842 であったことがわかりました。

クエリの高精度が優先される場合、Milvus はクエリごとに関連アイテムをより高い割合で取得するため、pgvecto.rs よりも優れています。しかし、1 秒あたりのクエリ数の方が重要な要素である場合、pgvecto.rs は Milvus を上回ります。ただし、pgvecto.rs 経由で取得されるデータの品質は低く、検索結果の約 37% が無関係な項目であることに注意することが重要です。

パフォーマンス検証に基づいて、次のことが観察されました。

Milvus では、I/O プロファイルは、Oracle SLOB で見られるような OLTP ワークロードによく似ています。ベンチマークは、データ取り込み、事後最適化、クエリの 3 つのフェーズで構成されます。初期段階では主に 64 KB の書き込み操作が特徴で、クエリ段階では主に 8 KB の読み取りが行われます。 ONTAP がMilvus I/O 負荷を適切に処理することが期待されます。

PostgreSQL I/O プロファイルでは、困難なストレージ ワークロードは発生しません。現在進行中のメモリ内実装を考慮すると、クエリフェーズ中にディスク I/O は発生しませんでした。

DiskANN は、ストレージの差別化に重要なテクノロジーとして登場しました。システム メモリの境界を超えたベクトル DB 検索の効率的なスケーリングが可能になります。ただし、HNSW などのメモリ内ベクトル DB インデックスでは、ストレージ パフォーマンスの差別化を確立できる可能性は低くなります。

また、インデックス タイプが HSNW の場合、RAG アプリケーションをサポートするベクター データベースにとって最も重要な操作フェーズであるクエリ フェーズでは、ストレージが重要な役割を果たしないことにも注目に値します。ここでの意味は、ストレージ パフォーマンスがこれらのアプリケーションの全体的なパフォーマンスに大きな影響を与えないということです。