Overview
The following sections describe deployment options for MongoDB Search on Atlas.
本番前または本番環境のニーズに合わせて、さまざまな配置タイプ、クラウドプロバイダー、およびクラスター階層を使用してクラスターを構造化できます。これらの推奨事項を使用して、配置タイプ、クラウドプロバイダーとリージョン、およびベクトル検索を実行するためのクラスターと検索階層を選択します。
environment | 配置タイプ | クラスター階層 | クラウドプロバイダーのリージョン | ノード アーキテクチャ |
|---|---|---|---|---|
クエリのテスト | フレキシブルな専有クラスター | 無料クラスター、Flex、以上の階層 | All | MongoDB and Search processes run on the same node. |
アプリケーションのプロトタイプ作成 | シャーディングまたはシャーディングされていない専用クラスター |
| すべて | MongoDB and Search processes run on the same node. |
本番環境 | シャーディングまたはシャーディングされていない個別の検索ノードを持つ専用クラスター |
| AWS and Azure in some regions or Google Cloud in all regions | MongoDB and Search processes run on different nodes. |
Community Edition | Self-managed deployment. You install and operate | N/A. You provide your own hardware or cloud instances. | N/A. You choose your own infrastructure. | MongoDB and Search processes run on either a single or separate self-managed hosts. |
次のセクションでは、各環境について説明します。
環境のテストとプロトタイプ作成
検索クエリをテストし、アプリケーションをプロトタイプするには、以下のセクションで説明されているデプロイメント タイプとノード アーキテクチャをお勧めいたします。
この構成は、次のユースケースに最適です。
インデックスするドキュメントの合計が 2M 未満
10GB 未満のインデックス データ
7 日間で 10,000 件未満のクエリ
使用量が記載された値を超える場合は、専用の検索ノードに移行します。
以下のセクションでは、このノード アーキテクチャについて詳しく説明します。
- 配置タイプ
クラウドのクラスターでMongoDB Search クエリをテストするには、 Flex または専有クラスターを配置できます。
To test MongoDB Search queries locally, create a local Atlas deployment using the Atlas CLI. This could be a single-node replica set hosted on your local computer. Local deployments are limited by the CPU, memory, and storage resources of your local machine. When your application is ready for production, migrate your local Atlas deployment to a production environment.
- Cluster Tiers
MongoDB Search クエリをテストするには、 無料クラスター（以前は
M0と呼ばれる）と Flex クラスターを使用します。For prototyping your application, use dedicated
M10,M20, and higher tier clusters or deploy dedicated Search Nodes for workload isolation. When your application is ready for production and to handle large datasets, scale to higher tiers.- クラウドプロバイダーとリージョン
サポートされている任意のクラウドプロバイダーリージョンを使用してください。
The cloud provider and region that you choose affect the configuration options available for the cluster tiers and the cost of running the cluster.
ノード アーキテクチャ
テストおよびプロトタイプ作成環境には、 MongoDBプロセスとMongoDB Search プロセスが 同じノードで実行されるノードアーキテクチャを推奨します。この配置モデルの次の図では、 MongoDB Search mongot プロセスが Atlas クラスター内の各ノードで mongod と並行して実行され、これらは同じリソースを共有しています。
デフォルトでは 、Atlas は 最初のMongoDB Searchインデックスを作成するときに、mongod プロセスを実行するのと同じノードでMongoDB Search mongot プロセスを有効にします。
MongoDB Search がこのアーキテクチャでクエリをプロセシングする方法については、 クエリプロセシングを参照してください。
MongoDB Searchインデックスで 保存済みソース フィールド を定義すると、mongot プロセスは mongot の指定フィールドを保存できます。次に、 MongoDB Search クエリで returnStoredSource オプション を使用すると、データベースでドキュメント全体を検索する代わりに、mongot から一致するドキュメントの保存済みフィールドを直接検索できます。
メリット
When you enable MongoDB Search, you can easily build search on top of your data with an integrated, fully managed search engine that automatically syncs to your database. MongoDB Search provides a rich query language that uses MongoDB Search aggregation pipeline stages like $search and $searchMeta for full-text search and $vectorSearch for semantic search in conjunction with other MongoDB aggregation pipeline stages, and score-based results ranking.
クラスターにプロビジョニングされるリソースによっては、同じノードに両方の プロセスを配置した方が、別個の 専用ノードで検索プロセスを実行中よりもコスト効率が高くなる場合があります。
制限
You might experience resource contention between the database mongod and the search mongot processes. This could negatively impact the performance of your index and latency of your queries. To support production-ready applications and their search workloads migrate to dedicated Search Nodes.
コスト
クラスターでMongoDB Search を有効にしても、追加料金や料金は発生しません。ただし、大規模なインデックス付きコレクションまたはインデックス定義では、クラスターのリソース使用率が増加する可能性があります。
Considerations
mongod プロセスと mongot プロセスの両方が 同じノードで実行されるため、特定の状況下で mongot が使用できなくなる可能性があります。 次の表では、潜在的な原因について説明しています。
原因 | 説明 |
|---|---|
クラスター階層のスケーリング - ネットワーク ストレージ | クラスターを増やすアップまたはスケールダウンすると、Atlas は新しいインスタンスをプロビジョニングします。 インスタンスの準備ができると、Atlas はネットワークストレージを接続し、新しいノードで
|
クラスター階層のスケーリング - ローカルSSD | |
Lucene のダウングレード | In rare cases where you require downgrading Lucene, you might not be able to read newer Lucene index formats. |
ストレージの調整 | Atlas クラスター ノードに接続されたネットワークストレージを保持できます。 これにより、 ただし、クラスターがローカル NVMe ディスクを使用している場合、またはその他のまれな状況では、特定のリージョンではネットワークストレージを保持できない場合があります。このような場合、Atlas は最初の同期を実行し、最初の同期が完了するまで検索クエリは失敗します。 |
|
|
新しい | クラスターに新しいノードを追加すると、Atlas は最初の同期を実行して検索インデックスを作成します。 新しい |
インスタンスの再起動または置換 |
|
|
|
本番環境
本番環境に対応したアプリケーションには、次のセクションで説明する配置タイプとノード アーキテクチャを使用することをお勧めします。
この構成は、次のユースケースに最適です。
既存のテスト環境を本番環境に移行する場合は、専用の検索ノードをクラスターに追加します。「専用検索ノードへの移行」を参照してください。
新しい本番環境の配置を最初から作成する場合は、 MongoDB Search が利用できるリージョンとゾーンでMongoDB Search をサポートする
M10以上の階層のクラスターを使用し、専用の検索ノードを環境に追加します。詳しくは、専用検索ノードの追加 を参照してください。
- 配置タイプ
本番環境向けのアプリケーションには、
M10、M20、およびそれ以上の専有クラスター階層を使用してください。これらの上位階層のクラスターは、大規模なデータセットや本番環境のワークロードを処理できます。We recommend that you also deploy dedicated Search Nodes. If your search requirements increase, you can scale up your search deployment independently of scaling up the MongoDB nodes.
- クラウドプロバイダーとリージョン
Use Search Nodes in all Google Cloud regions and in a subset of AWS and Azure regions. You must select a cloud provider and region where Search Nodes are available for your deployment.
All cluster tiers are available in supported cloud provider regions. The cloud provider and region that you choose affect the configuration options and search tiers available for the cluster and the cost of running the cluster.
ノード アーキテクチャ
本番環境では、 MongoDBプロセスとMongoDB Search プロセスが別々のノードで実行されるノードアーキテクチャを推奨します。個別の検索ノードを配置するには、専用検索ノードへの移行を参照してください。
この配置モデルの次の図では、 MongoDB Search mongot プロセスは専用の検索ノードで実行されます。このノードは、mongod プロセスが実行されるクラスター ノードとは別です。
Atlas は、各クラスターまたはクラスター上の各シャードに検索ノードを配置します。たとえば、3 つのシャードを持つクラスターに 2 つの検索ノードを配置すると、Atlas は 6 つの検索ノード（シャードあたり 2 つ）を配置します。また、検索ノードの数と、各検索ノードにプロビジョニングされるリソースの量を構成することもできます。
MongoDB Search がこのアーキテクチャでクエリをプロセシングする方法については、 クエリプロセシングを参照してください。
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 は検索インデックスの大部分のデータをメモリから提供でき、ディスクの読み取りとページ フォールトを最小化され、パフォーマンスが向上します。
注意
The local SSDs used for Search Nodes require a 20% storage overhead to support index operations.
検索ノードのコスト
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プロセスと検索プロセスは同じノードで実行されます。このアーキテクチャでは、カスタマー マネージドの暗号化はデータベースデータに適用されますが、検索インデックスには適用されません。
When you enable dedicated Search Nodes, search processes run on separate nodes. This allows you to enable Search Node Data Encryption, so you can encrypt both database data and search indexes with the same customer-managed keys for comprehensive encryption coverage.
注意
データベース ノードと検索ノードは、同じカスタマー マネージド キーを使用して異なる暗号化方法を使用します。データベース ノードはWiredTiger暗号化ストレージ エンジンを使用し、検索ノードはディスク レベルの暗号化を使用します。
詳細については、「検索ノードのカスタマーキー管理を有効にする」を参照してください。
重要
この機能は KMS プロバイダー全体で利用できますが、検索ノードは AWS 上にある必要があります。
専用検索ノードの追加
新しいクラスターに専用の検索ノードを追加すると、次のことが可能になります。
検索配置のサイズと増やすは、データベース配置とは独立して変更します。
MongoDBデータベースと検索プロセスを同じノードで実行するクラスターで発生する可能性のあるリソース競合を解消します。
To deploy dedicated Search Nodes, you must have Project Owner access to the project.
専用の検索ノードを追加するには以下の手順に従います。
Create your cluster as an
M10or 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
M10and higher cluster tiers and in cloud provider regions that support node isolation.Enable Search Nodes for workload isolation and Configure Search Nodes.
専用検索ノードへの移行
ステージングから本番環境に移行し、専用の検索ノードを追加するには、既存のステージングとプロトタイプ作成の配置に次の変更を加えます。
If your deployment uses a Flex cluster, change the cluster tier to a higher tier. Dedicated Search Nodes are supported only for
M10and higher cluster tiers.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.
Enable Search Nodes for workload isolation and configure Search Nodes. To learn more, see Add Search Nodes.
専用の検索ノードを配置すると、次の一連のアクションが実行されます。
Atlas は検索ノードに検索インデックスを構築し、クラスター ノードからインデックスを削除します。
Atlas は検索クエリを検索ノードにルーティングします。
MongoDB Search は、検索インデックスを使用してクラスターにクエリを処理します。
配置のトラブルシューティング
Failed to Execute search Command エラー
mongod と並行して mongot を実行し、検索ノードを構成しない場合、mongot は次のいずれかのイベント中に終了し、Failed to Execute search Command エラーを返す可能性があります。
クラスターのスケールアップ
ノード フェイルオーバー
アップグレード
mongot
mongot を専用の検索ノードにデプロイすると、mongod は検索クエリをmongot プロセスがアクティブな正常なノードのみにルーティングするプロキシを使用します。
MongoDB コミュニティ エディション
If you run MongoDB Search on MongoDB Community Edition or another self-managed deployment, Atlas does not manage mongot for you. Instead, you install, configure, and operate mongot yourself. The following sections summarize the available architecture patterns and sizing options. For complete deployment and sizing guidance, see MongoDB Search and MongoDB Vector Search on Self-Managed Deployments and Introduction to mongot Deployment Sizing.
アーキテクチャパターン
As with MongoDB Search on Atlas, self-managed deployments use one of the same two architecture patterns: co-located or dedicated. The only exception is that on self-managed deployments, you provision and manage the hosts yourself.
サイズ設定
Unlike Atlas, self-managed deployments have no predefined cluster or search tiers. You provision your own hardware or cloud instances. To choose a starting configuration and refine it based on your workload, see Introduction to mongot Deployment Sizing.