Oracle RACでのHNSW分散

Hierarchical Navigable Small World (HNSW)索引を複数のOracle Real Application Clusters (Oracle RAC)インスタンスにわたり分散できる方法について学習します。

Oracle RACでの分散HNSW索引により、RAC (Real Application Clusters)環境において、複数のインスタンスにわたるスケーラブルな類似検索が可能になります。分散HNSW索引では、次のようになります:
  • ベクトル・データは、メモリー効率の高い方法で、複数のRACインスタンスにわたりセグメント化され分散されます。
  • 各インスタンスにより、その割り当てられたベクトル・データ・サブセットに基づいてHNSWスライス・グラフが構築され、管理されます。完全HNSW索引は、これらのHNSWスライス・グラフの論理和です。
  • 問合せの実行中に、各インスタンスにより、そのHNSWスライス・グラフが検索され、部分的な結果がマージされて最終的な問合せ結果が生成されます。

分散HNSW索引を使用する理由

次の項では、分散HNSW索引を使用する利点について概要を示します。
  • 水平方向のスケーラビリティ

    メモリー効率の高い方法でベクトル・データを複数のRACインスタンスに分散すると、使用可能なメモリーの総量をクラスタ・サイズに合わせてスケーリングできます。HNSW索引は、単一インスタンスのメモリー・リソースや処理リソースによって制約されることがなくなりました。各RACインスタンスにより、そのHNSWスライス・グラフが個別に構築され保守されます。それにより、単一の分散HNSW索引を、データ・ボリュームとベクトルの次元の増加に応じてスケーリングできます。

  • パラレル化

    複数のRACインスタンスにわたるパラレル索引操作および問合せ実行が可能になります。各RACインスタンスで、それ固有のHNSW索引メンテナンスおよび問合せ処理に対応します。それにより、単一インスタンスがボトルネックになるのを防ぎ、その結果、問合せスループットが向上します。

  • 効率性

    複数のインスタンスにわたり冗長なグラフ・ストレージおよび構築時計算がなくなります。これにより、メモリー使用率が大幅に改善され、全体的な索引構築およびメンテナンス・コストが減少します。

  • リジリエンスと柔軟性

    必要に応じて索引データを再分散することで、クラスタの変化に自動的に適応します。これにより、障害分離が向上し、インスタンスの障害発生時やクラスタからの削除時の、クラスタのリバランスがサポートされます。詳細は、クラスタ・ノード障害発生中のHNSW索引の可用性とパフォーマンスについてを参照してください

使用上の注意

  • パラレルDML操作はサポートされていません

    分散HNSW索引では、パラレルDML操作はサポートされていません。

  • スナップショットはサポートされていません

    分散HNSW索引では、スナップショットはサポートされていません。分散HNSW索引のリフレッシュに使用される方法は、完全再移入のみです。HNSW索引の完全再移入操作がトリガーされる理由とタイミングの詳細は、「HNSW索引のアーキテクチャ: トランザクションのサポートと永続性」を参照してください。

  • カバー列はサポートされていません

    HNSW索引にカバー列(余分な列)を含めることはサポートされていません。問合せで索引付きベクトル列以外の列が必要な場合は、Oracle AI Databaseによって、その問合せの処理中に自動的に実表が使用されます。

  • 特定のクラスタ変化で索引が再構築されます

    クラスタ・サイズが小さくなり、すべてのHNSWスライス・グラフをホストするための使用可能なインスタンスの数が不足すると、Oracleによって索引が再構築されます。

  • オンライン索引構築はサポートされていません

    複数の同時DML操作による分散HNSW索引のオンライン作成はサポートされていません。

  • クラスタの再構成中は索引を使用できません

    インスタンスに障害が発生するかインスタンスが削除されると、影響を受けるHNSWスライス・グラフが一時的に無効になります。グラフが再分散または再構築されるまで、索引を問合せに使用できません。

