Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

ベクター検索の機能と制限

フォーカスモード
ベクター検索の機能と制限 - Amazon MemoryDB

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ベクトル検索が利用可能なリージョン

ベクトル検索が有効な MemoryDB 設定は、R6g, R7g、および T4g ノードタイプでサポートされており、MemoryDB が利用可能なすべての AWS リージョンで使用できます。

既存のクラスターは、検索を有効にするように変更することはできません。ただし、検索が無効なクラスターのスナップショットから検索対応クラスターを作成できます。

パラメトリック制限

次の表は、プレビューにおけるさまざまなベクトル検索項目の制限を示しています。

項目 最大値
ベクトルの次元の数 32768
作成できるインデックスの数 10
インデックス内のフィールドの数 50
FT.SEARCH および FT.AGGREGATE TIMEOUT句 (ミリ秒) 10000
FTAGGREGATE. コマンドのパイプラインステージの数 32
FT.AGGREGATE LOAD句のフィールド数 1024
FT.AGGREGATE GROUPBY句のフィールド数 16
FT.AGGREGATE SORTBY句のフィールド数 16
FT.AGGREGATE PARAM句のパラメータ数 32
HNSW M パラメータ 512
HNSW EF_CONSTRUCTION パラメータ 4096
HNSW EF_RUNTIME パラメータ 4096

[Scaling limits](スケーリング履歴)

現在、MemoryDB のベクトル検索は単一のシャードに制限されており、水平方向のスケーリングはサポートされていません。ベクトル検索は、垂直スケーリングとレプリカスケーリングをサポートしています。

オペレーションの制限

インデックスの永続化とバックフィル

ベクトル検索機能は、インデックスの定義とインデックスの内容を保持します。つまり、ノードの起動または再起動を引き起こすオペレーションリクエストまたはイベント中に、インデックス定義と内容が最新のスナップショットから復元され、保留中のトランザクションがジャーナルから再生されます。これを開始するには、ユーザーアクションは必要ありません。再構築は、データが復元されるとすぐにバックフィルオペレーションとして実行されます。これは、定義されたインデックスごとに FT.CREATE コマンドを自動的に実行するシステムと機能的に同等です。データが復元されると、アプリケーションのオペレーションのためにすぐにノードを使用できるようになりますが、これはインデックスバックフィルが完了する前である可能性が高いことに留意してください。これは、アプリケーションが再びバックフィルを認識できるようになることを意味します。例えば、バックフィルインデックスを使用した検索コマンドは拒否される可能性があります。バックフィルの詳細については、「ベクトル検索の概要」を参照してください。

インデックスバックフィルの完了は、プライマリとレプリカの間で同期されません。この同期の欠如は予期せずアプリケーションにとって認識可能になる可能性があるため、検索オペレーションを開始する前に、アプリケーションでプライマリとすべてのレプリカでバックフィルが完了したことを検証することをお勧めします。

スナップショットのインポート/エクスポートとライブ移行

RDB ファイル内に検索インデックスが存在すると、そのデータの互換性のあるトランスポータブル性が制限されます。MemoryDB ベクトル検索機能で定義されるベクトルインデックスの形式は、別の MemoryDB ベクトル対応クラスターでのみ理解されます。また、プレビュークラスターのRDBファイルは、MemoryDB クラスターの GA バージョンによってインポートできます。これにより、RDBファイルのロード時にインデックスコンテンツが再構築されます。

ただし、インデックスを含まないRDBファイルは、この方法では制限されません。そのため、エクスポート前にインデックスを削除することで、プレビュークラスター内のデータを、非プレビュークラスターにエクスポートできます。

メモリ消費

メモリ消費量は、ベクトルの数、ディメンションの数、M 値、およびベクトルに関連付けられたメタデータやインスタンス内に保存された他のデータなどのベクトル以外のデータの量に基づいています。

必要な合計メモリは、実際のベクトルデータに必要なスペースとベクトルインデックスに必要なスペースの組み合わせです。ベクトルデータに必要な領域は、ベクトルを HASHまたは JSON データ構造内に保存するために必要な実際の容量と、最適なメモリ割り当てのために最も近いメモリスラブへのオーバーヘッドを測定することによって計算されます。各ベクトルインデックスは、これらのデータ構造に保存されているベクトルデータへの参照を使用し、効率的なメモリ最適化を使用して、インデックス内のベクトルデータの重複コピーを削除します。

