Milvusの探査とストレステスト分析

1. 背景

最近ベクトル検索を使用したので、milvus でストレス テストを実行する必要があります。同時に、ストレステストで発生した問題をさらに分析するために、milvus のソースコードとドキュメントもいくつか読みました。私たちはいくつかの問題や疑問に遭遇し、milvus コミュニティやオープンソースの貢献者と直接コミュニケーションを取りました。

ストレステストを通じて、特定のシナリオではmilvusのパフォーマンスを改善できないことが判明し、そのシナリオに基づいたソリューションを提供しました。コミュニティはミルバスの役員にフィードバックしました。

以下は、milvus の設計とストレス テストで発生した問題とその解決策またはフォローアップ プランです。

2. ベクトル検索とmilvus

2.1 ベクトル検索

ベクトル検索は ANNS と略され、完全な英語名は approximate Nearest Neighbor Search です。一般的な概念は、多数のベクトルの中からターゲット ベクトルに最も近い N 個のベクトルを見つけることです。最も単純かつ大雑把な検索方法はブルートフォース検索ですが、インデックスを拡張し、大規模クエリの QPS を向上させることで検索速度を高速化できます。

現在のベクトル インデックスは、ツリー ベース インデックス、グラフ ベース インデックス、ハッシュ ベース インデックス、量子化ベース インデックスの 4 つのカテゴリに分類できます。その中で、グラフ アプローチは、再現率が高く、パフォーマンスが優れており、最適化後のアイデアが豊富なため、際立っています。

2.2 ミルバス

milvus (主にバージョン 2.0 以上用) は、ベクター挿入、ANNS 検索などをサポートするメタネイティブ ベクター データベースです。Milvus は、大量のベクター データを非常にうまく処理できます。ベクトル類似度計算の分野でよく知られているいくつかのオープンソースライブラリ (Faiss、SPTAG など) を統合し、データとハードウェアの計算能力の合理的なスケジュール設定を通じて最適な検索パフォーマンスを実現します。

公式サイト: https://milvus.io/

3. Milvus アーキテクチャの紹介

3.1 Milvusデータセットの概念

データセットの概念:

• コレクション: MySQL テーブルに似たデータ セット。
• チャネル: データ セットは、主キーに基づいて多数のチャネルに分割されます。データの書き込みとクエリを実行する場合、これはメッセージ ブローカーのチャネルの概念に対応します。
• パーティション: パーティションはデータ セットをレイヤーに分割します。日付などの共通パーティションは日付ごとにデータを保存します。パーティションとチャネルは直交します。
• セグメント: Milvus データセットの最小単位。特定のインデックスはセグメントに基づいて構築されます。クエリの最小単位もセグメントです。

公式ウェブサイトには、データセットの読み取りと書き込みの例が掲載されています: https://milvus.io/docs/v2.1.x/example_code.md

データセットクエリツール: https://github.com/milvus-io/birdwatcher

以下は、birdwatcher を使用してコレクションとセグメントの情報を表示します。

上記の出力結果がツールに変換されました。

etcd 内の特定のセグメントに関するすべての情報:

、

3.2 milvus アーキテクチャ図

milvus 公式サイトで提供されているアーキテクチャ図は次のとおりです。

グループは次のカテゴリに分類できます。

上記のマイクロサービスの機能を簡単に紹介します。

• システムファサード:

• プロキシ: すべての SDK クエリはプロキシを経由します。プロキシは、メッセージ ブローカー内のさまざまなチャネルに書き込みデータを配信します。プロキシは、書き込み要求、読み取り要求、制御要求の 3 種類のデータを処理します。

• システムコーディネーター:
• RootCoord: 従来のマスター ロールと同様に、コレクションの作成、コレクションの削除、パーティションの管理など、主にいくつかの DDL と DCL を管理します。さらに、rootCoord には、システムにグローバルに一意のタイムスタンプを割り当てるという、より大きな責任があります。
  
• データの書き込み:
  
• DataCoord: コーディネーター。セグメントの割り当てと管理、データノードの管理、データノードの障害回復の処理などを行います。
  
• DataNode: データ ストリームからデータを消費し、データをシリアル化し、ログ データをログ スナップショットに変換して、ディスクに更新します。
  
