データベース内のコレクション数の制限
Mongodbのコレクションの数に実際的な制限はあると言えますか？彼らはここに書く https://docs.mongodb.com/manual/core/data-model-operations/#large-number-of-collections ：
一般に、多数のコレクションを使用してもパフォーマンスが大幅に低下することはなく、非常に優れたパフォーマンスが得られます。
しかし、何らかの理由でmongodbはデータベース内の名前空間の数に制限24000を設定しているように見えますが、データベース内に多くのコレクションが存在してもパフォーマンスが発生しない場合、デフォルト設定に制限があるのはなぜでしょうかペナルティ？
たとえば、マルチテナントアプリケーションのデータベースに1つのアカウントのデータのコレクションを1つ持つなど、1つのデータベースにコレクションの数を事実上無制限にすることが実行可能なソリューションであることを意味します。データベースに？すべてのテナントのデータベースに非常に多くのコレクションを保持することが実行可能なソリューションである場合、たとえば、1つのコレクションに各テナントのドキュメントを保持する場合と比べて、そのメリットは何ですか？ご回答ありがとうございます。
この答えは遅れていますが、他の答えは少し...信頼性と事実情報の点で弱いようですので、私はそれを少し改善しようとします。
ただし、何らかの理由で、mongodbはデータベース内のネームスペースの数に24000の制限を設定しています。
これは単なるデフォルト設定です。はい、デフォルト設定があります。
制限ページで、24000が制限であると言っています（ http://docs.mongodb.org/manual/reference/limits/#Number%20of%20Namespaces ）、方法がないかのようにそれを拡張しますが、あります。
ただし、ネームスペースファイルの大きさには最大制限があります（ http://docs.mongodb.org/manual/reference/limits/#Size%20of%20Namespace%20File ）、これは2GBです。ほとんどの場合、およそ300万の名前空間を使用できますが、これは非常に印象的であり、多くの人がすぐにその制限に達するかどうかはわかりません。
構成内でnssizeパラメーターを使用して、デフォルト値を16MBより大きく変更することができます（ http://docs.mongodb.org/manual/reference/configuration-options/#nssize ）または実行時に、MongoDBの実行に使用されるコマンドを操作して（ http://docs.mongodb.org/manual/reference/mongod/#cmdoption-mongod--nssize ）。
私の知る限り、MongoDBがデフォルトでnssizeに16MBを実装する理由はありませんが、「ユーザーにすべての詳細を気にしない」というモットーについて聞いたことがないので、購入しません。
私の意見では、MongoDBがこれを隠している主な理由は、ドキュメントにあるように、
個別のコレクションは、高スループットのバッチ処理にとって非常に重要です。
MongoDBが設計されているように、クラスターを水平方向ではなく垂直方向にスケーリングする手段として複数のコレクションを使用することは、大規模なWebサイトの（非常に頻繁に）悪い習慣と見なされます。そのため、12Kコレクションは通常、人々が決して確認することはなく、決して確認すべきでないと見なされます。
これ以上の制限はありません！
他の答えが述べているように-これは名前空間ファイルのサイズによって決定されます。これは、16MBのデフォルト制限と2GBの最大制限があるため、以前は問題でした。ただし、MongoDB 3.0およびWiredTigerストレージエンジンのリリースでは、この制限が削除されたようです。 WiredTigerはほぼすべての点で優れているようです。そのため、レガシーサポートの理由を除いて、古いエンジンを使用する理由はほとんどありません。サイトから：
MMAPv1ストレージエンジンの場合、名前空間ファイルは2047メガバイト以下にする必要があります。
デフォルトでは、ネームスペースファイルは16メガバイトです。 nsSizeオプションを使用してサイズを構成できます。
WiredTigerストレージエンジンは、この制限を受けません。
少しの背景：
Mongoはデータベースを作成するたびに、そのデータベースのネームスペース（db.ns）ファイルを作成します。名前空間（または、必要に応じてコレクション）ファイルには、コレクションに関するメタデータが保持されます。デフォルトでは、ネームスペースファイルのサイズは16MBですが、サイズは手動で増やすことができます。各コレクションのメタデータは、648バイト+オーバーヘッドバイトです。これを16MBで除算すると、データベースごとに約24000の名前空間が得られます。大きなネームスペースファイルを指定することでmongoを起動でき、データベースごとにより多くのコレクションを作成できます。
デフォルト設定の背後にある考え方は、すべての詳細（および設定可能なノブ）でユーザーを煩わせず、ほとんどの人に一般的に機能するものを選択することです。また、実行可能性はベスト/グッドデザインプラクティスと密接に関連しています。クリスが言ったように、データの形状を考慮し、それに応じて決定します。
他の人が言及するように、デフォルトの名前空間サイズは16MBであり、約24000個の名前空間エントリを取得できます。実際、Ubuntuの私の64ビットインスタンスは、デフォルトの16MB名前空間ファイルを使用して23684で最高になりました。
FAQで言及されていない重要なことの1つは、インデックスも名前空間スロットを使用することです。
以下を使用して、名前空間エントリをカウントできます。
db.system.namespaces.count()
そして、実際にそこにあるものを実際に見ることも興味深いです：
db.system.namespaces.find()
一度データベースが作成されると、名前空間ファイルを拡張できないため、必要と思われるものよりも制限を高く設定します（私の知る限り-方法があれば教えてください!!!）。
実際には、私は最大に出会ったことがありません。しかし、コレクションの上限である24,000を超えたことはありません。パフォーマンステストを行ったとき以外は、200を超えたことはないと確信しています。認めなければならないのは、同じようなデータを独自のコレクションにグループ化するのではなく、単一のデータベースにそのような多くのコレクションを置くことは非常に多くの混乱のように思えます。
データとビジネスルールの形を考慮してください。マルチテナントアプリのデータを異なる論理グループに分ける必要があるようにデータをレイアウトする必要がある場合は、おそらく他のデータストアを検討する必要があります。 Mongoは優れていますが、コレクションの量に制限を設けているという事実から、パフォーマンスに影響する理論的な制限があることがわかっているためです。
おそらく、データの形状に一致するストアを検討する必要がありますか？たとえば、Riakには、アプリケーションに含めることができる「バケット」の数に制限はありません（理論上の最大値はありません）。アカウントごとに1つのバケットで完全に実行できますが、その方向に進むことでいくらかの可ability性を犠牲にします。
それ以外の場合は、likeのようなグループ化のよりリレーショナルなモデルに従うことをお勧めします。私の見解では、Mongoはリレーショナルデータベースとキーバリューストアの中間点のように感じます。これは、リレーショナルデータベースの世界からの概念化がより簡単であることを意味します。
コレクションを維持するための大きなオーバーヘッドがあるようです。 11000のコレクションに約1.5mioのドキュメントがあったデータベースを、約300のコレクションに同数のドキュメントがあるデータベースに縮小しました。これにより、データベースのサイズが8GBから1GBに削減されました。私はMongoDBの内部動作に精通していないので、これは明らかかもしれませんが、この文脈では注目に値するかもしれないと思いました。