翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ベクトル検索の概要
ElastiCache for Valkey は、数十億の高次元ベクトル埋め込みのインデックス作成、検索、更新を行う機能を提供します。ベクトル検索を使用すると、セカンダリインデックスを作成、保守、使用して、効率的でスケーラブルな検索を行うことができます。各ベクトル検索オペレーションは、1 つのインデックスに適用されます。インデックスオペレーションは、指定されたインデックスにのみ適用されます。インデックスの作成オペレーションと削除オペレーションを除き、任意のインデックスに対して任意の数のオペレーションをいつでも発行できます。クラスターレベルでは、複数のインデックスに対する複数のオペレーションが同時に進行している可能性があります。
このドキュメント内では、キー、行、レコードという用語は同一のものであり、相互互換的に使用されます。同様に、列、フィールド、パス、メンバーという用語も相互互換的に使用されます。
FT.CREATE コマンドを使用すると、指定したインデックスタイプのキーのサブセットに対してインデックスを作成できます。FT.SEARCH は、作成されたインデックスに対してクエリを実行し、FT.DROPINDEX は既存のインデックスと関連するすべてのデータを削除します。インデックス付きデータを追加、削除、変更するための特別なコマンドはありません。インデックス内のキーを変更する既存の HASH または JSON コマンドは、インデックスを自動的に更新します。
インデックスと Valkey OSS キースペース
インデックスは、Valkey OSS キースペースのサブセット上で構築および維持されます。各インデックスのキースペースは、インデックスの作成時に提供されるキープレフィックスのリストによって定義されます。プレフィックスのリストはオプションであり、省略した場合、キースペース全体がそのインデックスの一部になります。複数のインデックスは、制限なく、キースペースの素のサブセットまたは重複するサブセットを選択できます。
また、インデックスは、型が一致するキーのみをカバーするという点で型指定されます。現在、インデックスは JSON 型と HASH 型でのみサポートされています。HASH インデックスは、プレフィックスリストによってカバーされる HASH キーのインデックスのみを作成します。同様に、JSON インデックスは、プレフィックスリストによってカバーされる JSON キーのインデックスのみを作成します。インデックスのキースペースプレフィックスリスト内のキーのうち、指定されたタイプを持たないキーは無視され、検索オペレーションに影響を及ぼしません。
コマンドがインデックスのキースペース内にあるキーを変更すると、そのインデックスが更新されます。Valkey は、各インデックスの宣言されたフィールドを自動的に抽出し、インデックスを新しい値で更新します。更新プロセスには 3 つのステップがあります。最初のステップでは、HASH または JSON キーが変更され、リクエスト元のクライアントがブロックされます。2 番目のステップはバックグラウンドで実行され、変更されたキーを含む各インデックスをそれぞれ更新します。3 番目のステップでは、クライアントはブロック解除されます。したがって、ミューテーションと同じ接続で実行されるクエリオペレーションの場合、その変更はすぐに検索結果に表示されます。
インデックスの作成は複数のステップからなるプロセスです。最初のステップは、インデックスを定義する FT.CREATE コマンドを実行することです。作成が正常に実行されると、2 番目のステップであるバックフィルが自動的に開始されます。バックフィルプロセスはバックグラウンドスレッドで実行され、キースペースをスキャンして、新しいインデックスのプレフィックスリスト内にあるキーを探します。見つかった各キーはインデックスに追加されます。最終的にはキースペース全体がスキャンされて、インデックス作成プロセスが完了します。バックフィルプロセスの実行中は、インデックス付きキーのミューテーションが許可され、制限はなく、すべてのキーのインデックスが適切に作成されるまではインデックスバックフィルプロセスが完了しないことに留意してください。インデックスのバックフィル中に試行されるクエリオペレーションは許可されず、エラーで終了します。FT.INFO コマンドは、バックフィルプロセスのステータスを 'backfill_status' フィールドに入れて返します。
インデックスフィールドの型
各インデックスには、インデックスの作成時に宣言される特定の型と、インデックスが作成されるフィールド (列) の場所が含まれます。HASH キーの場合、その場所は HASH 内のフィールド名です。JSON キーの場合、その場所は パスの説明です。キーが変更されると、宣言されたフィールドに関連付けられたデータが抽出され、宣言された型に変換されてインデックスに格納されます。データが欠落している場合、または宣言された型に正常に変換できない場合、そのフィールドはインデックスから省略されます。次で説明するように、フィールドには 3 つのタイプがあります。
-
ベクトルフィールドには、ベクトル埋め込みとも呼ばれる数値のベクトルが含まれます。ベクトルフィールドを使用すると、類似度を測定する指定された距離メトリクスに基づいてベクトルをフィルタリングできます。
HASHインデックスの場合、フィールドにはバイナリ形式 (リトルエンディアンIEEE 754) でエンコードされたベクトル全体が含まれている必要があります。JSONキーの場合、パスは数字が入力されている正しいサイズの配列を参照する必要があります。なお、JSON 配列をベクトルフィールドとして使用すると、JSON キー内の配列の内部表現が、選択したアルゴリズムに必要な形式に変換され、メモリ消費量と精度が削減されます。JSON コマンドを使用した後続の読み取りオペレーションでは、精度の値が小さくなります。 -
数値フィールドには 1 つの数値が含まれます。数値フィールドは範囲検索演算子とともに使用できます。
HASHの場合、フィールドには、固定小数点数または浮動小数点数の標準形式で記述された数値の ASCII テキストが含まれることが想定されます。JSONフィールドの場合、JSON 数値の数値規則に従う必要があります。キー内の表現にかかわらず、このフィールドはインデックス内に格納するために 64 ビットの浮動小数点数に変換されます。基になる数値は精度制限のある浮動小数点で格納されるため、浮動小数点数の数値比較に関する通常のルールが適用されます。 -
タグフィールドには、単一の UTF-8 文字列としてコード化された 0 個以上のタグ値が含まれます。タグフィールドを使用すると、大文字と小文字を区別する比較または大文字と小文字を区別しない比較で、タグ値の同等性についてクエリをフィルタリングできます。文字列は、先頭と末尾の空白が削除された区切り文字 (デフォルトはカンマだが、上書きが可能) を使用してタグ値に解析されます。単一のタグフィールドには、任意の数のタグ値を含めることができます。
ベクトルインデックスアルゴリズム
Valkey では、2 つのベクトルインデックスアルゴリズムがサポートされています。
-
Flat – Flat アルゴリズムは、インデックス内の各ベクトルの総当たり線形処理であり、距離計算の精度の範囲内で正確な答えを生成します。インデックスの線形処理のため、インデックスが大きい場合、このアルゴリズムの実行時間が非常に長くなる可能性があります。フラットインデックスは、より高速の取り込みをサポートします。
-
Hierarchical Navigable Small Worlds (HNSW) – HNSW アルゴリズムは、実行時間を大幅に短縮する代わりに、最も近いベクトル一致の近似値を提供する代替手段です。このアルゴリズムは、
M、EF_CONSTRUCTION、EF_RUNTIMEの 3 つのパラメータによって制御されます。最初の 2 つのパラメータはインデックスの作成時に指定され、変更できません。EF_RUNTIMEパラメータにはインデックスの作成時に指定されるデフォルト値が含まれていますが、その後の個々のクエリオペレーションで上書きできます。これらの 3 つのパラメータは相互に影響し合って、取り込みおよびクエリオペレーション中のメモリと CPU 消費のバランスを取るだけでなく、正確な KNN 検索の近似値の質 (再現率と呼ばれます) を制御します。
HNSW では、パラメータ M は各ノードが接続できるネイバーの最大数を制御し、インデックス密度を形成します。M の値を大きくすると (32 以上など)、より接続されたグラフが生成され、関連するネイバーに到達するためのパスが増えるため、再現率とクエリ速度が向上します。ただし、インデックスサイズとメモリ使用量が増加し、インデックス作成が遅くなります。M の値を小さくすると (8 以下など)、インデックスが小さくなり、インデックス作成が高速化し、メモリ使用量も減少しますが、接続数が減少することで再現率が低下し、クエリに時間がかかるようになる場合があります。
パラメータ EF_construction は、インデックスの作成時に評価される接続の候補の数を示します。EF_construction の値を大きくすると (400 以上など)、インデクサがネイバーを選択する前に検討するパスが増えるため、後の再現率とクエリ効率がいずれも向上するグラフになりますが、それと引き換えにインデックス作成が遅くなり、構築中の CPU とメモリの使用量が増加します。EF_construction の値を小さくすると (64～120 など)、インデックス作成が高速化し、リソースの使用量が減少しますが、EF_runtime を大きな値に設定したとしても、結果のグラフの再現率が低下し、クエリが遅くなる可能性があります。
最後に、EF_runtime はクエリ中の検索の幅を管理し、実行時に探索されるネイバーの候補の数を制御します。これを大きな値に設定すると、再現率と精度は向上しますが、クエリのレイテンシーと CPU の使用量が犠牲になります。EF_runtime の値が小さければ、クエリは高速かつ軽量になりますが、再現率は低下します。M や EF_construction とは異なり、このパラメータはインデックスのサイズや作成時間には影響せず、インデックスの作成後に再現率とレイテンシーのトレードオフを調整するパラメータになります。
両方のベクトル検索アルゴリズム (Flat および HNSW) は、オプションの INITIAL_CAP パラメータをサポートしています。このパラメータを指定すると、インデックス用にメモリが事前に割り当てられるため、メモリ管理のオーバーヘッドが削減され、ベクトルの取り込み速度が向上します。フラットインデックスは、HNSW よりも優れた取り込み速度をサポートします。
HNSW などのベクトル検索アルゴリズムは、以前に挿入されたベクトルの削除または上書きを効率的に処理できない場合があります。これらのオペレーションを使用すると、インデックスメモリが過剰に消費されたり、再現の質が低下したりする可能性があります。インデックスの再作成は、最適なメモリ使用量および/または再現を復元するための 1 つの方法です。
ベクトル検索のセキュリティ
コマンドアクセスとデータアクセスの両方のための Valkey ACL (アクセスコントロールリスト)@search が提供され、既存のカテゴリの多く (@fast、@read、@write など) が新しいコマンドを含むように更新されます。検索コマンドはキーデータを変更しません。これは、書き込みアクセス用の既存の ACL 機構が保持されることを意味します。HASH および JSON オペレーションのアクセスルールは、インデックスが存在することで変更されることはありません。これらのコマンドには、通常のキーレベルのアクセスコントロールが引き続き適用されます。
また、インデックスを使用した検索コマンドでは、ACL を通じてアクセスが制御されます。アクセスチェックは、キーごとのレベルではなく、インデックス全体のレベルで実行されます。これは、そのインデックスのキースペースプレフィックスリストに含まれているすべての可能なキーにアクセスするための許可がユーザーに付与されている場合にのみ、インデックスに対するアクセスがユーザーに付与されることを意味します。つまり、インデックスの実際の内容はアクセスを制御しません。むしろ、これは、セキュリティチェックのために使用されるプレフィックスリストによって定義されるインデックスの理論的な内容です。キーに対する読み取りおよび/または書き込みアクセスがユーザーに付与されているにもかかわらず、そのキーを含むインデックスにアクセスできないという状況が起こりえます。インデックスの作成または使用にはキースペースに対する読み取りアクセスのみが必要であり、書き込みアクセスの有無は考慮されないことに留意してください
