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

適切な設定の選択

コンソールエクスペリエンス内で、ElastiCache は検索ワークロードのメモリと cpu 要件に基づいて適切なインスタンスタイプを簡単に選択する方法を提供します。

メモリ消費

ベクトルフィールドのメモリ消費量は、ベクトルの数、ディメンションの数、M 値、およびベクトルに関連付けられたメタデータやインスタンス内に保存されている他のデータなど、ベクトル以外のデータの量に基づきます。必要な合計メモリは、実際のベクトルデータに必要なスペースとベクトルインデックスに必要なスペースの組み合わせです。ベクトルデータに必要なスペースは、最適なメモリ割り当てのために、HASH または JSON のデータ構造内にベクトルを保存するために必要な実際の容量と、最も近いメモリスラブへのオーバーヘッドを測定して計算されます。各ベクトルインデックスは、これらのデータ構造に保存されているベクトルデータへの参照と、インデックス内のベクトルの追加コピーを使用します。インデックスによるこの追加のスペースの消費量を計画することをお勧めします。

ベクトルの数は、データをベクトルとして表す方法によって異なります。例えば、1 つのドキュメントを複数のチャンクに表現することを選択できます。各チャンクはベクトルを表します。または、ドキュメント全体を単一のベクトルとして表現することもできます。ベクトルのディメンションの数は、選択した埋め込みモデルによって異なります。たとえば、 AWS Titan 埋め込みモデルを使用する場合、ディメンションの数は 1536 になります。インスタンスタイプをテストして要件に適合していることを確認する必要があることに注意してください。

ワークロードのスケーリング

検索では、水平、垂直、レプリカの 3 つのスケーリング方法がすべてサポートされています。容量をスケーリングする場合、ベクトル検索は通常の Valkey と同じように動作します。つまり、個々のノードのメモリを増やす (垂直スケーリング) か、ノードの数を増やす (水平スケーリング) と、全体の容量が増加します。クラスターモードでは、FT.CREATE コマンドをクラスターの任意のプライマリノードに送信でき、システムは新しいインデックス定義をすべてのクラスターメンバーに自動的に配布します。

ただし、パフォーマンスの観点から見ると、検索の動作は通常の Valkey とは大きく異なります。検索のマルチスレッド実装は、追加の CPUsがクエリスループットと取り込みスループットの両方を直線的に増加させることを意味します。水平スケーリングでは、取り込みスループットは線形に増加しますが、クエリスループットは低下する場合があります。追加のクエリスループットが必要な場合は、レプリカまたは追加の CPU をスケールスルーする必要があります。