• インデックスの作成:
  
• IndexCoord: シールされたセグメントのインデックスを作成し、indexNode を管理します。
  
• IndexNode: 特定のインデックス作成に関する事項を担当します。
  
• クエリ:
  
• QueryCoord: データ クエリ管理。QueryNode の管理を担当します。
  
• QueryNode: 特定のデータクエリの問題を担当します。
  
• メタ情報とメタデータの保存:
  
• MetaStore: Metastore は ETCD ストレージを使用します。主にメタ情報とメタデータの保存を担当します。たとえば、テーブル構造、セグメント構造、グローバル タイムスタンプなど。
  
• 書き込みデータメッセージの配信:
  
• ログブローカー: ログブローカーはパルサーを使用します。最新バージョン 2.0 以降では、書き込まれたデータは最初にログ ブローカーに書き込まれ、その後 DataNode がログ ブローカーからデータを読み取ります。
  
• データとインデックスのストレージ:
  
• オブジェクト ストア: オブジェクト ストアは現在、主にデータやインデックスなどを保存するために使用される minio を使用しています。
  

上記から、マイクロサービスが多数存在し、マイクロサービス間の通信方法は主に以下の通りであることがわかります。

4. Milvusベクターの書き込みと読み取りリンク

4.1 milvus ベクター書き込みパス

• プロキシは、produce を通じてメッセージ ブローカーの物理チャネルにデータを書き込みます。
• DataNode はデータを消費するコンシューマーとして機能します。
• DataNode は消費データを定期的にオブジェクト ストアに保存します。
• DataNode は定期的に dataCoord に通知して、データのメタデータを記録します。

3.2 milvus ベクター検索パス

現在の最新バージョン 2.1.4 の以下の読み取りプロセスは、インターネット上の読み取りプロセス バージョン リンクと異なるため、修正する必要があります。

• ベクトル検索 (ANNS) 要求を受信すると、プロキシは要求をシャード リーダー クエリ ノードに送信します。
• リーダー クエリノードは、各セグメントの分布に基づいて、ANNS 要求を各クエリノードに配布します。クエリノードは、最小検索単位のセグメントやCPUコア数などに基づいて並列クエリを実行し、結果を絞り込みます。
• すべてのリクエストを受信した後、プロキシは検索結果を絞り込み、クライアントに返します。

5. milvusストレステストの問題分析

ストレステストバージョン: milvus-2.1.4

データ次元: 512dim

索引：

5.1 ストレステストの結果

5.2 ストレステストにおける問題と分析

QPS と CPU 使用率は増加できず、CPU が 50% を超える可能性は低くなります。 （最適化済み）

現象の説明:

ストレステスト中に、QPS を増やすことができないことが判明しました。慎重に調査した結果、クエリ ノードの CPU 使用率を増やすことができず、QPS が増加しないことが判明しました。

• 解決：
  当初、クエリ ノードのスケジューリングの問題ではないかと疑いました。さまざまな調査を行った結果、これはスケジューリング パラメータ scheduler.cpuRation と深く関係していることがわかりました。以下は、このパラメータのさまざまな値での QPS です。

このパラメータは主に、検索タスクの CPU 使用率を評価するために使用されます。パラメータが高くなるほど、タスクが使用する CPU が多くなります。スケジュール設定時に、複数のタスクによる並列クエリの数が少なくなります。今のところ、並列タスクが多すぎて高い QPS を達成できないのではないかと考えています。

Milvus はこのパラメータ設定を公開していませんが、問題/機能強化を通じて Milvus コミュニティに提出しました。以降のバージョンではいくつかの最適化が行われる予定です。

クエリノードを展開した後、短期間でセグメントが自動的にバランス調整されない（疑わしい、フォローアップ）

現象の説明:

• たとえば、2 つのクエリ ノードがオンラインであり、50 個のセグメントが 2 つのノードに均等に分散されているとします。ストレス テスト中に、ノードが追加された場合、セグメントが新しいノードに自動的にバランス調整されないことが何度も確認されました。

