集約フレームワークは、MongoDBインフラストラクチャの重要な歯車です。これは、MongoDBに保存されているデータを分析、要約、および集約するのに役立ちます。 MongoDB 2.6の集約フレームワークの詳細については、このブログ投稿を参照してください。
2.6リリースでは、MongoDBは、シャーディングされた環境での基盤となる集計パイプラインの実行方法に、微妙ではありますが重要な変更を加えました。シャーディングされたコレクションを操作する場合、MongoDBはパイプラインを2つのステージに分割します。最初のステージまたは「$match」フェーズは各シャードで実行され、関連するドキュメントを選択します。クエリプランナーがシャードキーに基づいてシャードが関連性がないと判断した場合、このフェーズはそのシャードで実行されません。
後続のステージは、コレクションの「プライマリ」シャードでのみ実行されます。このシャードは、他のシャードからのデータをマージし、パイプラインの残りの部分を実行します。これにより、集約されるコレクションのプライマリシャードにかなり多くの負荷がかかります。これは、3つのシャードを実行し、主に集計クエリを使用しているお客様の1人の例です。 
ご覧のとおり、最初のシャードの負荷は、他の理由の3〜4倍です。これは極端な例です。これは、2番目と3番目のシャードが後で追加された場合であり、したがって、すべてのコレクションのプライマリシャードが最初のシャードです。したがって、基本的に、すべての集約ジョブの後続のステージはShard1でのみ実行されます。プライマリシャードのログを調べると、他のシャードからデータを取得するいくつかの「マージ」コマンドが表示されます。
2.6より前は、集約パイプラインの後続のステージは、プライマリシャードではなく、MongoDBサーバーで実行されていました。
では、この不均一な負荷分散をどのように処理しますか？いくつかのオプションがあります：
- 複数のコレクションで集計を実行している場合は、コレクションの「プライマリシャード」がシャード全体に均等に分散されていることを確認してください。
- 1つのコレクションだけで集約の負荷が高い場合は、プライマリシャードに少し大きいマシンを使用する必要がある場合があります。
いつものように、質問やコメントがある場合は、[email protected]までメールでお問い合わせください。