分散HNSW索引: おおまかなワークフロー

  • DISTRIBUTE句を使用した索引作成

    CREATE VECTOR INDEX 文でDISTRIBUTE句を指定することで、分散HNSW索引を作成します。次のいずれかの分散方法を選択できます:
    • BY ROWID RANGE
    • BY PARTITION
    • BY SUBPARTITION
    DISTRIBUTE句を使用して分散方法が指定されていない場合は、Oracle AI Databaseによって、デフォルトのDISTRIBUTE AUTOに設定されます。DISTRIBUTE AUTOモードにおいては、非パーティション表ではROWID RANGE分散が使用され、パーティション表では[SUB] PARTITION分散が使用されます。

    分散HNSW索引の作成の構文:

    CREATE VECTOR INDEX index_name ON table_name(column_name)
    ORGANIZATION INMEMORY NEIGHBOR GRAPH
    WITH <distance_and_target_metrics>
    DISTRIBUTE [AUTO | BY ROWID RANGE | BY PARTITION | BY SUBPARTITION ];

    関連項目:

    CREATE VECTOR INDEX
  • RACインスタンスのメモリー評価

    調整インスタンスにより、すべての参加RACインスタンスにわたる使用可能なベクトル・プール・メモリーを見積もるためにメモリー・チェック(インスタンス間調整コール)が開始されます。各参加インスタンスにより、その推定された使用可能メモリーが報告されます。この情報は、様々なインスタンスにわたり比例的かつ効率的にベクトル・データを割り当てるために使用されます。

  • ベクトル・データセットのパーティション化

    Oracle AI Databaseによって、選択した分散方法を使用して、ベクトル・データセットが、ベクトル分散ユニットと呼ばれる論理単位に分割されます。分散ユニットとHNSWスライス・グラフの間のマッピングは、メンテナンスとリカバリのために補助メタデータ構造で記録されます。

  • 分散グラフ構築の開始

    調整インスタンスにより、すべての参加インスタンス(それ自体を含む)がトリガーされて、それらの割り当てられているベクトル・データについてHNSWスライス・グラフの構築が開始されます。グラフ構築は、必ずすべてのインスタンスでそれらのHNSWスライス・グラフの構築が正常に完了するように、一元的に調整され監視されます。

  • RACでのグラフ構築

    各RACインスタンスにより、その割り当てられているベクトル・データが実表から読み取られ、そのHNSWスライス・グラフが構築されます。その後、完了したグラフのチェックポイントが作成されます。

    割り当てられているベクトル・データに基づいて構築されたHNSWスライス・グラフは、そのベクトル・データセットのパーティション化に使用されている分散方法に従って次のように分類されます:
    • HNSW rowid-range-sliceグラフ: ROWID RANGE分散方法を使用してパーティション化されたベクトル・データのサブセットに基づいて構築されたHNSWグラフ。このコンテキストでは、"slice"はベクトル・データのサブセットを示しており、"rowid-range"は分散方法を示しています。
    • HNSW partition-sliceグラフ: PARTITIONまたはSUBPARTITION分散方法を使用してパーティション化されたベクトル・データのサブセットに基づいて構築されたHNSWグラフ。このコンテキストでは、"slice"はベクトル・データのサブセットを示しており、"partition"は分散方法を示しています。
  • 索引の最終処理

    分散HNSW索引のすべてのHNSWスライス・グラフが構築されチェックポイント作成が実行された後に、調整インスタンスにより、その索引が使用可能としてマークされます。これで、その索引を、分散されたパラレル類似検索問合せ(それぞれが、関連するインスタンスに効率的にルーティングされている)に使用できるようになりました。

  • 分散された問合せの実行

    ベクトル検索問合せが発行されると、Oracle AI Databaseにより、HNSWスライス・グラフをホストするすべてのインスタンスが識別されます。その問合せは、これらすべてのインスタンスにわたり並行して実行されます。

    各問合せにより、ef_searchk (近傍の数)など、構成されている検索パラメータを使用して、そのHNSWスライス・グラフに対して近似最近傍(ANN)検索が実行されます。

    トランザクションの整合性を確保するために、各インスタンスにより、索引付けされていない変更(まだ索引付けされていない、コミットされた挿入および削除)について共有ジャーナルがスキャンされ、それらが類似検索に含まれます。

    問合せオプティマイザにより、十分なパラレル化を使用可能な場合(索引をホストしているインスタンスごとにPQプロセスが1つ以上)のみ分散索引計画が選択されます。そうでない場合は、Oracle AI Databaseにより、索引なしの計画にフォールバックされます。

    オプティマイザ計画に関する情報は、「HNSWベクトル索引のオプティマイザ計画」を参照してください。

  • 索引のメンテナンスと永続性

    • HNSWの複数のチェックポイント: チェックポイント作成が有効になっている場合は、インスタンス障害発生後のリカバリを迅速化するために複数のチェックポイントが作成されます。各RACインスタンスによってホストされているHNSWスライス・グラフごとに1つのチェックポイントです。詳細は、チェックポイント作成を参照してください。
    • クラスタ再構成: リーダー・インスタンスにより、クラスタの変化(インスタンスの障害発生や削除など)が監視されて、これらの変化に動的に適応することで索引の整合性が維持されます。詳細は、クラスタ・インスタンス障害発生中のHNSW索引の可用性とパフォーマンスについてを参照してください

