OpenSearch:汎用ベクトルインデックスの構成

ベクトルディメンション

• 目的：ベクトル内の特徴量の数を定義します。この値は、埋め込みモデルの出力ディメンションと完全に一致する必要があります。

• 推奨事項：

  • 一貫性の確保：構成されたディメンションが書き込まれるベクトルデータのディメンションと一致しない場合、インデックス構築は失敗します。

  • パフォーマンスへの影響：ディメンションを大きくすると、ベクトルがより多くの情報を表現できるようになりますが、メモリ使用量と計算オーバーヘッドも増加します。ディメンションを 2 倍にすると、メモリ使用量もおよそ 2 倍になります。

距離タイプ

• 目的：ベクトル間の類似度を計算する方法を定義します。適切な距離タイプを選択することは、検索品質にとって極めて重要であり、データの特性やビジネスシナリオに依存します。

• 選択ガイド：

  距離タイプ	スコアの説明
  Cosine distance	スコアの範囲は [-1, 1] で、スコアが高いほど類似度が高くなります。スコアが 1 の場合はベクトルが同一であり、-1 の場合は互いに逆方向を指しています。
  Inner product distance	スコアが高いほど類似度が高くなります。
  Squared Euclidean distance	スコアが低いほど類似度が高くなります。スコアが 0 の場合はベクトルが同一です。

ベクトルインデックスアルゴリズム

• 目的：ベクトルインデックス構築に使用する基盤アルゴリズムを選択します。アルゴリズムによって、インデックス構築速度、メモリ使用量、クエリパフォーマンス、再現率のトレードオフが異なります。

• 選択ガイド：

  アルゴリズム	説明	距離タイプ	データ規模	再現率	レイテンシ	メモリ使用量	主なユースケース
  FLAT (formerly Linear)	ベクトル規模：数万件のベクトルに適しています。 シナリオ：完全なデータ精度（再現率 100%）が求められるシナリオ。	Inner Product、Squared Euclidean、Cosine	非常に小規模（< 1 万） 数万件	100%（正確）	非常に高い	非常に低い	ベンチマーク；極小データセットでの正確な再ランキング。
  HNSW	ベクトル規模：数千万件のベクトルに適しています。 シナリオ：精度と低レイテンシが厳しく要求されるユースケース向けの高性能オプション。	Inner Product、Squared Euclidean、Cosine	中規模（1,000 万件以上） 数千万件	非常に高い	低い	非常に高い	高性能なインメモリ型オンライン取得。
  HNSW_RaBitQ	ベクトル規模：10 億件規模のデータセットに適しています。 シナリオ：厳格なメモリ制約があり、ある程度の精度低下が許容される大規模データセット向け。	Squared Euclidean	大規模（1 億件以上） 数億	高い	非常に低い	非常に低い	バイナリ量子化により最適化された軽量取得。
  CagraHNSW	ベクトル規模：数億件のベクトルに適しています。 シナリオ：グラフインデックス向けの GPU パフォーマンス専有型ソリューション。数億件規模のデータセットでは複数 GPU を併用することが多いです。	Inner Product、Squared Euclidean	大規模（1 億件以上） 数億	非常に高い	非常に低い（GPU）	非常に高い	高スループットシナリオ向けの GPU アクセラレーション検索。
  HNSW_SQ (formerly QGraph)	ベクトル規模：10 億件規模のデータセットに適しています。 シナリオ：高クエリパフォーマンスと低レイテンシが求められ、精度要件がそれほど厳しくないユースケース向け。	Inner Product、Squared Euclidean、Cosine	非常に大規模（10 億件以上） 10 億件規模	高い	低い	高い
  IVF_SQ8	ベクトル規模：数億件のベクトルに適しています。 シナリオ：精度とレイテンシの要件が中程度の場合にバランスの取れた従来型アプローチ。	Inner Product、Squared Euclidean、Cosine	大規模（約 5 億件） 5 億件規模	中～高	中程度	低い	ベクトル圧縮によりメモリ使用量を削減する、大規模データセット向けの古典的かつ費用対効果の高いソリューション。特にコールド/ホットデータ階層化と組み合わせて、コストとスケールのバランスを取るのに最適です。
  DiskANN	ベクトル規模：最大スケール向けに設計されており、10 億件以上のベクトルデータセットを処理できます。 シナリオ：ローカルディスクを使用するため、レイテンシが多少高くてもよく、メモリ使用量を最小限に抑えたいシナリオに適しています。	Inner Product、Squared Euclidean、Cosine	超大規模（10 億件以上） 10 億件超	高い	中～高	非常に低い	超大規模データセット向けのディスク常駐型検索。

リアルタイムインデックス

• 目的：有効にすると、増分書き込みされたデータが数秒以内にインデックスされ、検索可能になります。

• 仕組み：システムはまず、リアルタイムデータ書き込み用の一時的なインメモリインデックスを構築します。この一時インデックスがあるサイズに達すると、そのデータをディスク上のフルインデックスにマージします。

• 推奨事項：

  • 有効 (true)：書き込み後すぐにデータを検索可能にする必要があるオンラインサービス向けに推奨されます。このオプションは、若干の追加メモリおよび CPU リソースを消費します。

  • 無効 (false)：オフライン分析や、フルインポート後の更新頻度が低いデータに適しています。

