膨大なコレクションがある場合、データベースのシャーディングは素晴らしいようです。かなりサイズのコレクションがたくさんある場合はどうなりますか？10万000のドキュメントのコレクション（それほど大きなコメントではない）に対して、シャーディングが効果的であるとしましょう。また、それぞれ10 000ドキュメントの10 000コレクションにも有効ですか？
（この質問は、コレクションをテーブルに置き換え、ドキュメントを行に置き換えた場合でも、テーブル指向のデータベースでは引き続き有効だと思います。可能であれば、理論的な答えと、理論的なものと異なる場合は、特定のMongoDBシナリオでの答えを知りたいです回答。）
回答:
また、1万件のドキュメントを含む1万件のコレクションにも有効ですか？
ほとんどの人は「単一の大規模なコレクション」の問題を抱えているため、このデータのバランスをとるという頭痛の種を減らすためにシャーディングは明らかに役立ちます。
ただし、10,000個の小さなコレクションがある場合、おそらく頭痛の種は「データのバランス」ではありません。このように多くの小さなコレクションがある場合、問題はこれらのコレクションを追跡することです。ドキュメントのサイズによっては、シャーディングの実際の下限を下回らない場合もあります。
非常に小さなコレクションの場合、あまり知られていないmovePrimaryコマンドを使用して、データの場所を管理できます。
もちろん、これを検討するもう1つの方法は、なぜ10kのコレクションがあるのかということです。コレクションは同種のオブジェクトを必要とせず、コレクションが10kの場合、ほとんどのオブジェクトを生成する必要があります。同じコレクションにデータのさまざまな「タイプ」を格納し、コレクションの数を減らし、そのタイプをシャードキーの一部として含めることは十分に可能です。
fooありbar、同じデータ構造の場合、それらをbazコレクションにマージして、_ids（コードで）をオーバーライドできます{ _id: "foo123" }, { _id: "bar123" }。より大きなインデックスがありますが、タイプを含むインデックスは1つしかありません。要件ではなく、単に「考えるための食物」です。
MongoDBシャーディングは、コレクションを小さな「チャンク」に分割し、それらを複数のマシンに均等に分散することで機能します。一般的に最も効率的なデフォルトのチャンクサイズは200MBです。そのため、コレクションが200 MBをはるかに超えて大きくならない限り、それはチャンクに分割されないため、シャーディングの対象にはなりません。そのため、メリットはありません。
一般的なケースでは、複数のマシンにデータをシャーディングすることは、読み取り、書き込み、クエリをスケーリングする非常に効果的な方法です。複数のCPU、ハードディスク、メモリストレージのメリットを活用して、データの読み取り、書き込み、処理を並行して行います。メモリーのスケールアウトは、MongoDBにとって特に重要です。MongoDBでは、高いパフォーマンスはメモリーに収まるデータに非常に敏感です。