• 現在の進捗状況:
  ストレス テスト全体を通じて、3 回の書き込み操作が実行されましたが、そのうち 2 回は自動的にバランス調整されず、最後の 1 回は自動的にバランス調整されました。
  私はこの問題について milvus コミュニティのメンテナーに相談しましたが、彼らは理論的には増幅は自動的にバランスが取られると考えています。これは私たちが測定した結果と一致しません。引き続き調査し、問題を見つけていきます。

長期間にわたって大規模な書き込みが継続すると、大量の成長セグメントが生成され、クエリのパフォーマンスが低下します（後述）。

• 現象の説明:
  複数のスレッドが大量のベクター データを継続的に挿入した後、ログを確認すると、一部のクエリ ノードのセグメントが常に増加状態にあることがわかります。これらのセグメントは書き込みノードでシールされていますが、クエリ ノードはこれらのシールされたセグメントを自動的に再ロードせず、常にこれらのノードが成長中の状態にあると認識します。
  増大する状態セグメントはインデックスなしでブルート フォース検索でクエリされるため、クエリが遅くなり、手動で解放する必要が生じます。

• 現在の進捗状況:

私はこの問題について milvus コミュニティのメンテナーに相談しており、引き続き原因を突き止めて改善に努めていきます。

バージョンアップ後、元のデータに互換性がない（解決方法あり）。

バージョンアップ後、元のデータに互換性がない（解決方法あり）。

• 現象の説明:
  milvusを2.1.4から最新バージョンにアップグレードした後、元のデータが読み込まれず起動できません。バージョンをロールバックした後、データ メタデータが破損しており、ロードできないことが判明しました。
• 解決：
  システムが安定したら、バージョンを慎重にアップグレードするか、アップグレードする前に徹底的な調査を行ってください。さらに、アップグレードする前にデータをマージすることが公式の提案です。

数千万のデータポイントでは、ストレステストの QPS は期待を満たすことができません (フォローアップが必要)

• 現象の説明:
  データが数千万レベルにまで挿入されると、ストレステストによる QPS の向上が難しくなり、99% の時間消費が比較的急速に減少することがわかります。 CPU コアの数を増やしても、改善はあまり顕著ではありません。
  

たとえば、次の例では 32 コア 16G を 2 つ使用します。

• 解決：
  これは、FLAT インデックスの使用に関連している可能性があります。後ほど、ストレス テスト用の新しいインデックス作成方法を試してみます。

デプロイメントを通じて容量を拡大または縮小しないでください。Helm を通じて行うようにしてください。

• 現象の説明:
  デプロイメントによる容量拡張後、パラメータを均一に変更できないため、スムーズな拡張が実現できません。たとえば、容量拡張後にデータを再度解放してロードする必要があり、短時間の中断が発生する可能性があります。
  

そのため、公式サイトでもスムーズに容量拡張するためにはhelmを使うようにすることを推奨しています。

6. まとめ

ストレステスト後、milvus は当社の現在のビジネス シナリオを満たすことができます。上記のストレス テストで残った問題のいくつか、たとえば、多数のセグメントの問題、ノードの拡張、その他の問題などについては、現在も追跡中です。これらの問題は 100% 発生するわけではなく、一部は当社の厳しいテスト条件下でのみ発生します。私たちは引き続きテストを行い、原因を特定し、さらなる最適化のためにコミュニティにフィードバックを提供していきます。上記のストレステストで使用されるインデックスは FLAT です。より高いパフォーマンスを実現するために、グラフ インデックスを使用することが公式に推奨されています。現在のビジネス シナリオでは FLAT インデックスの使用が必要なため、最初に FLAT インデックスに基づいてストレス テストを実行します。グラフインデックスは後で使用され、ストレステストも実行されます。

milvus のストレス テストを行うことで、milvus の設計を理解し、学ぶこともできます。一般的に、Milvus は優れたクラウドネイティブ ベクター データベースです。いくつかのデザインコンセプトは比較的先進的です。ベクトル検索と k8s を組み合わせ、クエリノードを単純に拡張するだけでベクトル検索のパフォーマンスを線形に向上させることができます。分散データベースでは、読み取りと書き込みの分離、ストレージとコンピューティングの分離を実現します。公式ウェブサイトでは、豊富なドキュメントと、attu、birdwatcher などの多くのツールが提供されています。