配置オプションを検討する

配置タイプ

Atlas Vector Search クエリをテストするには、共有クラスターまたは専用クラスター、またはローカル Atlas 配置を配置できます。

ノード アーキテクチャ

この配置モデルでは、検索mongotプロセスが Atlas クラスター内の各ノードでmongodと並行して実行されます。 mongodプロセスは同じノード上のmongotにクエリをルーティングし、同じリソースを共有します。

デフォルトでは、Atlas は最初の Atlas Vector Search インデックスを作成するときに、 mongodプロセスを実行するのと同じノードで検索mongotプロセスを有効にします。 mongotプロセスは、 mongotプロセスについて で説明されているアクションを実行します。

制限

データベースmongodと検索mongotプロセス間でリソース競合が発生する可能性があります。 これは、インデックスのパフォーマンスとクエリのレイテンシに悪影響を与える可能性があります。 この配置モデルは、環境のテストとプロトタイプ作成のみに推奨します。 本番環境に対応できるアプリケーションと関連する検索ワークロードの場合は、専用の検索ノードに移行することをお勧めします。

配置タイプ

本番環境に対応できるアプリケーションには専有クラスターが必要です。

Cluster Tiers

専有クラスターにはM10以上の階層が含まれます。 M10階層とM20 階層は開発環境と本番環境に適しています。ただし、上位階層では大規模なデータセットと本番環境のワークロードを処理できます。 検索ワークロード用に専用の検索ノードも配置することをお勧めします。 これにより、検索配置を個別かつ適切に増やすことができます。

クラウドプロバイダーとリージョン

選択したクラウド プロバイダーとリージョンは、クラスターで使用できる構成オプションと検索層、およびクラスターの実行コストに影響します。

すべてのクラスター階層は、特定の リージョンを 除き、サポートされているすべての クラウドプロバイダー リージョン Amazon Web Servicesで利用できます。Amazon Web Servicesでホストされているクラスターの場合は、配置に使用できるクラウドプロバイダーを選択する必要があります。

ノード アーキテクチャ

この配置モデルでは、 mongotプロセスは、 mongodプロセスが実行されるクラスター ノードとは別の検索ノードで実行されます。 Atlas は、各クラスターまたはクラスター上の各シャードに検索ノードを配置します。

たとえば、3 つのシャードを持つクラスターに 2 つの検索ノードを配置すると、Atlas は 6 つの検索ノード（シャードあたり 2 つ）を配置します。 また、検索ノードの数と、各検索ノードにプロビジョニングされるリソースの量を構成することもできます。

別個の検索ノードを配置すると、Atlas はインデックス作成用に各mongotにmongodを自動的に割り当てます。 mongotはmongodと通信して、保存しているインデックスの変更をリッスンし、同期します。 Atlas Vector Search は、 mongodとmongotプロセスの両方が同じノードで実行される場合と同様に、クエリをインデックスして処理します。 詳細については、「ベクトル検索のフィールドにインデックスを作成する方法 」と「ベクトル検索クエリを実行する方法 」を参照してください。 検索ノードを個別に配置する方法の詳細については、「ワークロード分離用の検索ノード 」を参照してください。

検索ノードに移行すると、Atlas は検索ノードを配置しますが、検索ノード上のクラスター上のすべてのインデックスが正常に構築されるまで、ノードに対するクエリを処理しません。 Atlas が新しいノードにインデックスをビルドする間も、クラスター ノードのインデックスを使用してクエリを処理し続けます。 Atlas は、検索ノードにインデックスを正常にビルドし、クラスター ノード上のインデックスを削除した後にのみ、検索ノードからクエリの処理を開始します。

クラスター上のすべての検索ノードを削除すると、検索クエリー結果の処理が中断されます。 詳細については、「クラスターの変更」を参照してください。 Atlas クラスターを削除すると、Atlas は一時停止し、関連付けられているすべての Atlas Vector Search 配置（ mongotプロセス）を削除します。

メリット

この配置モデルには、次のメリットがあります。

• リソースを効率的に利用しながら、検索ワークロード用にリソースの高可用性を確保します。

• 検索配置のサイズは、データベース配置とは独立してスケーリングします。

• Atlas Vector Search クエリを同時に自動的に処理することで、特に大規模なデータセットでの応答時間が向上します。 詳細については、「セグメント間での並列クエリ実行」を参照してください。

クラスターのサイズ設定とスケーリング

Atlas Vector Searchはインデックス全体をメモリに保持するので、Atlas Vector SearchインデックスとJVMに十分なメモリがあることを確認する必要があります。 各インデックスは、インデックスが作成されるベクトルと追加のメタデータの組み合わせです。 インデックスのサイズは、主にインデックスを付けるベクトルのサイズによって決まります。メタデータスペースは通常、比較的わずかなものです。

単一のベクトルの次の要件を考慮してください。

BinData vector サブタイプ int8 量子化ベクトル。詳細については、「量子化されたベクトルの取り込み」を参照してください。

必要なスペースは、インデックスを作成するベクトルの数とベクトル次元に応じて直線的に増加します。 また、 Search Index Sizeメトリクスを使用して、検索ノードに必要なスペースとメモリの量を判断することもできます。

専用の検索ノードを配置する場合は、さまざまな検索階層から選択できます。 各検索階層には、デフォルトの RAM 容量、ストレージ容量、および CPU が設定されています。 そのため、データベース配置とは別個にクラスターのサイズを設定および拡張することができます。 検索配置を個別にスケーリングするには、いつでもクラスター構成に次の変更を加えることができます。

• クラスター上の検索ノードの数を調整します。

• 検索階層を変更して、ノードの CPU、RAM、ストレージを調整する。

ノードには、Atlas ベクトル検索インデックスの合計サイズより少なくとも 10% 大きいRAMがあることをお勧めします。また、使用可能な CPU が十分にあることを確認することをお勧めします。 クエリのレイテンシは、使用可能なCPUの数によって異なります。これは、クエリのパフォーマンスを加速する内部同時実行のレベルに大きな影響を与える可能性があります。

専用検索ノードへの移行

専用検索ノードを使用すると、クラスターとは別に検索配置のサイズとスケーリングの両方を行うことができます。 また、データベース プロセスと検索プロセスの両方を同じノードで実行するクラスターで発生する可能性のあるリソースの競合も排除されます。

専用検索ノードに移行するには、配置を次の変更で行います。

1. 配置で現在共有階層を使用している場合は、クラスターをより高い階層にアップグレードします。 専用検索ノードは、 M10以上のクラスター階層でのみサポートされます。 別のクラスター階層への移行の詳細については、「 Cluster Tierの変更 」を参照してください。

2. 専用検索ノードは、 Amazon Web Servicesリージョンのサブセット、およびサポートされているすべてのGoogle Cloud PlatformおよびAzureリージョンで利用できます。 検索ノードも利用できるリージョンに クラスターを配置する ようにします。 既存のクラスターが検索ノードを利用できないリージョンにある場合は、検索ノードが利用できるリージョンにクラスターを移行します。 詳しくは、「クラウドプロバイダーのリージョン 」を参照してください。

3. Search Nodes for workload isolationを有効にして、検索ノードを構成します。 詳しくは、「検索ノードを追加する 」を参照してください。