まず、これは実際には次のバージョンで8MBに引き上げられています または16MB ...しかし、これを視野に入れると、10gen（MongoDBを開発した）のEliotが最も優れていると思います：
編集： サイズは正式に16MBに「引き上げられました」
したがって、ブログの例では、4MBは実際にはかなりの量です。たとえば、「War of theWorlds」の完全な非圧縮テキストはわずか364k（html）です：http：//www.gutenberg.org/etext/36
>あなたのブログ投稿が非常に長く、コメントが多い場合、私はそれを読むつもりはありません:)
トラックバックの場合、1MBをトラックバック専用にすると、簡単に10k以上（おそらく20kに近い）になる可能性があります
したがって、本当に奇妙な状況を除いて、それはうまく機能します。そして、例外的なケースやスパムの場合、とにかく20MBのオブジェクトが必要になるとは思いません。トラックバックを15k程度に制限することは、パフォーマンスにとって何の意味もあると思います。または、万が一発生した場合は、少なくとも特別なケーシング。
-エリオット
限界に達するのはかなり難しいと思います...そして時間の経過とともに、アップグレードすれば...心配する必要はますます少なくなります。
制限の主なポイントは、サーバー上のすべてのRAMを使い果たさないようにすることです（すべてのMBをロードする必要があるため） クエリを実行すると、ドキュメントがRAMに読み込まれます。）
したがって、制限は、一般的なシステムで通常使用可能なRAMの数％です...これは年々増加し続けます。
MongoDBへのファイルの保存に関する注意
16MBより大きいドキュメント（またはファイル）を保存する必要がある場合 GridFS APIを使用すると、データが自動的にセグメントに分割され、ストリーミングされます（したがって、サイズ制限/ RAMの問題を回避できます）。
GridFSは、ファイルを1つのドキュメントに保存する代わりに、ファイルをパーツまたはチャンクに分割し、各チャンクを個別のドキュメントとして保存します。
GridFSは、2つのコレクションを使用してファイルを保存します。 1つのコレクションはファイルチャンクを格納し、もう1つのコレクションはファイルメタデータを格納します。
この方法を使用すると、SQLデータベースの場合と同じように、画像、ファイル、ビデオなどをデータベースに保存できます。これを使用して、数ギガバイトのビデオファイルを保存することもできます。