ベクトルの数は、データをベクトルとして表す方法によって異なります。例えば、1 つのドキュメントを複数のチャンクに表現することを選択できます。各チャンクはベクトルを表します。または、ドキュメント全体を単一のベクトルとして表現することもできます。

ベクトルのディメンションの数は、選択した埋め込みモデルによって異なります。例えば、AWS Titan 埋め込みモデルを使用する場合、ディメンションの数は 1536 になります。

M パラメータは、インデックス構築中に新しい要素ごとに作成された双方向リンクの数を表します。MemoryDB のデフォルト値は 16 ですが、これを上書きできます。高い M パラメータは、高次元のand/or high recall requirements while low M parameters work better for low dimensionality and/or低再現率要件に適しています。M 値は、インデックスが大きくなるにつれてメモリの消費を増加させ、メモリの消費量が増加します。

コンソールエクスペリエンス内で、MemoryDB は、[クラスター設定でベクトル検索を有効にする] をチェックした後、ベクトルワークロードの特性に基づいて適切なインスタンスタイプを簡単に選択する方法を提供します。

AWS コンソールでのベクトル検索クラスターの設定。

サンプルワークロード

あるお客様が、内部財務ドキュメントに基づいたセマンティック検索エンジンの構築を希望しています。現在、1536 ディメンションの Titan 埋め込みモデルを使用して、ドキュメントごとに 10 ベクトルに分割され、非ベクトルデータが含まれない 100 万件の財務ドキュメントが保管しています。お客様は、M パラメータとしてデフォルト 16 を使用することにしました。

  • ベクトル: 100 万 * 10 チャンク = 1,000 万ベクトル

  • ディメンション: 1536

  • 非ベクトルデータ (GB): 0 GB

  • M パラメータ: 16

このデータを使用して、お客様はコンソール内のベクトル計算ツールの使用ボタンをクリックし、パラメータに基づいて推奨されるインスタンスタイプを取得できます。

ベクトル計算ツールへの入力に基づいて、ベクトル計算ツールが推奨するノードタイプ。
値が入力されたベクトル計算ツール。

この例では、ベクトル計算ツールは、指定されたパラメータに基づいてベクトルを保存するために必要なメモリを保持できる最小の MemoryDB r7g ノードタイプを探します。これは近似値であり、インスタンスタイプをテストして要件に適合していることを確認する必要があることに注意してください。

上記の計算方法とサンプルワークロードのパラメータに基づくと、このベクトルデータの保存には 104.9 GB と単一のインデックスが必要です。この場合、使用可能なメモリが 105.81 GB であるため、db.r7g.4xlarge インスタンスタイプが推奨されます。次に小さいノードタイプは小さすぎて、ベクトルワークロードを保持できません。

各ベクトルインデックスは、保存されたベクトルデータへの参照を使用し、ベクトルインデックスにベクトルデータの追加のコピーを作成しないため、インデックスの消費スペースも比較的少なくなります。これは、複数のインデックスを作成する場合や、ベクトルデータの一部が削除され、HNSWグラフを再構築する場合にも非常に役立ちます。これにより、高品質のベクトル検索結果に最適なノード接続を作成できます。

バックフィル中のメモリ不足

Valkey および Redis のOSS書き込みオペレーションと同様に、インデックスのバックフィルには制限が適用されます out-of-memory。バックフィルの進行中にエンジンメモリがいっぱいになると、すべてのバックフィルが一時停止します。メモリが使用可能になると、バックフィルプロセスが再開されます。メモリ不足によりバックフィルが一時停止されたときに、削除してインデックスを作成することも可能です。

トランザクション

コマンド FT.CREATEFT.DROPINDEXFT.ALIASADDFT.ALIASDEL、および は、トランザクションコンテキストで実行できません。つまり、MULTI/EXEC ブロック内や、 LUA または FUNCTIONスクリプト内でFT.ALIASUPDATE実行することはできません。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.