首先，它实际上是在8MB或16MB... 的下一个版本中提出的，但是我认为，从10gen(开发MongoDB的人)的艾略特(Eliot)的观点来看，它是最好的：

编辑： 大小已正式 “提高”到16MB

因此，在您的博客示例中，4MB实际上是很多。例如，“世界大战”的全部未压缩文本仅为364k(html)：http : //www.gutenberg.org/etext/36

如果您的博客文章有那么多评论那么长，我将一本不读:)

对于引用，如果您为它们分配了1MB的空间，则很容易会超过10k(可能接近20k)

因此，除了真正奇怪的情况外，它都将很好地工作。而且在例外情况或垃圾邮件中，我真的不认为您还是想要20mb的对象。我认为将引用限制在15k左右是很有意义的，无论性能如何。或至少发生特殊情况(如果有的话)。

-艾略特

我认为您很难达到极限...随着时间的流逝，如果升级...您将越来越不必担心。

限制的主要目的是使您不会用完服务器上的所有RAM(因为MB查询文档时需要将所有文档加载到RAM中。)

因此，限制是普通系统上正常可用RAM的一定百分比……这将保持逐年增长的趋势。

在MongoDB中存储文件的注意事项

如果您需要存储的文档(或文件)大于16MB您可以使用的GridFS API，它将自动将数据分解成段并将其流式传输回给您(从而避免了大小限制/ RAM的问题)。

GridFS不会将文件存储在单个文档中，而是将文件分为多个部分或大块，并将每个大块作为单独的文档存储。

GridFS使用两个集合来存储文件。一个集合存储文件块，另一个集合存储文件元数据。

您可以使用此方法在数据库中存储图像，文件，视频等，就像在SQL数据库中一样。我用它甚至存储了数千兆字节的视频文件。