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

適切な設定の選択

ElastiCache には、コンソールエクスペリエンス内で、ベクトルワークロードのメモリと CPU の要件に基づいて適切なインスタンスタイプを選択する簡単な方法が用意されています。

メモリ消費

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

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

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

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

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