MongoDB Search 配置オプション

ノード アーキテクチャ

テストおよびプロトタイプ作成環境には、 MongoDBプロセスとMongoDB Search プロセスが 同じノードで実行されるノードアーキテクチャを推奨します。この配置モデルの次の図では、 MongoDB Search mongot プロセスが Atlas クラスター内の各ノードで mongod と並行して実行され、これらは同じリソースを共有しています。

デフォルトでは 、Atlas は 最初のMongoDB Searchインデックスを作成するときに、mongod プロセスを実行するのと同じノードでMongoDB Search mongot プロセスを有効にします。

クエリを実行する際、 MongoDB Search は 構成済みの読み込み設定 (read preference)を使用して、クエリを実行するノードを識別します。クエリはまずMongoDBプロセスに送られます。このプロセスは、レプリカセットクラスターの場合は mongod、シャーディングされたクラスターの場合は mongos です。

For a replica set cluster, the mongod process routes the query to the mongot on the same node. For sharded clusters, your cluster data is partitioned across mongod instances (shards) and each mongot process can only access the data on the mongod instance on the same node. Therefore, you can't run MongoDB Search queries that target a particular shard. mongos routes the query to all shards, making these scatter gather queries. If you use zones to distribute a sharded collection over a subset of the shards in the cluster, MongoDB Search routes the query to the zone that contains the shards for the collection that you are querying and runs your $search queries on just the shards where the collection is located.

クエリがMongoDB Search mongot プロセスにルーティングされた後、mongot プロセスは検索とスコアリングを実行し、一致する結果のドキュメントID とその他の検索メタデータを対応する mongod プロセスに返します。次に、mongod プロセスは一致する結果のクエリをドキュメント全体で暗黙的に実行し、その結果をクライアントに返します。クエリで $search 同時実行 オプションを使用すると、 MongoDB Search はクエリ内並列処理を有効にします。詳細については、セグメント間でのクエリ実行の並列化 を参照してください。

mongot プロセスの詳細については、「クエリ処理」を参照してください。

MongoDB Searchインデックスで 保存済みソース フィールド を定義すると、mongot プロセスは mongot の指定フィールドを保存できます。次に、 MongoDB Search クエリで returnStoredSource オプション を使用すると、データベースでドキュメント全体を検索する代わりに、mongot から一致するドキュメントの保存済みフィールドを直接検索できます。

メリット

MongoDB Search を有効にすると、データベースに自動的に同期する統合された完全管理検索エンジンを使用して、データ上に検索を簡単に構築できます。MongoDB Search は、全文検索用の $search や $searchMeta などのMongoDB Search集計パイプラインステージ、セマンティック検索用の $vectorSearch などの MongoDB Search 集計パイプライン ステージを、他のMongoDB集計パイプラインステージやスコアベースの結果ランキングと組み合わせて使用する豊富な問い合わせ言語を提供します。

クラスターにプロビジョニングされるリソースによっては、同じノードに両方の プロセスを配置した方が、別個の 専用ノードで検索プロセスを実行中よりもコスト効率が高くなる場合があります。

制限

データベースmongod と検索 mongot プロセス間でリソース競合が発生する可能性があります。これは、インデックスのパフォーマンスとクエリのレイテンシに影響可能性があります。本番環境に対応できるアプリケーションとその検索ワークロードをサポートするには、専用の検索ノードに移行します。

コスト

クラスターでMongoDB Search を有効にしても、追加料金や料金は発生しません。ただし、大規模なインデックス付きコレクションまたはインデックス定義では、クラスターのリソース使用率が増加する可能性があります。

Considerations

mongod プロセスと mongot プロセスの両方が 同じノードで実行されるため、特定の状況下で mongot が使用できなくなる可能性があります。 次の表では、潜在的な原因について説明しています。

ノード アーキテクチャ

本番環境では、 MongoDBプロセスとMongoDB Search プロセスが別々のノードで実行されるノードアーキテクチャを推奨します。個別の検索ノードを配置するには、専用検索ノードへの移行を参照してください。

この配置モデルの次の図では、 MongoDB Search mongot プロセスは専用の検索ノードで実行されます。このノードは、mongod プロセスが実行されるクラスター ノードとは別です。

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

When you deploy separate Search Nodes, Atlas automatically assigns a mongod for each mongot for indexing. The mongot communicates with the mongod to listen for and sync index changes for the indexes that it stores. MongoDB Search indexes and processes your queries similar to a deployment where both the mongod and mongot processes run on the same node. To learn more, see Supported Clients and Queries and Indexes. To learn more about deploying Search Nodes separately, see Search Nodes for Workload Isolation.

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

クエリを実行すると、クエリは 構成済みの読み込み設定 (read preference) に基づいて mongod にルーティングされます。mongod プロセスは、同一のノード上のロードバランサーを通じて検索クエリーを転送します。その結果、 mongot プロセス全体にリクエストが分散されます。

MongoDB Search mongot プロセスは検索とスコアリングを実行し、一致する結果のドキュメントID とメタデータを mongod に返します。次に、mongod はドキュメント全体で一致する結果の検索を実行し、その結果をクライアントに返します。クエリで $search 同時実行 オプションを使用すると、 MongoDB Search はクエリ内並列処理を有効にします。詳細については、セグメント間でのクエリ実行の並列化 を参照してください。

If you delete all the Search Nodes on your cluster, there will be an interruption in processing your search query results. To learn more, see Modify a Cluster. If you delete your Atlas cluster, Atlas pauses and then deletes all associated MongoDB Search deployments (mongot processes).

