了解MongoDB BSON文档大小限制
来自MongoDB权威指南：
大于4MB的文档（转换为BSON时）不能保存到数据库。 这是一个有些武断的限制（将来可能会提高）。 主要是防止糟糕的模式devise并确保性能一致。
我不明白这个限制，这是否意味着一个文档包含一个很多大于4MB的注释的博客post不能被存储为单个文档？
这也算嵌套的文件吗？
如果我想要一个文件来审核价值的变化呢？ （它最终会增长，超过4MB的限制。）
希望有人解释正确。
我刚开始阅读关于MongoDB（我正在学习的第一个nosql数据库）。
谢谢。
首先，这实际上是在下一个版本中提高到8MB或16MB …但我认为从这个angular度来看，来自10gen（谁开发MongoDB）的艾略特说得最好：
编辑： 大小已经正式 “提出”到16MB
所以，在你的博客例子中，4MB实际上是一大堆。例如，“世界大战”的完整解压文本只有364k（html）： http : //www.gutenberg.org/etext/36
如果你的博客文章有这么多评论，那么我就不会阅读它了:)
对于引用，如果你给他们专用的1MB，你可以很容易超过10k（可能接近20k）
所以除了真正的离奇情况，它会很好的工作。 而在例外情况或垃圾邮件，我真的不认为你会想要一个20MB的对象无论如何。 我认为，将引用限制在15K左右，无论性能如何，都有很大的意义。 或者至less是特别的套pipe，如果它发生的话。
-Eliot
我认为你很难达到极限……随着时间的推移，如果你升级…你将不得不担心越来越less。
限制的要点是，你不要用尽服务器上的所有RAM（因为当你查询它时，你需要将所有的MB文件加载到RAM中）。
所以这个限制是普通系统上正常可用内存的一些百分比，这个数目将会持续增长。
关于在MongoDB中存储文件的注意事项
如果您需要存储大于16MB文档（或文件），则可以使用GridFS API ，该API将自动将数据分成多个段并将其stream式传回给您（从而避免了大小限制/ RAM的问题）。
GridFS不是将文件存储在单个文档中，而是将文件分成多个部分或块，并将每个块存储为单独的文档。
GridFS使用两个集合来存储文件。 一个集合存储文件块，另一个存储文件元数据。
您可以使用此方法将图像，文件，video等存储在数据库中，就像在SQL数据库中一样。 我用这个甚至存储了多GB的video文件。
社区中的许多人不希望对性能产生任何限制，请参阅此评论以获得一个合理的论点： https : //jira.mongodb.org/browse/SERVER-431? focusedCommentId = 22283 & page =com.atlassian.jira.plugin。 system.issuetabpanels：评论，一个tabpanel＃评论- 22283
我认为，领先的开发者对这个问题是固执的，因为他们认为这是早期的重要“特征”。 他们不会很快改变它，因为任何人都会质疑他们的感受。 另一个性格和政治背离开源社区产品的例子，但这不是一个真正的残酷问题。
在这里为那些被Google定向的人发布一个澄清的答案。
文档大小包括文档中的所有内容，包括子文档，嵌套对象等
所以一个文件：
{ _id:{}, na: [1,2,3], naa: [ {w:1,v:2,b:[1,2,3]}, {w:5,b:2,h:[{d:5,g:7},{}]} ] }
最大尺寸为16meg。
废票和嵌套的对象都计算在文档的大小上。
BSON文档的嵌套深度： MongoDB支持不超过100层的BSON文档嵌套。
更多信息vist
我还没有看到没有涉及到文件本身存储的大文件的限制的问题。 已经有很多数据库在存储/检索大文件方面非常高效， 他们被称为操作系统。 数据库作为操作系统上的一层存在。 如果出于性能方面的原因使用NoSQL解决scheme，为什么要通过在应用程序和数据之间放置数据库层来为数据的访问添加额外的处理开销？
JSON是一种文本格式。 因此，如果您通过JSON访问数据，那么尤其是如果您有二进制文件，因为它们必须用uuencode，hex或Base 64编码。转换path可能看起来像
二进制文件<> JSON（编码）<> BSON（编码）
将path（URL）放到文档中的数据文件并将数据本身保存为二进制文件会更有效。
如果你真的想在数据库中保留这些长度未知的文件，那么你最好把它们放到GridFS中，而不要冒着在访问大文件的时候遇到并发的风险。
也许在非关系数据库中存储博客post – >评论关系并不是最好的devise。
无论如何，您应该将注释存储在一个单独的集合中。
[编辑]
请参阅下面的评论进一步讨论。
