Atlas Search 配置オプション
本番前または本番環境のニーズに合わせて、さまざまな配置タイプ、クラウドプロバイダー、およびクラスター階層を使用して Atlas クラスターを構成できます。 これらの推奨事項を使用して、配置タイプ、クラウドプロバイダーとリージョン、およびベクトル検索を実行するためのクラスターと検索階層を選択します。
environment | 配置タイプ | クラスター階層 | クラウドプロバイダーのリージョン | ノード アーキテクチャ |
|---|---|---|---|---|
クエリのテスト | Shared or dedicated cluster Local deployment | M0, M2, M5, or higher tierN/A | All N/A | MongoDB プロセスと Search プロセスは同じノードで実行 |
アプリケーションのプロトタイプ作成 | シャーディングまたはシャーディングされていない専用クラスター |
| すべて | MongoDB プロセスと Search プロセスは同じノードで実行 |
本番環境 | シャーディングまたはシャーディングされていない個別の検索ノードを持つ専用クラスター |
| 一部のリージョンではAmazon Web ServicesまたはすべてのリージョンではGoogle Cloud PlatformとAzure | MongoDB プロセスと Search プロセスは異なるノードで実行 |
これらの配置モデルの詳細については、次のセクションを確認してください。
環境のテストとプロトタイプ作成
検索クエリをテストし、アプリケーションのプロトタイプを作成するには、次の構成をお勧めします。 この構成は、次のユースケースに最適です。
インデックスを作成するドキュメントの合計数が2 M 未満。
インデックス データは10 GB 未満です。
10未満の場合、 7日間に000クエリを実行します。
使用量がリストされている値を超える場合は、別個の検索ノードに移行してください。
配置タイプ
Atlas Search クエリをテストするには、共有クラスターまたは専有クラスター、またはローカル Atlas 配置を配置できます。
Cluster Tiers
共有クラスターには、 M0 、 M2 、 M5階層が含まれます。 これらの低コストのクラスタータイプは、Atlas Search クエリのテストに使用できます。 ただし、共有クラスターではリソース競合とクエリ レイテンシが発生する可能性があります。 共有クラスターでプロジェクトを開始した場合は、アプリケーションの本番環境が準備できたら、より高い階層にアップグレードすることをお勧めします。
専有クラスターにはM10以上の階層が含まれます。 M10階層とM20 階層はアプリケーションのプロトタイプ作成に適しています。アプリケーションの本番環境が準備できたら、上位階層にアップグレードして大規模なデータセットを処理したり、 専用の検索ノードを配置してワークロードを分離したりできます。
クラウドプロバイダーとリージョン
すべてのクラスター階層は、サポートされているすべてのクラウドプロバイダー リージョンで利用できます。 選択したクラウドプロバイダーとリージョンは、クラスター階層で使用可能な構成オプションと クラスターのランニング コスト に影響します。
Atlas Search クエリをローカルでテストしたい場合は、Atlas CLI を使用してローカル コンピューターでホストされている単一ノードのレプリカセットを配置できます。 詳細については、「 Atlas 配置のローカル配置の作成 」を参照してください。
アプリケーションの本番環境が準備できたら、ライブ移行を使用してローカル Atlas の配置を本番環境に移行します。 ローカル配置は、ローカル マシンの CPU、メモリ、およびストレージ リソースによって制限されます。
ノード アーキテクチャ
この配置モデルでは、検索mongotプロセスが Atlas クラスター内の各ノードでmongodと並行して実行されます。 mongodプロセスは同じノード上のmongotにクエリをルーティングし、同じリソースを共有します。
デフォルトでは、Atlas は最初の Atlas Search インデックスを作成するときに、 mongodプロセスを実行するのと同じノードで検索mongotプロセスを有効にします。 mongotプロセスは、 mongotプロセスについて で説明されているアクションを実行します。
Atlas Search インデックスで保存済みソースフィールド を定義すると、 mongotプロセスはmongotの指定フィールドを保存できるようになります。 次に、Atlas Search クエリでreturnStoredSource オプションを使用すると、データベースでドキュメント全体を検索する代わりに、 mongotから一致するドキュメントの保存済みフィールドを直接検索できます。
メリット
Atlas Search を有効にすると、データベースに自動的に同期する統合されたフルマネージド検索エンジンを使用して、データ上に検索を簡単に構築できます。 Atlas Search は、全文検索用の$searchや$searchMeta 、セマンティック検索用の$vectorSearchなどの Atlas Search 集計パイプライン ステージを、MongoDB の他の集計パイプライン ステージやスコアベースの結果ランキングと組み合わせて使用する豊富な問い合わせ言語を提供します。
クラスターにプロビジョニングされるリソースによっては、別個の専用ノードで検索プロセスを実行するよりも、同じノードに両方の プロセスを配置するとコスト効率が高くなる場合があります。
制限
データベースmongodと検索mongotプロセス間でリソース競合が発生する可能性があります。 これは、インデックスのパフォーマンスとクエリのレイテンシに悪影響を与える可能性があります。 この配置モデルは、環境のテストとプロトタイプ作成のみに推奨します。 本番環境に対応できるアプリケーションと関連する検索ワークロードの場合は、専用の検索ノードに移行することをお勧めします。
コスト
Atlas クラスターで Atlas Search を有効にしても、追加料金や料金は発生しません。 ただし、インデックス作成されたコレクションのサイズやインデックス定義などの要因によっては、クラスターでのリソース使用率が増加することがあります。
Considerations
mongod プロセスと mongot プロセスの両方が 同じノードで実行されるため、特定の状況下で mongot が使用できなくなる可能性があります。次の表では、潜在的な原因について説明しています。
原因 | 説明 |
|---|---|
クラスター階層のスケーリング - ネットワーク ストレージ | クラスターを増やすアップまたはスケールダウンすると、Atlas は新しいインスタンスをプロビジョニングします。インスタンスの準備ができると、Atlas はネットワークストレージを接続し、新しいノードで
|
クラスター階層のスケーリング - ローカルSSD | |
Lucene のダウングレード | Lucene のダウングレードが必要になる稀なケースでは、新しい Luceneインデックス形式を読み取れない可能性があります。 |
ストレージの調整 | Atlas クラスター ノードに接続されたネットワークストレージを保持できます。これにより、 ただし、クラスターがローカル NVMe ディスクを使用している場合、またはその他のまれな状況では、特定のリージョンではネットワークストレージを保持できない場合があります。このような場合、Atlas は最初の同期を実行し、最初の同期が完了するまで検索クエリは失敗します。 |
|
|
新しい | クラスターに新しいノードを追加すると、Atlas は最初の同期を実行して検索インデックスを作成します。新しい |
インスタンスの再起動または置換 |
|
本番環境
本番環境のアプリケーションには、次のクラスター構成が推奨されます。 この構成は、次のユースケースに適しています。
インデックスを作成するドキュメントの合計が2 M より大きい
インデックス データが10 GB を超える。
10より大きい場合、 7日ごとに000クエリを実行します。
配置タイプ
本番環境に対応できるアプリケーションには専有クラスターが必要です。
Cluster Tiers
専有クラスターにはM10以上の階層が含まれます。 M10階層とM20 階層は開発環境と本番環境に適しています。ただし、上位階層では大規模なデータセットと本番環境のワークロードを処理できます。 検索ワークロード用に専用の検索ノードも配置することをお勧めします。 これにより、検索配置を個別かつ適切に増やすことができます。
クラウドプロバイダーとリージョン
検索ノードはGoogle Cloud PlatformとAzureのすべてのリージョンで利用できますが、 Amazon Web Servicesリージョンのサブセットでのみ利用できます。 配置で検索ノードが利用できるクラウドプロバイダーとリージョンを選択する必要があります。
すべてのクラスター階層はサポートされているクラウドプロバイダー リージョンで利用できます。 選択したクラウドプロバイダーとリージョンは、クラスターで使用可能な構成オプションと検索階層、および クラスターのランニング コスト に影響します。
ノード アーキテクチャ
この配置モデルでは、 mongotプロセスは、 mongodプロセスが実行されるクラスター ノードとは別の検索ノードで実行されます。 Atlas は、各クラスターまたはクラスター上の各シャードに検索ノードを配置します。
たとえば、3 つのシャードを持つクラスターに 2 つの検索ノードを配置すると、Atlas は 6 つの検索ノード（シャードあたり 2 つ）を配置します。 また、検索ノードの数と、各検索ノードにプロビジョニングされるリソースの量を構成することもできます。
別個の検索ノードを配置すると、Atlas はインデックス作成用に各mongotにmongodを自動的に割り当てます。 mongotはmongodと通信して、保存しているインデックスの変更をリッスンし、同期します。 Atlas Search は、 mongodとmongotプロセスの両方が同じノードで実行される場合と同様に、クエリのインデックスと処理を行います。 詳しくは、「 Atlas Search インデックスの作成と管理 」および「 Atlas Search クエリの作成と実行」を参照してください。 検索ノードを個別に配置する方法の詳細については、「ワークロード分離用の検索ノード 」を参照してください。
検索ノードに移行すると、Atlas は検索ノードを配置しますが、検索ノード上のクラスター上のすべてのインデックスが正常に構築されるまで、ノードに対するクエリを処理しません。 Atlas が新しいノードにインデックスをビルドする間も、クラスター ノードのインデックスを使用してクエリを処理し続けます。 Atlas は、検索ノードにインデックスを正常にビルドし、クラスター ノード上のインデックスを削除した後にのみ、検索ノードからクエリの処理を開始します。
クラスター上のすべての検索ノードを削除すると、検索クエリー結果の処理が中断されます。 詳細については、「クラスターの変更」を参照してください。 Atlas クラスターを削除すると、Atlas は一時停止し、関連付けられているすべての Atlas Search 配置（ mongotプロセス）を削除します。
Atlas Search インデックスで保存済みソースフィールド を定義すると、 mongotプロセスはmongotの指定フィールドを保存できるようになります。 次に、Atlas Search クエリでreturnStoredSource オプションを使用すると、データベースでドキュメント全体を検索する代わりに、 mongotから一致するドキュメントの保存済みフィールドを直接検索できます。
メリット
別個の検索ノードを配置すると次のメリットが得られます。
- 高可用性
- 別個の検索ノードを配置すると、Atlas は少なくとも 2 つの検索ノードを強制して、障害や中断が発生した場合にワークロードが最小限のダウンタイムで機能し続けるようにします。
- スケーラビリティ
別個の検索ノードを配置すると、次の操作を実行できます。
ストレージをスケーリングし、MongoDB クラスターから独立してコンピューティングします。
MongoDB とは別個にクエリ負荷を拡張する。
検索ノードは水平と垂直の両方でスケーリングできます。
検索ノードの数を増減して、クラスターを水平方向にスケーリングできます。 最小2から最大32の検索ノードをプロビジョニングできます。 Atlas Search は、利用可能な検索ノードのリストを繰り返し処理して、検索ノードで実行されるクエリを分散するため、プロビジョニングされたすべてのノード間でクエリの負荷を分散します。
検索ノードにはさまざまな検索階層を選択できます。 さまざまな検索階層から、全文およびベクトル ワークロードに最も適した CPU、RAM、ストレージ構成を選択できます。
- パフォーマンス
個別の検索ノードを配置すると、
mongodプロセスとmongotプロセスの両方のパフォーマンスとリソース使用率が向上し、2 つのプロセス間のリソース競合がなくなります。専用検索ノードは同時セグメント検索をサポートしているため、Atlas Search は同時に複数のインデックス セグメントを同時に検索し、場合によってはクエリの応答時間を向上させることができます。 To learn more, see Parallelize Query Execution Across Segments.
クラスターのサイズ設定とスケーリング
検索ノードに必要なメモリの量を決定するには、次の Atlas メトリクスを使用します。
検索インデックスのサイズ
検索ノード上の RAM の合計
たとえば、次の点について考えてみましょう。
検索インデックスのサイズ = 10 GB
検索ノードの合計 RAM = 4 GB
4 GB の RAM のうち、 1 GB が他のプロセスによって使用され、インデックス データ用に使用できるのは3 GB のみであるとします。 したがって、残りの7 GB のインデックス データ（ 10 GB - 3 GB = 7 GB）は、必要に応じてディスクからページインされます。 ディスクからのページングが頻繁に行われると（ 7 GB）、ページフォールト、ディスク I/O、CPU IOWait が増加し、パフォーマンスが低下します。
より多くの RAM（ 8 GB 以上）を備えた上位の検索階層では、検索インデックスのデータのほとんどをメモリから提供できるため、ディスク読み取りとページ フォールトを最小限に抑え、パフォーマンスが向上します。
注意
検索ノードに使用されるローカル SSD では、インデックス操作をサポートするために 20% のストレージ オーバーヘッドが必要です。
検索ノードのコスト
MongoDB は（M10 以上）の専有クラスターで個別の検索ノードをサポートします。検索ノードは、コンピュート集約型 NVMe インスタンスに配置されます。少なくとも 2 つのノードを配置する必要があります。ノードごとのリソース使用量が時間単位で毎日請求されます。詳細については、「検索ノードのコスト」を参照してください。
専用検索ノードへの移行
専用検索ノードを使用すると、クラスターとは別に検索配置のサイズを設定することもできます。 また、データベース プロセスと検索プロセスの両方を同じノードで実行するクラスターで発生する可能性のあるリソースの競合も排除されます。
専用検索ノードに移行するには、配置を次の変更で行います。
配置で現在共有階層を使用している場合は、クラスターをより高い階層にアップグレードします。 専用検索ノードは、
M10以上のクラスター階層でのみサポートされます。 別のクラスター階層への移行の詳細については、「 Cluster Tierの変更 」を参照してください。専用検索ノードは、 Amazon Web Servicesリージョンのサブセット、およびサポートされているすべてのGoogle Cloud PlatformおよびAzureリージョンで利用できます。 検索ノードも利用できるリージョンに クラスターを配置する ようにします。 既存のクラスターが検索ノードを利用できないリージョンにある場合は、検索ノードが利用できるリージョンにクラスターを移行します。 詳しくは、「クラウドプロバイダーのリージョン 」を参照してください。
Search Nodes for workload isolationを有効にして、検索ノードを構成します。 詳しくは、「検索ノードを追加する 」を参照してください。
別個の検索ノードを配置しても、Atlas が検索ノードにインデックスを構築している間、Atlas Search は Atlas クラスターのインデックスを使用してクエリを処理し続けます。 Atlas は、次の手順が完了した後にのみクエリを検索ノードにルーティングします。
検索ノードにすべてのインデックスが正常に構築されます。
クラスター ノードから検索インデックスを削除します。