Linear build threshold

• 目的：シャード内のベクトル数がこのしきい値未満の場合、システムは選択したベクトルインデックスアルゴリズムを上書きし、FLAT アルゴリズムを使用して力まかせ探索を実行します。

• 推奨事項：

  • デフォルト：5000。この規模のデータセットでは、インデックス構築オーバーヘッドが低いため、力まかせ探索の方が複雑なインデックスよりも同等または優れたパフォーマンスを発揮することがよくあります。

  • 調整が必要な場合：通常、この値を変更する必要はありません。ただし、クエリ同時実行数が非常に高く、データ量がしきい値付近にある場合は、HNSW のような高性能インデックスを強制的に使用するためにこの値を下げることができます。これにより、インデックス構築オーバーヘッドが増加する可能性があります。

Ignore invalid vector data

• 目的：フルインデックスまたは増分インデックス構築中に無効なベクトル（例：ディメンション不一致や null 値）が検出された際のシステムの動作を制御します。

• 推奨事項：

  オプション	動作	推奨されるユースケース
  true	システムは無効なベクトルを含む行をスキップし、警告をログに記録した上でインデックス構築タスクを継続します。	開発およびテスト環境。少数の不良レコードによって全体のビルドタスクが失敗することを防ぎ、迅速にデバッグできます。
  false	無効なベクトルが 1 つでも検出された場合、インデックス構築タスクは直ちに失敗し、エラーを返します。	本番環境。データ品質を強制的に保証し、サイレントなデータ損失を防止します。堅牢な上流データクレンジングパイプラインと併用することを推奨します。

Real-time indexing parameters

• 目的：リアルタイムインデックスが有効な場合、これらのパラメーターでリアルタイムデータストリーム処理を微調整します。

• パラメーター例：{"proxima.oswg.streamer.segment_size":2048}

• パラメーター説明：proxima.oswg.streamer.segment_size は、メモリ内に蓄積されたリアルタイムレコードを小さなインメモリセグメントにフラッシュするまでの件数を制御します。

• チューニングの推奨事項：

  • 書き込み QPS が高いシナリオ：この値を増加させ（例：4096）、インメモリセグメント数を減らしてインデックス管理オーバーヘッドを低減します。これにより、書き込みから検索可能になるまでのレイテンシがわずかに増加します。

  • 書き込み QPS が低いシナリオ：デフォルト値 2048 のままにするか、さらに小さくして、新しく書き込まれたデータをより迅速に検索可能にします。

Real-time retrieval parameters

• 目的：クエリ時にインデックスアルゴリズムの検索動作を動的に調整し、再現率とレイテンシのバランスを取ります。このパラメーターのキーと値は、選択したベクトルインデックスアルゴリズムによって異なります。

• 一般的な説明：これらのパラメーターは通常、検索範囲を制御します。たとえば、HNSW アルゴリズムでは、ef パラメーターが検索中に走査する近傍ノード数を制御します。ef 値を大きくすると再現率が向上しますが、クエリレイテンシも増加します。

• 構成例（HNSW）：

  • {"searcher_name":"HNSW", "ef":200}

  • ef の値は通常、k（返却する上位結果の件数）から 4096 の範囲です。良い開始値は 100 で、再現率とレイテンシに関するビジネス要件に基づいて調整できます。

Vector separator

• 目的：文字列形式のベクトルデータにおいて、各ディメンション値の間に使用される区切り文字を定義します。

• 例：ベクトルデータ 1.05,0.15,0.14 の場合、区切り文字はカンマ（,）で、これはシステムのデフォルトです。通常、この設定を変更する必要はありません。

書き込みボリューム制御

• バッチサイズの制限：1 回のバッチで書き込むドキュメント数を過剰にしないでください。ベクトルディメンションおよびインスタンスタイプに基づいてデータをより小さなバッチに分割し、データ処理メモリ使用量の急激な増加を防いでください。

• 書き込み頻度の制御：高頻度書き込みシナリオでは、書き込み同時実行数を減らすか、バッチ間の間隔を長くすることを検討してください。これにより、インデックス構築およびセグメントのマージに十分な時間が確保されます。

• データ処理メモリの監視：書き込み後も全体のインスタンスメモリが十分あるにもかかわらずデータ処理メモリ使用量が高止まりしている場合は、インデックス構築またはセグメントのマージによるメモリオーバーヘッドが高いことを示しています。このような場合は、書き込みレートを下げ、マージ操作が完了するまで待機した後に再開してください。

リソース評価とスケーリング

データ処理メモリが不足している、またはクエリレイテンシが著しく増加している場合は、現在のインスタンスタイプがビジネス要件を満たしているか評価してください。

• スペック電卓 を使用し、ベクトルディメンション、データ量、QPS などのビジネスパラメーターを入力することで、推奨インスタンスタイプを取得できます。

• 電卓が現在のインスタンスタイプが不十分であると示した場合は、インスタンス構成を変更してデータノードのメモリおよび計算リソースをスペックアップしてください。