了解MongoDB BSON文档大小限制
来自MongoDB权威指南：
大于4MB的文档（转换为BSON时）不能保存到数据库。 这是一个有些武断的限制（将来可能会提出）; 主要是为了防止糟糕的模式设计并确保一致的性能。
我不明白这个限制，这是否意味着一个包含博客帖子的文档只有大于4MB的注释才能被存储为单个文档？
这是否也计算嵌套的文件呢？
如果我想要一个审核价值变化的文档，该怎么办？ （它最终会增长，超过4MB的限制。）
希望有人解释正确。
我刚开始阅读关于MongoDB（我正在学习的第一个nosql数据库）。
谢谢。
首先，这实际上是在下一个版本中提高到8MB或16MB ......但我认为从这个角度来看，来自10gen（谁开发MongoDB）的艾略特说得最好：
编辑：大小已正式'提出'到16MB
因此，在您的博客示例中，4MB实际上是一大堆。例如，“World of the Worlds”的完整解压缩文本仅为364k（html）：http://www.gutenberg.org/etext/36
如果你的博客文章有那么长的评论，我就不会读它了:)
对于trackbacks，如果你为它们专用了1MB，你可以轻松地拥有超过10k（可能接近20k）
所以除了真正奇怪的情况，它会很好。 而在例外情况或垃圾邮件中，我真的不认为你会想要一个20MB的对象。 无论性能如何，我认为将引用限制在15K左右非常有意义。 或者至少特殊的外壳，如果它发生。
-Eliot
我认为你很难达到极限......随着时间的推移，如果升级......你将不得不担心越来越少。
限制的要点是，您不要用完服务器上的所有RAM（因为在查询时需要将文档的所有MB都加载到RAM中）。
所以这个限制是普通系统上正常可用内存的百分之一......这将会保持同比增长。
关于在MongoDB中存储文件的注意事项
如果您需要存储大于16MB文档（或文件），则可以使用GridFS API，它将自动将数据分解为多个段并将它们流式传输回给您（从而避免了大小限制/ RAM的问题）。
GridFS不是将文件存储在单个文档中，而是将文件分成多个部分或块，并将每个块存储为单独的文档。
GridFS使用两个集合来存储文件。 一个集合存储文件块，另一个存储文件元数据。
您可以使用此方法将图像，文件，视频等存储在数据库中，就像在SQL数据库中一样。 我用它甚至可以存储多个千兆字节的视频文件。
社区中的许多人不希望对性能发出警告的限制，请参阅此评论以获得理由充分的论据：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。
违规和嵌套对象都是按文档大小计算的。
链接地址: http://www.djcxy.com/p/86367.html