配置オプションを検討する
項目一覧
本番前または本番環境のニーズに合わせて、さまざまな配置タイプ、クラウドプロバイダー、およびクラスター階層を使用して Atlas クラスターを構成できます。 これらの推奨事項を使用して、配置タイプ、クラウドプロバイダーとリージョン、およびベクトル検索を実行するためのクラスターと検索階層を選択します。
environment | 配置タイプ | クラスター階層 | クラウドプロバイダーのリージョン | ノード アーキテクチャ |
|---|---|---|---|---|
クエリのテスト | Shared or dedicated cluster Local deployment | M0, M2, M5, or higher tierN/A | All N/A | MongoDB プロセスと Search プロセスは同じノードで実行 |
アプリケーションのプロトタイプ作成 | 専用クラスター |
| すべて | MongoDB プロセスと Search プロセスは同じノードで実行 |
本番環境 | 個別の検索ノードを持つ専用クラスター |
| MongoDB プロセスと Search プロセスは異なるノードで実行 |
これらの配置モデルの詳細については、次のセクションを確認してください。
環境のテストとプロトタイプ作成
ベクトル検索クエリをテストし、アプリケーションのプロトタイプ作成には、次の構成が推奨されます。
配置タイプ
Atlas Vector Search クエリをテストするには、共有クラスターまたは専用クラスター、またはローカル Atlas 配置を配置できます。
Cluster Tiers
共有クラスターには、 M0 、 M2 、 M5 階層が含まれます。 これらの低コストのクラスタータイプは、Atlas Vector Search クエリをテストするために使用できます。 ただし、共有クラスターではリソース競合とクエリ レイテンシが発生する可能性があります。 共有クラスターでプロジェクトを開始した場合は、アプリケーションの本番環境が準備できたら、より高い階層にアップグレードすることをお勧めします。
専有クラスターにはM10以上の階層が含まれます。 M10階層とM20 階層はアプリケーションのプロトタイプ作成に適しています。アプリケーションが本番環境に準備が整ったら、大規模なデータセットを処理したり、ワークロードを分離するために専用の検索ノードを配置したりするために、上位階層にアップグレードできます。
クラウドプロバイダーとリージョン
選択したクラウドプロバイダーとリージョンは、クラスター階層で使用可能な構成オプションと クラスターのランニング コスト に影響します。
Atlas Vector Search クエリをローカルでテストしたい場合は、Atlas CLI を使用して、ローカル コンピューターでホストされている単一ノードのレプリカセットを配置できます。 開始するには、 Atlas Vector Search クイック スタートを完了し、ローカル配置の [] タブを選択します。
アプリケーションの本番環境が準備できたら、ライブ移行を使用してローカル Atlas の配置を本番環境に移行します。 ローカル配置は、ローカル マシンの CPU、メモリ、およびストレージ リソースによって制限されます。
ノード アーキテクチャ
この配置モデルでは、検索mongotプロセスが Atlas クラスター内の各ノードでmongodと並行して実行されます。 mongodプロセスは同じノード上のmongotにクエリをルーティングし、同じリソースを共有します。
デフォルトでは、Atlas は最初の Atlas Vector Search インデックスを作成するときに、 mongodプロセスを実行するのと同じノードで検索mongotプロセスを有効にします。 mongotプロセスは、 mongotプロセスについて で説明されているアクションを実行します。
制限
データベースmongodと検索mongotプロセス間でリソース競合が発生する可能性があります。 これは、インデックスのパフォーマンスとクエリのレイテンシに悪影響を与える可能性があります。 この配置モデルは、環境のテストとプロトタイプ作成のみに推奨します。 本番環境に対応できるアプリケーションと関連する検索ワークロードの場合は、専用の検索ノードに移行することをお勧めします。
本番環境
本番環境のアプリケーションには、次のクラスター構成が推奨されます。
配置タイプ
本番環境に対応できるアプリケーションには専有クラスターが必要です。
Cluster Tiers
専有クラスターにはM10以上の階層が含まれます。 M10階層とM20 階層は開発環境と本番環境に適しています。ただし、上位階層では大規模なデータセットと本番環境のワークロードを処理できます。 検索ワークロード用に専用の検索ノードも配置することをお勧めします。 これにより、検索配置を個別かつ適切に増やすことができます。
クラウドプロバイダーとリージョン
検索ノードは Google Cloud のすべてのリージョンで利用できますが、 AWSおよびAzureリージョンのサブセットでのみ利用できます。配置で検索ノードが利用できるクラウドプロバイダーとリージョンを選択する必要があります。
すべてのクラスター階層はサポートされているクラウドプロバイダー リージョンで利用できます。 選択したクラウドプロバイダーとリージョンは、クラスターで使用可能な構成オプションと検索階層、および クラスターのランニング コスト に影響します。
ノード アーキテクチャ
この配置モデルでは、 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 に十分なメモリがあることを確認する必要があります。各インデックスは、インデックスが作成されるベクトルと追加のメタデータの組み合わせです。インデックスのサイズは、主にインデックスを作成するベクトルのサイズによって決まります。メタデータ スペースは通常、比較的わずかなものです。
単一のベクトルの次の要件を考慮してください。
埋め込みモデル | ベクトル次元 | スペース要件 |
|---|---|---|
OpenAI | 1536 | 6kb |
Google | 768 | 3kb |
Cohere | 1024 | 1.07kb |
BinData
vector サブタイプint8 またはint1 の量子化ベクトル。詳細については、「 取り込み量子化ベクトル 」を参照してください。
必要なスペースは、インデックスを作成するベクトルの数とベクトル次元に応じて直線的に増加します。 また、 Search Index Sizeメトリクスを使用して、検索ノードに必要なスペースとメモリの量を判断することもできます。
取り込みに BinData または量子化ベクトルを使用すると、浮動小数ベクトルのmongod のストレージは約66 % 削減されます。mongot のRAMは、スカラーの場合は3.75 x だけ、バイナリの場合は24 x だけ減少します。これは、ベクトル値がそれぞれ4 x と24 x 減少するためですが、 Hierarchical Navigable Small Worlds グラフ自体をは縮小しません。リスコアリングに使用される完全忠実度ベクトルは、少数のメモリを使用するだけで、インデックスのようにキャッシュに保持する必要はありません。ただし、これらのベクトルはディスクに保存されます。したがって、それぞれスカラーとバイナリ量子化用に、ストレージとRAMの比率が約4 x/24 x に対応できる検索ノードが必要です。
専用の検索ノードを配置する場合は、さまざまな検索階層から選択できます。 各検索階層には、デフォルトの RAM 容量、ストレージ容量、および CPU が設定されています。 そのため、データベース配置とは別個にクラスターのサイズを設定および拡張することができます。 検索配置を個別にスケーリングするには、いつでもクラスター構成に次の変更を加えることができます。
クラスター上の検索ノードの数を調整します。
検索階層を変更して、ノードの CPU、RAM、ストレージを調整する。
注意
検索ノードと検索階層のコストの詳細については、[ MongoDB 料金] ページで [ View all plan featuresを展開し、[ Atlas Vector Search ] をクリックします。
ノードには、Atlas Vector Search インデックスの合計サイズより少なくとも 10% 大きい RAM があることをお勧めします。また、使用可能な CPU が十分にあることを確認することもお勧めします。クエリのレイテンシは、使用可能な CPU の数によって異なります。これは、クエリのパフォーマンスを加速する内部同時実行のレベルに大きな影響を与える可能性があります。
例
サイズが約 3 GB の 1M 768 次元ベクトルがあるとします。S30（低 CPU）と S20（高 CPU）検索階層のどちらにも、インデックスをサポートするのに十分な RAM があります。S30（低 CPU）検索階層に配置する代わりに、S20（高 CPU）検索階層に配置することをお勧めします。S20（高 CPU）検索階層ではクエリを同時に実行するために、より多くの CPU が使用できるためです。
専用検索ノードへの移行
専用検索ノードを使用すると、クラスターとは別に検索配置のサイズとスケーリングの両方を行うことができます。 また、データベース プロセスと検索プロセスの両方を同じノードで実行するクラスターで発生する可能性のあるリソースの競合も排除されます。
専用検索ノードに移行するには、配置を次の変更で行います。
配置で現在共有階層を使用している場合は、クラスターをより高い階層にアップグレードします。 専用検索ノードは、
M10以上のクラスター階層でのみサポートされます。 別のクラスター階層への移行の詳細については、「 Cluster Tierの変更 」を参照してください。専用検索ノードは、 AWSおよびAzureリージョンのサブセット、およびサポートされているすべての Google Cloud リージョンで利用できます。検索ノードも利用できるリージョンに クラスターを配置する ようにします。既存のクラスターが検索ノードを利用できないリージョンにある場合は、検索ノードが利用できるリージョンにクラスターを移行します。詳しくは、「 クラウドプロバイダーのリージョン 」を参照してください。
Search Nodes for workload isolationを有効にして、検索ノードを構成します。 詳しくは、「検索ノードを追加する 」を参照してください。