PolarDB:OpenSearch プロトコル：1億件規模の MSMARCO データセットにおけるパフォーマンス

クラスターの仕様とバージョン

• マスターノード：2 コア 8 GB

• 読み取り専用ノード：2 コア 8 GB

• 検索ノード：32 コア 256 GB × 3

• クライアントレイテンシー：0.097 ms

• PolarDB ベクトルインデックスバージョン：2.19.3

データセット

HNSW インデックスの作成とデータ書き込み

1. インデックスの作成：以下の構成を使用して、1億件規模のデータセット用のインデックスを作成します。この構成は、ビルド速度、メモリ使用量、クエリパフォーマンスのバランスを取るものです。

   1. インデックススキーマと主要パラメーターの定義

      • number_of_shards：3つの検索ノード (合計 96 物理コア) にデータと計算ワークロードを均等に分散させるため、18 に設定します。

      • ef_construction と m：これらは HNSW インデックスを構築するための主要パラメーターです。このテストでは、ビルド速度とインデックス品質のバランスを取るために 128 と 8 を使用します。

      • refresh_interval と durability：これらはテストパフォーマンスを最大化するための特別な最適化であり、本番環境で直接使用することは推奨されません。詳細については、「本番運用時の注意点」をご参照ください。

   2. 次のコマンドを実行してインデックスを作成します。

      curl -X PUT "http://<endpoint>:<port>/msmarco" -H 'Content-Type: application/json' -d'
      {
        "mappings": {
          "properties": {
            "docid": { "type": "keyword" },
            "domain": { "type": "keyword" },
            "emb": {
              "type": "knn_vector",
              "dimension": 1024,
              "method": {
                "engine": "faiss",
                "space_type": "l2",
                "name": "hnsw",
                "parameters": {
                  "ef_construction": 128,
                  "m": 8
                }
              }
            },
            "url": { "type": "text" }
          }
        },
        "settings": {
          "index": {
            "replication": { "type": "DOCUMENT" },
            "refresh_interval": "0s",
            "number_of_shards": "18",
            "translog": {
              "flush_threshold_size": "1gb",
              "sync_interval": "30s",
              "durability": "async"
            },
            "knn.algo_param": { "ef_search": "64" },
            "provided_name": "msmarco",
            "knn": "true",
            "number_of_replicas": "0"
          }
        }
      }
      '

2. データ書き込み：MSMARCO V2.1 データセットを HNSW インデックスに書き込みます。

クエリパフォーマンステストの実行

同時実行数と ef_search パラメーターのさまざまな組み合わせを使用して、クエリスループット (QPS)、レイテンシー、取得率をテストしました。

• concurrency：1 から 128 までの同時クエリをシミュレートします。

• ef_search：クエリ中に HNSW グラフで検索される近傍ノードの幅。値が大きいほど理論的には取得率が高くなりますが、計算オーバーヘッドも増加するため、QPS が低下し、レイテンシーが増加します。

# コマンド例。実際のスクリプトに置き換えてください。
python benchmark.py --concurrency 1/2/4/8/16/32/64/128 --ef-search 32/64/128/256 --max-duration 60

パフォーマンス結果の分析

• 同時実行数のスケーラビリティ：QPS 曲線を見ると、同時実行数が 1 から 64 に増加するにつれて、システムスループット (QPS) はほぼ線形に増加していることがわかります。これは、PolarDB ベクトルエンジンが優れた水平スケーラビリティを持つことを示しています。同時実行数が 64 を超えると、QPS の増加は鈍化し、同時実行数 128 でピークに達します。この時点で、システムリソース (おそらく CPU) が飽和状態に近くなり、パフォーマンスのボトルネックとなっています。

• レイテンシーと同時実行数の関係：平均 (Avg) および P99 レイテンシーは、同時実行数が増加するにつれて大幅に増加します。この動作は、システム負荷が増加するにつれて予想されるものです。高い QPS が要求されるシナリオでは、P99 レイテンシーがビジネス要件を満たしていることを確認してください。

• 取得率のパフォーマンス：すべてのテスト条件下で、取得率は 95.8% 以上で安定しています。これは、HNSW インデックスが現在のパラメーターで高い検索精度を持つことを示しています。

主要パラメーターの本番環境向け推奨設定

以下のパラメーターは、最大のテストパフォーマンスを達成するために設定されたものです。本番環境で使用する前に、慎重に評価してください。

• "refresh_interval": "0s"

  • テスト目的：自動更新を無効にするため。これにより、書き込みテスト中にデータがメモリと translog にのみ書き込まれるようになります。クエリテストの前に手動で refresh を実行し、バックグラウンドタスクからの干渉なしにクエリパフォーマンスデータを取得します。

  • 本番環境での推奨事項：本番環境では、この値を 0s に設定しないでください。データの可視性要件に基づいて、適切な値を設定してください。たとえば、1s という値は、新しいデータが書き込まれてから約 1 秒後に検索可能になることを意味します。

• "durability": "async"

  • テスト目的：非同期 translog フラッシュを使用するため。データはメモリに書き込まれ、すぐに成功応答が返されます。その後、バックグラウンドスレッドがデータを非同期にディスクに永続化します。これにより、書き込みスループットが向上します。

  • 本番環境での推奨事項：高いデータ信頼性が要求されるシナリオでは、この設定を慎重に使用してください。サーバー障害などの極端な状況では、async モードではディスクに永続化されていない最後の数秒間のデータが失われる可能性があります。高いデータ信頼性要件がある場合は、本番環境でデフォルトの request モードを使用してください。このモードでは、データが translog に書き込まれ、ディスクに永続化された後にのみ成功応答が返されますが、書き込みパフォーマンスは低下します。

リソース使用率評価

ピーク負荷時のシステムのリソース消費を理解することは、正確な容量計画にとって不可欠です。

• 書き込み集中型のシナリオ：8,394 docs/sec のピーク書き込み時、システムの主なボトルネックは CPU (インデックス構築に使用) とディスク I/O (translog 書き込みに使用) です。

• クエリ集中型のシナリオ：同時実行数 128、1,067 QPS のピーククエリ時、システムのボトルネックは主に CPU 使用率です。