データベースの負荷分散により、同時クライアント要求が複数のデータベースサーバーに分散され、単一サーバーの負荷が軽減されます。これにより、データベースのパフォーマンスを大幅に向上させることができます。幸い、MongoDBは、デフォルトで同じデータの読み取りと書き込みを同時に行う複数のクライアントの要求を処理できます。いくつかの同時実行制御メカニズムとロックプロトコルを使用して、常にデータの一貫性を確保します。
このようにして、MongoDBは、すべてのクライアントがいつでもデータの一貫したビューを取得できるようにします。複数のクライアントからのリクエストを処理するこの組み込み機能により、MongoDBサーバーの上に外部ロードバランサーを追加することを心配する必要はありません。ただし、負荷分散を使用してデータベースのパフォーマンスを向上させたい場合は、次の方法でそれを実現できます。
MongoDB垂直スケーリング
簡単に言うと、垂直スケーリングとは、ロードを処理するためにサーバーにリソースを追加することを意味します。すべてのデータベースシステムと同様に、MongoDBはより多くのRAMとIO容量を優先します。これは、複数のサーバーに負荷を分散させることなく、MongoDBのパフォーマンスを向上させる最も簡単な方法です。 MongoDBデータベースの垂直スケーリングには、通常、CPU容量またはディスク容量の増加とスループット（I / O操作）の増加が含まれます。リソースを追加することで、mongoサーバーは複数のクライアントのリクエストを処理できるようになります。したがって、データベースの負荷分散が向上します。
このアプローチを使用することの欠点は、単一のシステムにリソースを追加することの技術的限界です。また、すべてのクラウドプロバイダーには、新しいハードウェア構成の追加に制限があります。このアプローチのもう1つの欠点は、単一障害点です。このアプローチでは、すべてのデータが単一のシステムに保存されるため、データが永久に失われる可能性があります。
MongoDB水平スケーリング
水平スケーリングとは、データベースをチャンクに分割し、それらを複数のサーバーに保存することです。このアプローチの主な利点は、サーバーをオンザフライで追加して、ダウンタイムなしでデータベースのパフォーマンスを向上できることです。 MongoDBは、シャーディングによる水平スケーリングを提供します。 MongoDBシャーディングは、書き込み負荷を複数のサーバー（シャード）に分散するための追加の容量を提供します。ここでは、各シャードを1つの独立したデータベースと見なすことができ、すべてのシャードのコレクションを1つの大きな論理データベースと見なすことができます。シャーディングにより、MongoDBはデータを複数のサーバーに分散して、同時クライアント要求を効率的に処理できます。したがって、データベースの読み取りと書き込みのスループットが向上します。
MongoDBシャーディング
シャードは、単一のmongodインスタンス、またはmongoシャードデータベースのサブセットを保持するレプリカセットにすることができます。レプリカセットのシャードを変換して、データの高可用性と冗長性を確保できます。
上の画像でわかるように、シャード1はコレクション1とコレクション2全体に対して、シャード2にはコレクション1の他のサブセットのみが含まれます。 mongosインスタンスを使用して各シャードにアクセスできます。たとえば、shard1インスタンスに接続すると、collection1のサブセットのみを表示/アクセスできるようになります。
Mongosは、クライアントアプリケーションのシャードクラスターへのアクセスを提供するクエリルーターです。負荷分散を改善するために、複数のmongosインスタンスを持つことができます。たとえば、本番クラスタでは、アプリケーションサーバーごとに1つのmongosインスタンスを持つことができます。ここで、外部ロードバランサーを使用できます。これにより、アプリケーションサーバーのリクエストが適切なmongosインスタンスにリダイレクトされます。このような構成を本番サーバーに追加するときは、カーソルなどの一部のmongoリソースがmongosインスタンスに固有であるため、クライアントからの接続が常に同じmongosインスタンスに接続するようにしてください。
構成サーバーは、クラスターに関する構成設定とメタデータを保存します。 MongoDBバージョン3.4からは、構成サーバーをレプリカセットとしてデプロイする必要があります。本番環境でシャーディングを有効にする場合は、それぞれ異なるマシン上にある3つの個別の構成サーバーを使用する必要があります。
このガイドに従って、レプリカセットクラスターをシャードクラスターに変換できます。シャーディングされた本番クラスターのサンプル図は次のとおりです。
MongoDBレプリケーションを使用して、クライアントからのより多くのトラフィックを処理し、プライマリサーバーの負荷を軽減できる場合があります。これを行うには、プライマリサーバーではなくセカンダリから読み取るようにクライアントに指示できます。これにより、クライアントからのすべての読み取り要求がセカンダリサーバーによって処理され、プライマリサーバーが書き込み要求のみを処理するため、プライマリサーバーの負荷を軽減できます。
以下は、読み取りプリファレンスをセカンダリに設定するコマンドです：
db.getMongo().setReadPref('secondary')読み取りクエリの処理中に、特定のセカンダリをターゲットにするタグを指定することもできます。
db.getMongo().setReadPref(
"secondary", [
{ "datacenter": "APAC" },
{ "region": "East"},
{}
])ここで、MongoDBはデータセンタータグの値がAPACであるセカンダリノードを見つけようとします。見つかった場合、Mongoはタグデータセンター「APAC」を持つすべてのセカンダリからの読み取り要求を処理します。見つからない場合、Mongoはタグ領域が「East」のセカンダリを検索しようとします。それでもセカンダリが見つからない場合は、{}がデフォルトのケースとして機能し、Mongoは適格なセカンダリからのリクエストを処理します。
ただし、この負荷分散のアプローチを使用して読み取りスループットを向上させることはお勧めできません。プライマリ以外の読み取り設定モードでは、プライマリサーバーで最近書き込みが更新された場合に、古いデータが返される可能性があるためです。通常、プライマリサーバーは書き込み要求を処理し、変更をセカンダリサーバーに伝達するのに時間がかかります。この間、誰かが同じデータに対して読み取り操作を要求すると、セカンダリサーバーはプライマリサーバーと同期していないため、古いデータを返します。アプリケーションが書き込み操作に比べて読み取り操作が多い場合は、このアプローチを使用できます。
MongoDBはそれ自体で同時リクエストを処理できるため、MongoDBクラスターにロードバランサーを追加する必要はありません。クライアント要求の負荷分散には、セカンダリを使用して読み取りおよび書き込み操作をスケールアウトすることはお勧めできないため、垂直スケーリングまたは水平スケーリングのいずれかを選択できます。上で説明したように、垂直スケーリングは技術的な限界に達する可能性があります。したがって、小規模なアプリケーションに適しています。大規模なアプリケーションの場合、シャーディングによる水平スケーリングは、読み取り操作と書き込み操作の負荷分散に最適なアプローチです。