HNSW索引のアーキテクチャ: トランザクションのサポートと永続性

Hierarchical Navigable Small World (HNSW)索引は、効率的なベクトル検索のために設計された特殊なメモリー専用構造です。HNSW索引が作成されると、実表に対して実行された後続の挿入、更新または削除(DML操作)は索引に反映されません。

トランザクション・データ操作での正確性、パフォーマンスおよび整合性を維持するために、Oracleでは、いくつかのサポート・データ構造を採用しています。このページでは、HNSW索引について、トランザクションのベクトル検索と永続性の維持に使用される主要な内部コンポーネントの概要を示します。

トランザクション・サポートの構造:

  • プライベート・ジャーナルは、ベクトル・メモリー・プール内に存在する、インメモリーの、トランザクションごとの構造です。これにより、アクティブなトランザクションによって挿入または削除されたベクトルがすべて取得されます。これは、インメモリー列ストア・データの保守に使用されるトランザクション・ジャーナル(『Oracle AI Database In-Memoryガイド』を参照)に類似しています。

  • 共有ジャーナルは、各HNSW索引とともに作成される、ディスク上の、表ベースのコンポーネントです。これにより、索引付きベクトル列を変更したコミット済トランザクションの履歴が保持されます。各ジャーナル・エントリには、コミットSCNが関連付けられており、メタデータ(挿入されたベクトルの識別子や削除されたベクトルの識別子など)が含まれています。

  • すべてのHNSW索引には、それぞれの実表の行ID (ROWID)をそのHNSWグラフで使用されている対応するベクトルID (VID)にリンクする、専用のROWIDとVIDのマッピング表が含まれています。

グラフのリフレッシュと永続性の構造:

索引の作成後に実行される問合せでは、索引に加え、上位K件の結果を取得するためにその後に発生したDMLを参照する必要があります。DMLが蓄積されていくと、共有ジャーナルのベクトルでの正確な検索が、現在索引付けされているHNSWグラフの近似検索よりも高コストになるため、問合せが遅くなります。パフォーマンスと精度を維持するために、Oracleでは、自動化されたグラフ・リフレッシュおよび永続性メカニズムが提供されています。

  • 増分スナップショットとは、特定のSCNに関連付けられているHNSWグラフの、更新されたインメモリー・バージョンを意味します。これにより、新規挿入されたベクトルがグラフに追加され、コンパクトなビットマップを使用して削除が追跡されます。スナップショットにより、共有ジャーナルのオーバーヘッドが減少し、問合せのパフォーマンスが向上し、メモリー使用率が最小限になります。それらは、特に、小さいDML操作が頻繁に発生する場合に有効です。

    ノート:

    • 最新スナップショットの構築SCNを下回る問合せは、エラーORA 51815「INMEMORY NEIGHBOR GRAPH HNSWベクトル索引スナップショットが古すぎます。」になります。
  • 増分リフレッシュが非効率になると(通常は、削除されたベクトルの蓄積が原因)、現在の実表を使用してゼロからHNSWグラフを再構築するために、完全再移入がトリガーされます。既存のグラフを更新する増分スナップショットとは異なり、完全な再移入では、進行中の問合せに対して古いグラフをアクティブに保ちながら、新しいグラフが作成されます。

    ノート:

    完全再移入時(新しいHNSWグラフを使用可能になるまで)に、問合せで、存在しなくなった古いバージョンのHNSWグラフへのアクセスが試みられると、読取り一貫性エラー(ORA-51815「INMEMORY NEIGHBOR GRAPH HNSWベクトル索引スナップショットが古すぎます。」)が発生します。

  • チェックポイントは、HNSWグラフのトポロジおよびメタデータの、ディスクベースのシリアライズされたコピーです(実際のベクトルではない)。それは、キー・イベント(索引の作成や再移入など)の間に自動的に作成されます。

    分散HNSW索引により、複数のチェックポイントが作成されます(各RACインスタンスによってホストされているHNSWスライス・グラフごとに1つ)。チェックポイント作成済グラフは、特定の物理インスタンスに関連付けられていません。かわりに、それらはそのHNSWスライス・グラフを所有するインスタンスに関連付けられています。システムにより、インスタンスの障害発生中や削除時に索引を簡単に再分散できるように、どのHNSWスライス・グラフがどのインスタンスに属するかが追跡されます。インスタンス障害発生時は、障害が発生したインスタンスと同じHNSWスライス・グラフにマップされているRACインスタンスで、既存のチェックポイント作成済グラフが直接再利用されます。それにより、リカバリが早まり停止時間が短くなります。

    DBMS_VECTOR PL/SQLパッケージのENABLE_CHECKPOINTプロシージャとDISABLE_CHECKPOINTプロシージャを使用することで、完全HNSWチェックポイントを無効化または再有効化できます。

グラフ・リフレッシュの明示的な指定

DBMS_VECTOR.REBUILD_INDEXプロシージャのidx_rebuild_modeパラメータを使用して、HNSWグラフのリフレッシュ方法を指定できます。このパラメータには、値FULLまたはINCREMENTALを指定できます。これにより、完全なグラフ再構築が可能になります。デフォルトでは、idx_rebuild_modeはNULLに設定されます。この場合、システムは既存の動作に従い、索引を削除して再作成します。idx_rebuild_modeにより、索引リフレッシュ操作を管理する際にきめ細かい制御が可能になります。

完全な再移入をトリガーする例:

execute dbms_vector.rebuild_index('galaxies_hnsw_idx', 
                                           'galaxies', 
                                           'embedding', 
                                            NULL, 
                                            NULL, 
                                           'INMEMORY NEIGHBOR GRAPH', 
                                           'EUCLIDEAN', 
                                            95, 
                                            FULL, 
                                           '{"type" : "HNSW", "neighbors" : 3, "efConstruction" : 4 }') ;

ノート:

このコードは、索引galaxies_hnsw_idxがgalaxies表にすでに作成されていることを前提としています。HNSW索引の作成に関するガイダンスは、Hierarchical Navigable Small World (HNSW)索引の構文およびパラメータに関するOracleドキュメントを参照してください。

HNSW索引では、トランザクションの一貫性がある上位Kの結果を取得する間に、パフォーマンスと精度のバランスを取るために、これらの構造が利用されます。それらを組み合せることで、頻繁な更新と削除によって表が進化する場合でも、必ずスケーラブルかつ低遅延のベクトル検索になります。

親トピック: インメモリー近傍グラフ・ベクトル索引について