HNSW RAC複製とHNSW索引分散の対比

表6-1 複製と分散の対比

HNSW RAC複製 HNSW索引分散

データ・アクセス

各インスタンスによってベクトル・データセット全体が読み取られて、完全HNSWグラフが作成されます。

データ・アクセス

そのベクトル・データセットは、複数のベクトル分散ユニットに分割されます(by ROWID RANGEby [SUB]PARTITION)。各インスタンスにより、それに割り当てられているベクトル・データのサブセットのみが読み取られます。

索引構造

各RACインスタンスには、そのベクトル・データセット全体についての、HNSWグラフの同一かつ完全なコピーが含まれています。

索引構造

各インスタンスでは、完全HNSW索引の一部分(HNSWスライス・グラフ)のみが保持されます。

メモリー使用率

高: すべてのインスタンスで、索引全体がメモリーに保持されている必要があります。

メモリー使用率

効率的: メモリー・ロードはすべてのンスタンスにわたり分割され、各インスタンスで、完全HNSW索引の一部分(HNSWスライス・グラフ)のみが保持されます。

索引構築プロセス

調整RACインスタンスにより、それで作成されたHNSWグラフのディスク・チェックポイントが作成されてから、他のすべての参加RACインスタンスにより、そのディスク・チェックポイントを使用してそのグラフがロードされます。すべてのインスタンスで、ベクトル・データセット全体を使用したHNSWグラフ全体が個別にロードされます。

索引構築プロセス

各インスタンスにより、そのインスタンスに割り当てられているベクトル・データのサブセットについて、HNSWスライス・グラフが構築されます。

問合せ実行

問合せは単一インスタンスで実行されます(複数のRACインスタンスにわたる並列処理ではない)。

問合せ実行

問合せは、HNSWスライス・グラフを保持しているすべてのインスタンスにわたり分散されパラレル化されます。

リソース使用率

悪い: すべてのインスタンスで、冗長なストレージと構築計算になります。

リソース使用率

良い: すべてのインスタンスにわたり、ストレージは冗長ではなく、ワークロードが分散されます。

スケーラビリティ

単一インスタンスのメモリーおよび処理能力によって制限されます。

スケーラビリティ

クラスタ・サイズに合わせてスケーリングします。非常に大きなデータセットに対応できます。

クラスタ再構成

クラスタに変化があった場合は、すべてのインスタンスで、完全HNSW索引をリロードまたは再構築する必要があります。

クラスタ再構成

影響を受けるHNSWスライス・グラフのみが再分散または再構築されます。

最適なユースケース

小さいデータセット

最適なユースケース

大規模な、または増大するデータセット