MongoDB Searchインデックスで 保存済みソース フィールド を定義すると、mongot プロセスは mongot の指定フィールドを保存できます。次に、 MongoDB Search クエリで returnStoredSource オプション を使用すると、データベースでドキュメント全体を検索する代わりに、mongot から一致するドキュメントの保存済みフィールドを直接検索できます。

メリット

別個の検索ノードを配置すると次のメリットが得られます。

高可用性

別個の検索ノードを配置すると、Atlas は少なくとも 2 つの検索ノードを強制して、障害や中断が発生した場合にワークロードが最小限のダウンタイムで機能し続けるようにします。

スケーラビリティ

検索ノードを個別に配置すると、MongoDB クラスターから独立してストレージと計算能力をスケールできます。これにより、MongoDB とは独立してクエリ負荷をスケールすることも可能です。

検索ノードを水平方向に増やすするには、検索ノードの数を増減します。最小 2 から最大 32 の検索ノードまでプロビジョニングできます。クエリの負荷を分散するために、 MongoDB Search は検索クエリを利用可能なすべての検索ノードに分散します。

検索ノードを垂直方向にスケールするには、フルテキストワークロードをサポートするさまざまな検索階層、CPU、RAM、およびストレージ構成を選択します。

パフォーマンス

専用の検索ノードを導入することで、mongodおよび mongotプロセスのパフォーマンスとリソース利用率が向上し、これらのプロセス間のリソース競合が解消されます。

専用検索ノードは同時セグメント検索をサポートしているため、 MongoDB Search は複数のインデックスセグメントを同時に検索できます。同時セグメント検索を使用すると、クエリの応答時間が改善される場合があります。

ワークロードの分離

専用の検索ノードを配置しても、メインのデータベースノードへのデータ転送には直接影響しません。検索ノードは検索クエリをデータベースのメイン操作とは別に処理するため、ワークロードを分離できますが、検索ノードとデータベースノード間のトラフィックに対してのみネットワーク料金が発生します。

検索ノードのサイズ設定とスケーリングに関するヒント

検索ノードのメモリ要件を決定するには、次の Atlas メトリクスを使用します。

• 検索インデックスのサイズ

• 検索ノード上の RAM の合計

検索インデックスが 10 GB で、検索ノードの合計 RAM が 4 GB のアプリケーションを考えてみましょう。この場合、1GBのRAMが他のプロセスで使用され、インデックスデータ用に3GBのみが使用可能な場合、残りの7GBのインデックスデータ（10GB - 3GB = 7GB）は、必要に応じてディスクからページインされます。ディスクからの頻繁なページングは、ページフォールト、ディスク I/O、CPU IOWait の増加を引き起こし、パフォーマンスの低下を招きます。

8GB 以上の RAM を持つ上位のクラスター階層を使用すると、Atlas は検索インデックスの大部分のデータをメモリから提供でき、ディスクの読み取りとページ フォールトを最小化され、パフォーマンスが向上します。

検索ノードのコスト

MongoDB supports separate Search Nodes on dedicated (M10 or higher) clusters. Search Nodes are deployed on compute-intensive instances with high-performance local storage. You must deploy a minimum of two nodes. You will be billed daily for hourly resource usage per node. To learn more, see Search Node Costs.

保存時の暗号化の有効化

デフォルトでは、MongoDBプロセスと検索プロセスは同じノードで実行されます。このアーキテクチャでは、カスタマー マネージドの暗号化はデータベースデータに適用されますが、検索インデックスには適用されません。

専用の検索ノードを有効にすると、検索プロセスは別々のノードで実行されます。これにより、検索ノード データの暗号化が有効になり、データベースデータと検索インデックスの両方を同じカスタマー マネージド キーで暗号化して、包括的な暗号化をカバレッジすることができます。

詳細については、「検索ノードのカスタマーキー管理を有効にする」を参照してください。

専用検索ノードの追加

新しいクラスターに専用の検索ノードを追加すると、次のことが可能になります。

• Change the size and scale of your search deployment independently from your database deployment.

• MongoDBデータベースと検索プロセスを同じノードで実行するクラスターで発生する可能性のあるリソース競合を解消します。

専用の検索ノードを追加するには以下の手順に従います。

1. Create your cluster as an M10 or higher tier in a cloud provider and region that supports node isolation. To learn more, see Create a Cluster.

   Dedicated Search Nodes are supported only for M10 and higher cluster tiers and in cloud provider regions that support node isolation.

2. Enable Search Nodes for workload isolation and Configure Search Nodes.

専用検索ノードへの移行

ステージングから本番環境に移行し、専用の検索ノードを追加するには、既存のステージングとプロトタイプ作成の配置に次の変更を加えます。

1. If your deployment uses a Flex cluster, change the cluster tier to a higher tier. Dedicated Search Nodes are supported only for M10 and higher cluster tiers.

2. Deploy your cluster in regions where Search Nodes are also available. Dedicated Search Nodes are available on a subset of the AWS and Azure regions and in all supported Google Cloud regions. If your existing cluster is hosted in regions where Search Nodes aren't available, migrate your cluster to regions where Search Nodes are available. To learn more, see Cloud Provider Regions that Support Node Isolation.

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

   専用の検索ノードを配置すると、次の一連のアクションが実行されます。

   • Atlas は検索ノードに検索インデックスを構築し、クラスター ノードからインデックスを削除します。

   • Atlas は検索クエリを検索ノードにルーティングします。

   • MongoDB Search は、検索インデックスを使用してクラスターにクエリを処理します。

配置のトラブルシューティング