翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ベクトル検索 MemoryDB のベクトル検索は、MemoryDB の機能を拡張します。ベクトル検索は、既存の MemoryDB 機能と組み合わせて使用できます。ベクトル検索を使用しないアプリケーションは、ベクトル検索が存在していることによる影響を受けません。ベクトル検索は、MemoryDB が利用可能なすべてのリージョンで使用できます。 ベクトル検索は、高速ベクトル検索を実現しながらアプリケーションのアーキテクチャを簡素化します。MemoryDB のベクトル検索は、ピークのパフォーマンスとスケールが最も重要な選択基準であるユースケースに最適です。既存の MemoryDB データ、または Valkey または Redis OSS API を使用して、機械学習と生成 AI のユースケースを構築できます。これには、取得拡張生成、異常検出、ドキュメント取得、リアルタイムレコメンデーションが含まれます。 6/26/2024 の時点で、 AWS MemoryDB は一般的なベクトルデータベースの中で最高の再現率で最速のベクトル検索パフォーマンスを提供します AWS。 **Topics** + [ # ベクトル検索の概要 ](vector-search-overview.md) + [ # ユースケース ](vector-search-examples.md) + [ # ベクター検索の機能と制限 ](vector-search-limits.md) + [ # ベクトル検索が有効になっているクラスターを作成する ](vector-search-cluster.md) + [ # ベクトル検索コマンド ](vector-search-commands.md) # ベクトル検索の概要 ベクトル検索は、インデックスの作成、メンテナンス、使用を基盤として構築されています。各ベクトル検索オペレーションは単一のインデックスを指定し、そのオペレーションはそのインデックスに限定されます。すなわち、1 つのインデックスに対するオペレーションは、他のインデックスに対するオペレーションの影響を受けません。インデックスの作成および破棄のオペレーションを除き、任意のインデックスに対して任意の数のオペレーションをいつでも発行できます。これは、クラスターレベルでは、複数のインデックスに対する複数のオペレーションが同時に進行する可能性があることを意味します。 個々のインデックスは、他の Valkey および Redis OSS 名前空間 (キー、関数など) とは異なる、一意の名前空間に存在する名前付きオブジェクトです。各インデックスは、列と行の 2 つの次元で構造化されているという点で、概念的には従来のデータベーステーブルと似ています。テーブル内の各行はキーに対応します。インデックス内の各列は、そのキーのメンバーまたは部分に対応します。このドキュメント内では、キー、行、レコードという用語は同一のものであり、相互互換的に使用されます。同様に、列、フィールド、パス、メンバーという用語は本質的に同一のものであり、これらも相互互換的に使用されます。 インデックス付きデータを追加、削除、変更するための特別なコマンドはありません。むしろ、インデックス内のキーを変更する既存の **HASH** または **JSON** コマンドが、インデックスも自動的に更新します。 **Topics** + [ ## インデックスと Valkey および Redis OSS キースペース ](#vector-search-indexes-keyspaces) + [ ## インデックスフィールドの型 ](#vector-search-index-field-types) + [ ## ベクトルインデックスアルゴリズム ](#vector-search-index-algorithms) + [ ## ベクトル検索のクエリ式 ](#vector-search-query-expression) + [ ## INFO コマンド ](#vector-search-ft.info) + [ ## ベクトル検索のセキュリティ ](#vector-search-security) ## インデックスと Valkey および Redis OSS キースペース インデックスは、Valkey および Redis OSS キースペースのサブセット上で構築および維持されます。複数のインデックスは、制限なく、キースペースの素のサブセットまたは重複するサブセットを選択できます。各インデックスのキースペースは、インデックスの作成時に提供されるキープレフィックスのリストによって定義されます。プレフィックスのリストはオプションであり、省略した場合、キースペース全体がそのインデックスの一部になります。また、インデックスは、型が一致するキーのみをカバーするという点で型指定されます。現在、JSON インデックスと HASH インデックスのみがサポートされています。HASH インデックスは、プレフィックスリストによってカバーされる HASH キーのインデックスのみを作成し、同様に、JSON インデックスは、プレフィックスリストによってカバーされる JSON キーのインデックスのみを作成します。インデックスのキースペースプレフィックスリスト内のキーのうち、指定されたタイプを持たないキーは無視され、検索オペレーションに影響を及ぼしません。 HASH または JSON コマンドがインデックスのキースペース内にあるキーを変更すると、そのインデックスが更新されます。このプロセスには、各インデックスについて宣言されたフィールドを抽出し、新しい値でインデックスを更新することが含まれます。更新プロセスはバックグラウンドスレッドで実行されます。これは、インデックスが最終的にキースペースの内容と一致することを意味します。そのため、キーの挿入または更新は、すぐに検索結果に表示されません。システム負荷および/またはデータのミューテーションが多い期間中は、表示できるようになるまでの遅延が長くなる可能性があります。 インデックスの作成は複数のステップからなるプロセスです。最初のステップは、インデックスを定義する [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) コマンドを実行することです。作成が正常に実行されると、2 番目のステップであるバックフィルが自動的に開始されます。バックフィルプロセスはバックグラウンドスレッドで実行され、キースペースをスキャンして、新しいインデックスのプレフィックスリスト内にあるキーを探します。見つかった各キーはインデックスに追加されます。最終的にはキースペース全体がスキャンされて、インデックス作成プロセスが完了します。バックフィルプロセスの実行中は、インデックス付きキーのミューテーションが許可され、制限はなく、すべてのキーのインデックスが適切に作成されるまではインデックスバックフィルプロセスが完了しないことに留意してください。インデックスのバックフィル中に試行されるクエリオペレーションは許可されず、エラーで終了します。バックフィルプロセスの完了は、そのインデックスについての `FT.INFO` コマンドの出力 (「backfill\$1status」) から判断できます。 ## インデックスフィールドの型 インデックスの各フィールド (列) には、インデックスの作成時に宣言される特定の型と、キー内の場所が含まれます。HASH キーの場合、その場所は HASH 内のフィールド名です。JSON キーの場合、その場所は JSON パスの説明です。キーが変更されると、宣言されたフィールドに関連付けられたデータが抽出され、宣言された型に変換されてインデックスに格納されます。データが欠落している場合、または宣言された型に正常に変換できない場合、そのフィールドはインデックスから省略されます。次で説明するように、フィールドには 4 つのタイプがあります: + **数値フィールド**には 1 つの数値が含まれます。JSON フィールドの場合、JSON 数値の数値規則に従う必要があります。HASH の場合、フィールドには、固定小数点数または浮動小数点数の標準形式で記述された数値の ASCII テキストが含まれることが想定されます。キー内の表現にかかわらず、このフィールドはインデックス内に格納するために 64 ビットの浮動小数点数に変換されます。数値フィールドは範囲検索演算子とともに使用できます。基になる数値は精度制限のある浮動小数点で格納されるため、浮動小数点数の数値比較に関する通常のルールが適用されます。 + **タグフィールド**には、単一の UTF-8 文字列としてコード化された 0 個以上のタグ値が含まれます。文字列は、先頭と末尾の空白が削除された区切り文字 (デフォルトはカンマだが、上書きが可能) を使用してタグ値に解析されます。単一のタグフィールドには、任意の数のタグ値を含めることができます。タグフィールドを使用すると、大文字と小文字を区別する比較または大文字と小文字を区別しない比較で、タグ値の同等性についてクエリをフィルタリングできます。 + **テキストフィールド**には、UTF-8 に準拠している必要のないバイトの BLOB が含まれています。テキストフィールドを使用すると、アプリケーションにとって意味のある値でクエリ結果を装飾できます。例えば、URL やドキュメントのコンテンツなどです。 + **ベクトルフィールド**には、埋め込みとも呼ばれる数値のベクトルが含まれます。ベクトルフィールドは、指定されたアルゴリズムと距離メトリクスを使用した固定サイズのベクトルの K 最近傍検索 (KNN) をサポートします。HASH インデックスの場合、フィールドにはバイナリ形式 (*リトルエンディアン IEEE 754*) でエンコードされたベクトル全体が含まれている必要があります。JSON キーの場合、パスは数字が入力されている正しいサイズの配列を参照する必要があります。なお、JSON 配列をベクトルフィールドとして使用すると、JSON キー内の配列の内部表現が、選択したアルゴリズムに必要な形式に変換され、メモリ消費量と精度が削減されます。JSON コマンドを使用した後続の読み取りオペレーションでは、精度の値が小さくなります。 ## ベクトルインデックスアルゴリズム 2 つのベクトルインデックスアルゴリズムが提供されています。 + **Flat** – Flat アルゴリズムは、インデックス内の各ベクトルの総当たり線形処理であり、距離計算の精度の範囲内で正確な答えを生成します。インデックスの線形処理のため、インデックスが大きい場合、このアルゴリズムの実行時間が非常に長くなる可能性があります。 + **HNSW (Hierarchical Navigable Small Worlds)** - HNSW アルゴリズムは、実行時間を大幅に短縮する代わりに、正しい答えの近似値を提供する代替手段です。このアルゴリズムは、`M`、`EF_CONSTRUCTION`、`EF_RUNTIME` の 3 つのパラメータによって制御されます。最初の 2 つのパラメータはインデックスの作成時に指定され、変更できません。`EF_RUNTIME` パラメータにはインデックスの作成時に指定されるデフォルト値が含まれていますが、その後の個々のクエリオペレーションで上書きできます。これらの 3 つのパラメータは相互に影響し合って、取り込みおよびクエリオペレーション中のメモリと CPU 消費のバランスを取るだけでなく、正確な KNN 検索の近似値の質 (再現率と呼ばれます) を制御します。 両方のベクトル検索アルゴリズム (Flat および HNSW) は、オプションの `INITIAL_CAP` パラメータをサポートしています。このパラメータを指定すると、インデックス用にメモリが事前に割り当てられるため、メモリ管理のオーバーヘッドが削減され、ベクトルの取り込み速度が向上します。 HNSW などのベクトル検索アルゴリズムは、以前に挿入されたベクトルの削除または上書きを効率的に処理できない場合があります。これらのオペレーションを使用すると、インデックスメモリが過剰に消費されたり、再現の質が低下したりする可能性があります。インデックスの再作成は、最適なメモリ使用量および/または再現を復元するための 1 つの方法です。 ## ベクトル検索のクエリ式 [FT.SEARCH](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.search.html) および [FT.AGGREGATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.aggregate.html) コマンドにはクエリ式が必要です。この式は、1 つ以上の演算子で構成される単一の文字列パラメータです。各演算子はインデックス内の 1 つのフィールドを使用して、インデックス内のキーのサブセットを識別します。ブール結合子や括弧を使用して複数の演算子を結合し、収集されたキーのセット (または結果セット) をさらに拡張または制限できます。 ### ワイルドカード ワイルドカード演算子であるアスタリスク (「\$1」) は、インデックス内のすべてのキーと一致します。 ### 数値範囲 数値範囲演算子の構文は次のとおりです: ``` ::= '@' ':' '[' ']' ::= | '(' ::= | | | 'Inf' | '-Inf' | '+Inf' ``` は、`NUMERIC` の型の宣言されたフィールドである必要があります。デフォルトでは、境界は包括的ですが、先頭の開き括弧 [「(」] を使用して境界を排他的にすることができます。範囲検索は、`Inf`、`+Inf`、または `-Inf` を使用して単一のリレーショナル比較 (<、<=、>、>=) に変換できます。指定された数値形式 (整数、固定小数点、浮動小数点、無限大) にかかわらず、数値は比較を実行するために 64 ビットの浮動小数点に変換され、それに応じて精度が低下します。 **Example 例** ``` @numeric-field:[0 10] // 0 <= <= 10 @numeric-field:[(0 10] // 0 < <= 10 @numeric-field:[0 (10] // 0 <= < 10 @numeric-field:[(0 (10] // 0 < < 10 @numeric-field:[1.5 (Inf] // 1.5 <= value ``` ### タグ比較 タグ比較演算子の構文は次のとおりです: ``` ::= '@' ':' '{' [ '|' ]* '}' ``` 演算子のタグのいずれかがレコードのタグフィールドのタグのいずれかに一致する場合、そのレコードは結果セットに含まれます。`` によって設計されるフィールドは、型 `TAG` で宣言されたインデックスのフィールドである必要があります。タグ比較の例は次のとおりです: ``` @tag-field:{ atag } @tag-field: { tag1 | tag2 } ``` ### ブール値の組み合わせ 数値演算子またはタグ演算子の結果セットは、次のブール論理を使用して組み合わせることができます: and/or。括弧を使用すると、演算子をグループ化したり、評価順序を変更したりできます。ブール論理演算子の構文は次のとおりです: ``` ::= | '|' | '(' ')' ::= | ::= | | '*' ``` 語句に結合された複数の用語は「and」で結合されます。パイプ (「\$1」) で結合された複数の語句は「or」で結合されます。 ### ベクトル検索 ベクトルインデックスは、最も近い近隣と範囲の 2 つの異なる検索方法をサポートしています。最も近い近隣検索では、指定された (参照) ベクトルに最も近いインデックス内のベクトルの数 K が検索されます。これは、「K」に最も近い近隣の KNN と呼ぶものです。KNN 検索の構文は次のとおりです。 ``` ::= '=>[KNN' '@' '$' ']' ::= [ 'EF_RUNTIME' ] [ 'AS' ] ``` ベクトル KNN 検索は、`` (上記で定義した演算子の任意の組み合わせ: ワイルドカード、範囲検索、タグ検索、および/またはそれらのブール値の組み合わせ) を満たすベクトルにのみ適用されます。 + `` は、返される最近傍ベクトルの数を指定する整数です。 + `` は、型 `VECTOR` の宣言されたフィールドを指定する必要があります。 + `` フィールドは、`FT.SEARCH` または `FT.AGGREGATE` コマンドの `PARAM` テーブルのエントリの 1 つを指定します。このパラメータは、距離計算の参照ベクトル値です。ベクトルの値は、*リトルエンディアン IEEE 754* バイナリ形式の `PARAM` の値にエンコードされます (HASH ベクトルフィールドの場合と同じようにエンコードされます)。 + 型が HNSW であるベクトルインデックスの場合、オプションの `EF_RUNTIME` 句を使用して、インデックスの作成時に設定された `EF_RUNTIME` パラメータのデフォルト値を上書きできます。 + オプションの `` は、参照ベクトルと見つかったキーの間の計算された距離を含む結果セットのフィールド名を提供します。 範囲検索は、参照ベクトルから指定された距離 (半径) 内のすべてのベクトルを検索します。範囲検索の構文は次のとおりです。 ``` ::= ‘@’ ‘:’ ‘[’ ‘VECTOR_RANGE’ ( | ‘$’ ) $ ‘]’ [ ‘=’ ‘>’ ‘{’ ‘}’ ] ::= | , ::= [ ‘$yield_distance_as’ ‘:’ ] [ ‘$epsilon’ ‘:’ ] ``` コードの説明は以下のとおりです。 + `` は、検索するベクトルフィールドの名前です。 + ` or $` は、検索の距離制限の数値です。 + `$ ` は、参照ベクトルを含むパラメータの名前です。ベクトルの値は、リトルエンディアン IEEE 754 バイナリ形式の PARAM の値にエンコードされます (HASH ベクトルフィールドの場合と同じようにエンコードされます)。 + オプションの `` は、参照ベクトルと見つかったキーの間の計算された距離を含む結果セットのフィールド名を提供します。 + オプションの ` ` は検索オペレーションの境界を制御し、距離 ` * (1.0 + ) ` 内のベクトルは候補結果を探して横断されます。デフォルトは .01 です。 ## INFO コマンド ベクトル検索は、統計とカウンターのいくつかの追加セクションで Valkey および Redis OSS [INFO](https://valkey.io/commands/info/) コマンドを強化します。セクション `SEARCH` を取得するリクエストは、次のすべてのセクションを取得します: ### `search_memory` セクション | 名前 | 説明 | | --- | --- | | search\$1used\$1memory\$1bytes | すべての検索データ構造で消費されるメモリのバイト数 | | search\$1used\$1memory\$1human | 上記の人間が読めるバージョン | ### `search_index_stats` セクション | 名前 | 説明 | | --- | --- | | search\$1number\$1of\$1indexes | 作成されたインデックスの数 | | search\$1num\$1fulltext\$1indexes | すべてのインデックス内の非ベクトルフィールドの数 | | search\$1num\$1vector\$1indexes | すべてのインデックス内のベクトルフィールドの数 | | search\$1num\$1hash\$1indexes | HASH 型キーのインデックスの数 | | search\$1num\$1json\$1indexes | JSON 型キーのインデックスの数 | | search\$1total\$1indexed\$1keys | すべてのインデックス内のキーの総数 | | search\$1total\$1indexed\$1vectors | すべてのインデックス内のベクトルの総数 | | search\$1total\$1indexed\$1hash\$1keys | すべてのインデックス内の型が HASH であるキーの総数 | | search\$1total\$1indexed\$1json\$1keys | すべてのインデックス内の型が JSON であるキーの総数 | | search\$1total\$1index\$1size | すべてのインデックスによって使用されるバイト数 | | search\$1total\$1fulltext\$1index\$1size | 非ベクトルインデックス構造によって使用されるバイト数 | | search\$1total\$1vector\$1index\$1size | ベクトルインデックス構造によって使用されるバイト数 | | search\$1max\$1index\$1lag\$1ms | 最後の取り込みバッチ更新時の取り込みの遅延 | ### `search_ingestion` セクション | 名前 | 説明 | | --- | --- | | search\$1background\$1indexing\$1status | 取り込みのステータス。NO\$1ACTIVITY はアイドル状態であることを意味します。他の値は、取り込み中のキーがあることを示します。 | | search\$1ingestion\$1paused | 再起動中を除き、これは常に「no」である必要があります。 | ### `search_backfill` セクション **注記** このセクションに記載されているフィールドの一部は、操作しているときにバックフィルが進行中の場合にのみ表示されます。 | 名前 | 説明 | | --- | --- | | search\$1num\$1active\$1backfills | 現在のバックフィルアクティビティの数 | | search\$1backfills\$1paused | メモリ不足の場合を除いて、これは常に「no」である必要があります。 | | search\$1current\$1backfill\$1progress\$1percentage | 現在のバックフィルの完了率 (0～100) | ### `search_query` セクション | 名前 | 説明 | | --- | --- | | search\$1num\$1active\$1queries | 現在進行中の FT.SEARCH および FT.AGGREGATE コマンドの数 | ## ベクトル検索のセキュリティ コマンドアクセスとデータアクセスの両方のための [ACL (アクセスコントロールリスト)](https://valkey.io/topics/acl/) セキュリティメカニズムは、検索機能を制御するために拡張されています。個々の検索コマンドの ACL コントロールは完全にサポートされています。新しい ACL カテゴリ `@search` が提供され、既存のカテゴリの多く (`@fast`、`@read`、`@write` など) が新しいコマンドを含むように更新されます。検索コマンドはキーデータを変更しません。これは、書き込みアクセス用の既存の ACL 機構が保持されることを意味します。HASH および JSON オペレーションのアクセスルールは、インデックスが存在することで変更されることはありません。これらのコマンドには、通常のキーレベルのアクセスコントロールが引き続き適用されます。 また、インデックスを使用した検索コマンドでは、ACL を通じてアクセスが制御されます。アクセスチェックは、キーごとのレベルではなく、インデックス全体のレベルで実行されます。これは、そのインデックスのキースペースプレフィックスリストに含まれているすべての可能なキーにアクセスするための許可がユーザーに付与されている場合にのみ、インデックスに対するアクセスがユーザーに付与されることを意味します。つまり、インデックスの実際の内容はアクセスを制御しません。むしろ、これは、セキュリティチェックのために使用されるプレフィックスリストによって定義されるインデックスの理論的な内容です。キーに対する読み取りおよび/または書き込みアクセスがユーザーに付与されているにもかかわらず、そのキーを含むインデックスにアクセスできない状況が容易に発生する可能性があります。インデックスの作成または使用にはキースペースに対する読み取りアクセスのみが必要であり、書き込みアクセスの有無は考慮されないことに留意してください。 MemoryDB での ACL の使用の詳細については、「[アクセスコントロールリスト (ACL) によるユーザー認証](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)」を参照してください。 # ユースケース ベクトル検索のユースケースを次に示します。 ## 検索拡張生成 (RAG) 検索拡張生成 (RAG) は、ベクトル検索を活用して、大規模なデータコーパスから関連するパッセージを取得し、大規模言語モデル (LLM) を拡張します。具体的には、エンコーダーは入力コンテキストと検索クエリをベクトルに埋め込み、近似最近傍検索を使用して意味的に類似したパッセージを見つけます。これらの取得されたパッセージは元のコンテキストと連結され、LLM に追加の関連情報を提供し、より正確な応答をユーザーに返します。 ![\[検索拡張生成フローの図\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/RAG.png) ## 耐久性のあるセマンティックキャッシュ セマンティックキャッシュは、FM の以前の結果を保存して計算コストを削減するプロセスです。セマンティックキャッシュは、過去の推論の以前の結果を再計算するのではなく、再利用することにより、FM を通じた推論中に必要な計算量を削減します。MemoryDB は、耐久性のあるセマンティックキャッシュを可能にし、過去の推論のデータ損失を回避します。これにより、生成 AI アプリケーションは、不要な LLM 推論を回避してコストを削減しながら、以前の意味的に類似した質問からの回答を 1 桁ミリ秒以内に応答できます。 ![\[基盤モデルのプロセスを示すワークフロー図。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/FM.png) + **セマンティック検索のヒット** – お客様のクエリが以前の質問に対する定義された類似性スコアに基づいて意味的に類似している場合、FM バッファメモリ (MemoryDB) は、ステップ 4 で以前の質問に対する回答を返し、ステップ 3 を通じて FM を呼び出しません。これにより、基盤モデル (FM) のレイテンシーと発生するコストが回避することができ、より高速なエクスペリエンスがお客様に提供されます。 + **セマンティック検索ミス** – お客様のクエリが、以前のクエリに対する、定義された類似性スコアに基づいて意味的に類似していない場合、お客様は、ステップ 3a でお客様に応答を提供するように FM を呼び出します。FM から生成された応答は、意味的に類似した質問に対する FM のコストを最小限に抑えるために、将来のクエリのためにベクトルとして MemoryDB に保存されます (ステップ 3b)。このフローでは、意味的に類似した質問が元のクエリに含まれていないため、ステップ 4 は呼び出されません。 ## 不正検出 異常検出の一種である不正検出は、純新規トランザクションのベクトル表現を比較しながら、有効なトランザクションをベクトルとして表現します。不正は、これらの純新規トランザクションが、有効なトランザクションデータを表すベクトルとの類似性が低い場合に検出されます。これにより、考えられるあらゆる不正行為事例の予測を試みるのではなく、通常の動作をモデル化することで不正を検出できます。MemoryDB を使用すると、組織は、高スループット時に、誤検知を最小限に抑えながら、1 桁ミリ秒のレイテンシーでこれを実行できます。 ![\[不正検出プロセスを示すワークフロー図。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/fraud-detection.png) ## その他のユースケース + **レコメンデーションエンジン**は、項目をベクトルとして表現することで、類似した製品やコンテンツをユーザーのために見つけることができます。ベクトルは、属性とパターンを分析することによって作成されます。ユーザーのパターンと属性に基づいて、ユーザーに合わせて既に肯定的に評価されている最も類似したベクトルを見つけることで、これまでに表示されていない新しい項目をユーザーに推奨できます。 + **文書検索エンジン**は、数値の密なベクトルとしてテキスト文書を表現し、意味論的意味を捉えます。検索時に、エンジンは検索クエリをベクトルに変換し、近似最近傍検索を使用して、クエリに対して最も類似したベクトルを持つドキュメントを検索します。このベクトル類似性アプローチにより、単にキーワードを照合するのではなく、意味に基づいてドキュメントを照合できます。 # ベクター検索の機能と制限 ## ベクトル検索が利用可能なリージョン ベクトル検索が有効な MemoryDB 設定は、R6g, R7g、T4g ノードタイプでサポートされており、MemoryDB が利用可能なすべての AWS リージョンで使用できます。 既存のクラスターは、検索を有効にするように変更することはできません。ただし、検索が無効なクラスターのスナップショットから検索対応クラスターを作成できます。 ## パラメトリック制限 次の表は、プレビューにおけるさまざまなベクトル検索項目の制限を示しています。 | Item | 最大値 | | --- | --- | | ベクトルの次元の数 | 32768 | | 作成できるインデックスの数 | 10 | | インデックス内のフィールドの数 | 50 | | FT.SEARCH および FT.AGGREGATE TIMEOUT 句 (ミリ秒) | 10000 | | FT.AGGREGATE コマンドのパイプラインステージの数 | 32 | | FT.AGGREGATE LOAD 句のフィールドの数 | 1024 | | FT.AGGREGATE GROUPBY 句のフィールドの数 | 16 | | FT.AGGREGATE SORTBY 句のフィールドの数 | 16 | | FT.AGGREGATE PARAM 句のパラメータの数 | 32 | | HNSW M パラメータ | 512 | | HNSW EF\$1CONSTRUCTION パラメータ | 4096 | | HNSW EF\$1RUNTIME パラメータ | 4096 | ## [Scaling limits]（スケーリング履歴） 現在、MemoryDB のベクトル検索は単一のシャードに制限されており、水平方向のスケーリングはサポートされていません。ベクトル検索は、垂直スケーリングとレプリカスケーリングをサポートしています。 ## オペレーションの制限 **インデックスの永続化とバックフィル** ベクトル検索機能は、インデックスの定義とインデックスの内容を保持します。つまり、ノードの起動または再起動を引き起こすオペレーションリクエストまたはイベント中に、インデックス定義とコンテンツは最新のスナップショットから復元され、保留中のトランザクションはマルチ AZ トランザクションログから読み取られます。これを開始するには、ユーザーアクションは必要ありません。再構築は、データが復元されるとすぐにバックフィルオペレーションとして実行されます。これは、定義されたインデックスごとに [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) コマンドを自動的に実行するシステムと機能的に同等です。データが復元されると、アプリケーションのオペレーションのためにすぐにノードを使用できるようになりますが、これはインデックスバックフィルが完了する前である可能性が高いことに留意してください。これは、アプリケーションが再びバックフィルを認識できるようになることを意味します。例えば、バックフィルインデックスを使用した検索コマンドは拒否される可能性があります。バックフィルの詳細については、「[ベクトル検索の概要インデックスと Valkey および Redis OSS キースペース](vector-search-overview.md#vector-search-indexes-keyspaces)」を参照してください。 インデックスバックフィルの完了は、プライマリとレプリカの間で同期されません。この同期の欠如は予期せずアプリケーションにとって認識可能になる可能性があるため、検索オペレーションを開始する前に、アプリケーションでプライマリとすべてのレプリカでバックフィルが完了したことを検証することをお勧めします。 ## スナップショットのインポート/エクスポートとライブ移行 RDB ファイル内に検索インデックスが存在する場合、そのデータの互換性のある転送可能性が制限されます。MemoryDB ベクトル検索機能で定義されるベクトルインデックスの形式は、別の MemoryDB ベクトル対応クラスターでのみ理解されます。また、プレビュークラスターの RDB ファイルは、MemoryDB クラスターの GA バージョンによってインポートできます。これにより、RDB ファイルのロード時にインデックスコンテンツが再構築されます。 ただし、インデックスを含まない RDB ファイルについては、このような制限はありません。そのため、エクスポート前にインデックスを削除することで、プレビュークラスター内のデータを、非プレビュークラスターにエクスポートできます。 ## メモリ消費 メモリ消費量は、ベクトルの数、ディメンションの数、M 値、およびベクトルに関連付けられたメタデータやインスタンス内に保存された他のデータなどのベクトル以外のデータの量に基づいています。 必要な合計メモリは、実際のベクトルデータに必要なスペースとベクトルインデックスに必要なスペースの組み合わせです。ベクトルデータに必要なスペースは、最適なメモリ割り当てのために、HASH または JSON データ構造内にベクトルを保存するために必要な実際の容量と、最も近いメモリスラブへのオーバーヘッドを測定して計算されます。各ベクトルインデックスは、これらのデータ構造に保存されているベクトルデータへの参照を使用し、効率的なメモリ最適化を使用して、インデックス内のベクトルデータの重複コピーを削除します。 ベクトルの数は、データをベクトルとして表す方法によって異なります。例えば、1 つのドキュメントを複数のチャンクに表現することを選択できます。各チャンクはベクトルを表します。または、ドキュメント全体を単一のベクトルとして表現することもできます。 ベクトルのディメンションの数は、選択した埋め込みモデルによって異なります。例えば、[AWS Titan](https://aws.amazon.com/bedrock/titan/) 埋め込みモデルを使用する場合、ディメンションの数は 1536 になります。 M パラメータは、インデックス構築中に新しい要素ごとに作成された双方向リンクの数を表します。MemoryDB のデフォルト値は 16 ですが、これを上書きできます。高い M パラメータは、高いディメンションおよび/または高いリコール要件に対してより適しており、低い M パラメータは、低いディメンションおよび/または低いリコール要件に対してより適しています。M 値は、インデックスが大きくなるにつれてメモリの消費を増加させ、メモリの消費量が増加します。 コンソールエクスペリエンス内で、MemoryDB は、[クラスター設定でベクトル検索を有効にする] をチェックした後、ベクトルワークロードの特性に基づいて適切なインスタンスタイプを簡単に選択する方法を提供します。 ![\[AWS コンソールでのベクトル検索クラスターの設定。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png) **サンプルワークロード** あるお客様が、内部財務ドキュメントに基づいたセマンティック検索エンジンの構築を希望しています。現在、1536 ディメンションの Titan 埋め込みモデルを使用して、ドキュメントごとに 10 ベクトルに分割され、非ベクトルデータが含まれない 100 万件の財務ドキュメントが保管しています。お客様は、M パラメータとしてデフォルト 16 を使用することにしました。 + ベクトル: 100 万 \$1 10 チャンク = 1,000 万ベクトル + ディメンション: 1536 + 非ベクトルデータ (GB): 0 GB + M パラメータ: 16 このデータを使用して、お客様はコンソール内のベクトル計算ツールの使用ボタンをクリックし、パラメータに基づいて推奨されるインスタンスタイプを取得できます。 ![\[ベクトル計算ツールへの入力に基づいて、ベクトル計算ツールが推奨するノードタイプ。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/vector-calc1.png) ![\[値が入力されたベクトル計算ツール。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/vector-calc2.png) この例では、ベクトル計算ツールは、指定されたパラメータに基づいてベクトルを保存するために必要なメモリを保持できる最小の [MemoryDB r7g ノードタイプ](https://aws.amazon.com/memorydb/pricing/)を探します。これは近似値であり、インスタンスタイプをテストして要件に適合していることを確認する必要があることに注意してください。 上記の計算方法とサンプルワークロードのパラメータに基づくと、このベクトルデータの保存には 104.9 GB と単一のインデックスが必要です。この場合、使用可能なメモリが 105.81 GB であるため、`db.r7g.4xlarge` インスタンスタイプが推奨されます。次に小さいノードタイプは小さすぎて、ベクトルワークロードを保持できません。 各ベクトルインデックスは、保存されたベクトルデータへの参照を使用し、ベクトルインデックスにベクトルデータの追加のコピーを作成しないため、インデックスの消費スペースも比較的少なくなります。これは、複数のインデックスを作成する場合や、ベクトルデータの一部が削除され、HNSW グラフを再構築する場合にも非常に役立ちます。これにより、高品質のベクトル検索結果に最適なノード接続を作成できます。 ## バックフィル中のメモリ不足 Valkey および Redis OSS の書き込みオペレーションと同様に、インデックスバックフィルにはメモリ不足の制限があります。バックフィルの進行中にエンジンメモリがいっぱいになると、すべてのバックフィルが一時停止します。メモリが使用可能になると、バックフィルプロセスが再開されます。メモリ不足によりバックフィルが一時停止されたときに、削除してインデックスを作成することも可能です。 ## トランザクション コマンド `FT.CREATE`、`FT.DROPINDEX`、`FT.ALIASADD`、`FT.ALIASDEL`、および `FT.ALIASUPDATE` は、トランザクションコンテキストでは実行できません。すなわち、MULTI/EXEC ブロック内、または LUA もしくは FUNCTION スクリプト内では実行できません。 # ベクトル検索が有効になっているクラスターを作成する または を使用して AWS マネジメントコンソール、ベクトル検索が有効になっているクラスターを作成できます AWS Command Line Interface。アプローチによっては、ベクトル検索を有効にするための考慮事項を有効にする必要があります。 ## の使用 AWS マネジメントコンソール コンソール内でベクトル検索が有効なクラスターを作成するには、**クラスター**の設定でベクトル検索を有効にする必要があります。ベクトル検索は、MemoryDB バージョン 7.1 および単一シャード設定で使用できます。 ![\[[ベクトル検索を有効にする] オプションをチェックしてクラスター設定を表示すると、特定のバージョンと設定のサポートに関する情報が提供されます。\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/images/vs-2.png) でのベクトル検索の使用の詳細については AWS マネジメントコンソール、「」を参照してください[クラスターの作成 (コンソール)](getting-started.md#clusters.createclusters.viewdetails.cluster)。 ## の使用 AWS Command Line Interface ベクトル検索が有効な MemoryDB クラスターを作成するには、MemoryDB [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) コマンドを使用してイミュータブルなパラメータグループ `default.memorydb-redis7.search` を渡し、ベクトル検索機能を有効にします。 ``` aws memorydb create-cluster \ --cluster-name \ --node-type \ --engine redis \ --engine-version 7.1 \ --num-shards 1 \ --acl-name \ --parameter-group-name default.memorydb-redis7.search ``` 必要に応じて、次の例に示すように、ベクトル検索を有効にする新しいパラメータグループを作成することもできます。パラメータグループの詳細については、[こちら](parametergroups.management.md)を参照してください。 ``` aws memorydb create-parameter-group \ --parameter-group-name my-search-parameter-group \ --family memorydb_redis7 ``` 次に、新しく作成したパラメータグループで、パラメータ search-enabled を yes に更新します。 ``` aws memorydb update-parameter-group \ --parameter-group-name my-search-parameter-group \ --parameter-name-values "ParameterName=search-enabled,ParameterValue=yes" ``` デフォルトのパラメータグループの代わりにこのカスタムパラメータグループを使用して、MemoryDB クラスターでベクトル検索を有効にできるようになりました。 # ベクトル検索コマンド ベクトル検索でサポートされているコマンドのリストを次に示します。 **Topics** + [ # FT.CREATE ](vector-search-commands-ft.create.md) + [ # FT.SEARCH ](vector-search-commands-ft.search.md) + [ # FT.AGGREGATE ](vector-search-commands-ft.aggregate.md) + [ # FT.DROPINDEX ](vector-search-commands-ft.dropindex.md) + [ # FT.INFO ](vector-search-commands-ft.info.md) + [ # FT.\$1LIST ](vector-search-commands-ft.list.md) + [ # FT.ALIASADD ](vector-search-commands-ft.aliasadd.md) + [ # FT.ALIASDEL ](vector-search-commands-ft.aliasdel.md) + [ # FT.ALIASUPDATE ](vector-search-commands-ft.aliasupdate.md) + [ # FT.\$1ALIASLIST ](vector-search-commands-ft.aliaslist.md) + [ # FT.PROFILE ](vector-search-commands-ft.profile.md) + [ # FT.EXPLAIN ](vector-search-commands-ft.explain.md) + [ # FT.EXPLAINCLI ](vector-search-commands-ft.explain-cli.md) # FT.CREATE インデックスを作成し、そのインデックスのバックフィルを開始します。詳細については、「[ベクトル検索の概要](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html)」でインデックス構築の詳細をご覧ください。 **[Syntax]** (構文) ``` FT.CREATE ON HASH | JSON [PREFIX [...]] SCHEMA ( [AS ] NUMERIC | TAG [SEPARATOR ] [CASESENSITIVE] | TEXT | VECTOR [HNSW|FLAT] [ ]) )+ ``` **Schema** + フィールド識別子: + ハッシュキーの場合、フィールド識別子はフィールド名です。 + JSON キーの場合、フィールド識別子は JSON パスです。 詳細については、「[インデックスフィールドの型](vector-search-overview.md#vector-search-index-field-types)」を参照してください。 + フィールドの型: + タグ: 詳細については、「[タグ](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/)」を参照してください。 + NUMERIC: フィールドには数値が含まれます。 + TEXT: フィールドにはデータの BLOB が含まれます。 + VECTOR: ベクトル検索をサポートするベクトルフィールド。 + アルゴリズム – HNSW (Hierarchical Navigable Small World) または FLAT (総当たり) を使用できます。 + `attr_count` – アルゴリズム設定として渡される属性の数。これには名前と値の両方が含まれます。 + `{attribute_name} {attribute_value}` – インデックス設定を定義するアルゴリズム固有の key/value ペア。 FLAT アルゴリズムの場合、属性は次のとおりです: 必須: + DIM – ベクトルの次元の数。 + DISTANCE\$1METRIC – [L2 \$1 IP \$1 COSINE] のいずれかを使用できます。 + TYPE – ベクトルの型。サポートされている唯一の型は `FLOAT32` です。 オプション: + INITIAL\$1CAP – インデックスのメモリ割り当てサイズに影響するインデックスの初期ベクトル容量。 HNSW アルゴリズムの場合、属性は次のとおりです: 必須: + TYPE – ベクトルの型。サポートされている唯一の型は `FLOAT32` です。 + DIM – ベクトルの次元。正の整数として指定します。最大: 32,768 + DISTANCE\$1METRIC – [L2 \$1 IP \$1 COSINE] のいずれかを使用できます。 オプション: + INITIAL\$1CAP – インデックスのメモリ割り当てサイズに影響するインデックスの初期ベクトル容量。デフォルトは 1024 です。 + M – 各レイヤーのグラフ内の各ノードに許可される発信エッジの最大数。レイヤー 0 では、発信エッジの最大数は 2M です。デフォルトは 16、最大値は 512 です。 + EF\$1CONSTRUCTION – インデックスの構築中に検査されるベクトルの数を制御します。このパラメータの値を大きくすると、インデックスの作成時間が長くなりますが、再現率が向上します。デフォルト値は 200 です。最大値は 4096 です。 + EF\$1RUNTIME – クエリオペレーション中に検査されるベクトルの数を制御します。このパラメータの値を大きくすると、クエリ時間が長くなりますが、再現が改善されます。このパラメータの値はクエリごとに上書きできます。デフォルト値は 10 です。最大値は 4096 です。 **戻る** シンプルな文字列の OK メッセージまたはエラー応答を返します。 **例** **注記** 次の例では、データを Valkey または Redis OSS に送信する前に、そのデータの引用符の削除やエスケープの削除など、[valkey-cli](https://valkey.io/topics/cli/) にネイティブな引数を使用します。他のプログラミング言語クライアント (Python、Ruby、C\$1 など) を使用するには、それらの環境の文字列およびバイナリデータの処理規則に従います。サポートされているクライアントの詳細については、[「 で構築するツール AWS](https://aws.amazon.com/developer/tools/)」を参照してください。 **Example 1: インデックスを作成する** サイズ 2 のベクトルのインデックスを作成する ``` FT.CREATE hash_idx1 ON HASH PREFIX 1 hash: SCHEMA vec AS VEC VECTOR HNSW 6 DIM 2 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` HNSW アルゴリズムを使用して 6 次元の JSON インデックスを作成します: ``` FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR HNSW 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` **Example 例 2: 一部のデータを入力する** 次のコマンドは、redis-cli ターミナルプログラムの引数として実行できるようにフォーマットされています。プログラミング言語クライアント (Python、Ruby、C\$1 など) を使用するデベロッパーは、文字列とバイナリデータを処理するための環境の処理ルールに従う必要があります。 ハッシュデータと JSON データの作成: ``` HSET hash:0 vec "\x00\x00\x00\x00\x00\x00\x00\x00" HSET hash:1 vec "\x00\x00\x00\x00\x00\x00\x80\xbf" JSON.SET json:0 . '{"vec":[1,2,3,4,5,6]}' JSON.SET json:1 . '{"vec":[10,20,30,40,50,60]}' JSON.SET json:2 . '{"vec":[1.1,1.2,1.3,1.4,1.5,1.6]}' ``` 次の点に注意してください。 + ハッシュおよび JSON データのキーには、インデックス定義のプレフィックスが含まれています。 + ベクトルはインデックス定義の適切なパスにあります。 + ハッシュベクトルは 16 進データとして入力され、JSON データは数値として入力されます。 + ベクトルは適切な長さであり、2 次元のハッシュベクトルエントリには 2 つの浮動小数点相当の 16 進データが含まれており、6 次元の JSON ベクトルエントリには 6 つの数値が含まれています。 **Example 例 3: インデックスを削除して再作成する** ``` FT.DROPINDEX json_idx1 OK FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR FLAT 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` 新しい JSON インデックスでは、`HNSW` アルゴリズムの代わりに `FLAT` アルゴリズムが使用されることに留意してください。また、既存の JSON データのインデックスが再作成されることにも留意してください。 ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # FT.SEARCH インデックス内のキーを検索するために、指定されたクエリ式を使用します。見つかると、それらのキー内のインデックス付きフィールドのカウントおよび/または内容を返すことができます。詳細については、「[ベクトル検索クエリ式](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression)」を参照してください。 これらの例で使用するデータを作成するには、[FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) コマンドを参照してください。 **[Syntax]** (構文) ``` FT.SEARCH [RETURN ( [AS ])+] [TIMEOUT timeout] [PARAMS [ ]] [LIMIT ] [COUNT] ``` + RETURN: この句は、キーのどのフィールドが返されるかを指定します。各フィールドのオプションの AS 句は、結果内のフィールドの名前を上書きします。このインデックスのために宣言されているフィールドのみを指定できます。 + LIMIT: : この句は、オフセットおよびカウントの値を満たすキーのみが返されるというページネーション機能を提供します。この句を省略すると、デフォルトで「LIMIT 0 10」になります。すなわち、最大 10 個のキーのみが返されます。 + PARAMS: key-value ペアの数の 2 倍。Param の key/value ペアはクエリ式内から参照できます。詳細については、「[ベクトル検索クエリ式](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression)」を参照してください。 + COUNT: この句はキーの内容を返すことを抑制し、キーの数のみが返されます。これは「LIMIT 0 0」のエイリアスです。 **戻る** 配列またはエラー応答を返します。 + オペレーションが正常に完了すると、配列が返されます。最初の要素は、クエリに一致するキーの総数です。残りの要素は、キー名とフィールドリストのペアです。フィールドリストは、フィールド名と値のペアで構成される別の配列です。 + インデックスのバックフィルが進行中の場合、コマンドは直ちにエラー応答を返します。 + タイムアウトに達すると、コマンドはエラー応答を返します。 **例: 検索を実行する** **注記** 次の例では、データを Valkey または Redis OSS に送信する前に、そのデータの引用符の削除やエスケープの削除など、[valkey-cli](https://valkey.io/topics/cli/) にネイティブな引数を使用します。他のプログラミング言語クライアント (Python、Ruby、C\$1 など) を使用するには、それらの環境の文字列およびバイナリデータの処理規則に従います。サポートされているクライアントの詳細については、[「 で構築するツール AWS](https://aws.amazon.com/developer/tools/)」を参照してください。 **ハッシュ検索** ``` FT.SEARCH hash_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "hash:0" 3) 1) "__VEC_score" 2) "0" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x00\x00" 4) "hash:1" 5) 1) "__VEC_score" 2) "1" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x80\xbf" ``` これにより、クエリベクトル (16 進数で入力) からの距離であるスコアによってソートされた 2 つの結果が生成されます。 **JSON 検索** ``` FT.SEARCH json_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" ``` これにより、スコア順に並べ替えられた最も近い 2 つの結果が生成されます。JSON ベクトル値は浮動小数点数に変換され、クエリベクトルは依然としてベクトルデータであることに留意してください。`KNN` パラメータが 2 であるため、結果は 2 つだけであることにも留意してください。値が大きいほど、より多くの結果が返されます: ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # FT.AGGREGATE FT.SEARCH コマンドのスーパーセット。クエリ式によって選択されたキーの実質的な追加処理を許可します。 **[Syntax]** (構文) ``` FT.AGGREGATE index query [LOAD * | [count field [field ...]]] [TIMEOUT timeout] [PARAMS count name value [name value ...]] [FILTER expression] [LIMIT offset num] [GROUPBY count property [property ...] [REDUCE function count arg [arg ...] [AS name] [REDUCE function count arg [arg ...] [AS name] ...]] ...]] [SORTBY count [ property ASC | DESC [property ASC | DESC ...]] [MAX num]] [APPLY expression AS name] ``` + FILTER、LIMIT、GROUPBY、SORTBY、および APPLY 句は、任意の順序で複数回繰り返すことができ、自由に組み合わせることができます。これらは指定された順序で適用され、1 つの句の出力を次の句の入力に供給します。 + 上記の構文では、「プロパティ」は、このインデックスの [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) コマンドで宣言されたフィールド、または前の APPLY 句もしくは REDUCE 関数の出力のいずれかです。 + LOAD 句は、インデックスで宣言されたフィールドのロードに制限されます。「LOAD \$1」は、インデックスで宣言されたすべてのフィールドをロードします。 + 次のリデューサー関数がサポートされています: COUNT、COUNT\$1DISTINCTISH、SUM、MIN、MAX、AVG、STDDEV、QUANTILE、TOLIST、FIRST\$1VALUE、および RANDOM\$1SAMPLE。詳細については、「[集計](https://redis.io/docs/interact/search-and-query/search/aggregations/)」を参照してください。 + LIMIT : で始まり まで続くレコードを保持し、他のすべてのレコードは破棄されます。 + PARAMS: key-value ペアの数の 2 倍。Param の key/value ペアはクエリ式内から参照できます。 **戻る** 配列またはエラー応答を返します。 + オペレーションが正常に完了すると、配列が返されます。最初の要素は特定の意味を持たない整数です (無視する必要があります)。残りの要素は、最後のステージによって出力された結果です。各要素はフィールド名と値のペアの配列です。 + インデックスのバックフィルが進行中の場合、コマンドは直ちにエラー応答を返します。 + タイムアウトに達すると、コマンドはエラー応答を返します。 # FT.DROPINDEX インデックスをドロップします。インデックス定義と関連付けられたコンテンツが削除されます。キーは影響を受けません。 **[Syntax]** (構文) ``` FT.DROPINDEX ``` **戻る** シンプルな文字列の OK メッセージまたはエラー応答を返します。 # FT.INFO **[Syntax]** (構文) ``` FT.INFO ``` FT.INFO ページからの出力は、次の表に示す key-value ペアの配列です: | Key | 値のタイプ | 説明 | | --- | --- | --- | | index\$1name | string | インデックスの名前 | | creation\$1timestamp | integer | 作成時の Unix スタイルのタイムスタンプ | | key\$1type | string | HASH または JSON | | key\$1prefixes | 文字列の配列 | このインデックスのキープレフィックス | | fields | フィールド情報の配列 | このインデックスのフィールド | | space\$1usage | integer | このインデックスによって使用されるメモリバイト | | fullext\$1space\$1usage | integer | 非ベクトルフィールドによって使用されるメモリバイト | | vector\$1space\$1usage | integer | ベクトルフィールドによって使用されるメモリバイト | | num\$1docs | integer | 現在インデックスに含まれているキーの数 | | num\$1indexed\$1vectors | integer | 現在インデックスに含まれているベクトルの数 | | current\$1lag | integer | 最近の取り込み遅延 (ミリ秒) | | backfill\$1status | string | 次のいずれか: Completed、InProgres、Paused、または Failed | 次の表では、各フィールドの情報について説明します: | Key | 値のタイプ | 説明 | | --- | --- | --- | | 識別子 | string | フィールドの名前 | | field\$1name | string | ハッシュメンバー名または JSON パス | | 型 | string | 次のいずれか: Numeric、Tag、Text、または Vector | | option | string | ignore | フィールドの型が Vector である場合、アルゴリズムに応じて追加情報が存在します。 HNSW アルゴリズムの場合: | Key | 値のタイプ | 説明 | | --- | --- | --- | | アルゴリズム | string | HNSW | | data\$1type | string | FLOAT32 | | distance\$1metric | string | 次のいずれか: L2、IP、または Cosine | | initial\$1capacity | integer | ベクトルフィールドインデックスの初期サイズ | | current\$1capacity | integer | ベクトルフィールドインデックスの現在のサイズ | | maximum\$1edges | integer | 作成時の M パラメータ | | ef\$1construction | integer | 作成時の EF\$1CONSTRUCTION パラメータ | | ef\$1runtime | integer | 作成時の EF\$1RUNTIME パラメータ | FLAT アルゴリズムの場合: | Key | 値のタイプ | 説明 | | --- | --- | --- | | アルゴリズム | string | FLAT | | data\$1type | string | FLOAT32 | | distance\$1metric | string | 次のいずれか: L2、IP、または Cosine | | initial\$1capacity | integer | ベクトルフィールドインデックスの初期サイズ | | current\$1capacity | integer | ベクトルフィールドインデックスの現在のサイズ | # FT.\$1LIST すべてのインデックスを一覧表示します。 **[Syntax]** (構文) ``` FT._LIST ``` **戻る** インデックス名の配列を返します # FT.ALIASADD インデックスのエイリアスを追加します。新しいエイリアスは、インデックス名が必要なあらゆる場所で使用できます。 **[Syntax]** (構文) ``` FT.ALIASADD ``` **戻る** シンプルな文字列の OK メッセージまたはエラー応答を返します。 # FT.ALIASDEL インデックスの既存のエイリアスを削除します。 **[Syntax]** (構文) ``` FT.ALIASDEL ``` **戻る** シンプルな文字列の OK メッセージまたはエラー応答を返します。 # FT.ALIASUPDATE 別の物理インデックスをポイントするように既存のエイリアスを更新します。このコマンドは、エイリアスへの今後の参照にのみ影響します。現在進行中のオペレーション (FT.SEARCH、FT.AGGREGATE) は、このコマンドの影響を受けません。 **[Syntax]** (構文) ``` FT.ALIASUPDATE ``` **戻る** シンプルな文字列の OK メッセージまたはエラー応答を返します。 # FT.\$1ALIASLIST インデックスのエイリアスを一覧表示します。 **[Syntax]** (構文) ``` FT._ALIASLIST ``` **戻る** 現在のエイリアスの数のサイズの配列を返します。配列の各要素は、エイリアスとインデックスのペアです。 # FT.PROFILE クエリを実行し、そのクエリに関するプロファイル情報を返します。 **[Syntax]** (構文) ``` FT.PROFILE SEARCH | AGGREGATE [LIMITED] QUERY ``` **戻る** 2 つの要素の配列。1 つ目の要素は、プロファイリングされた `FT.SEARCH` または `FT.AGGREGATE` コマンドの結果です。2 つ目の要素は、パフォーマンスおよびプロファイリング情報の配列です。 # FT.EXPLAIN クエリを解析し、そのクエリがどのように解析されたかに関する情報を返します。 **[Syntax]** (構文) ``` FT.EXPLAIN ``` **戻る** 解析結果を含む文字列。 # FT.EXPLAINCLI 結果が、redis-cli でより便利な別の形式で表示されることを除いて、FT.EXPLAIN コマンドと同じです。 **[Syntax]** (構文) ``` FT.EXPLAINCLI ``` **戻る** 解析結果を含む文字列。