了解MongoDB BSON文档尺寸限制

StackOverflow https://stackoverflow.com/questions/4667597

  •  10-10-2019
  •  | 
  •  

题

来自MongoDB的“权威指南：

大于4MB的文档（转换为BSON）不能保存到数据库。这是一个任意的限制（并且将来可能会提出）；这主要是为了防止错误模式设计并确保稳定的性能。

我不了解这个限制，这是否意味着包含许多评论的博客文章的文档，恰好大于4MB的文档无法存储为单个文档？

这也计算出嵌套的文档吗？

如果我想要一个文档来审核更改为一个值。 （最终可能会增长，超过4MB限制。）

希望有人正确解释这一点。

我刚刚开始阅读有关MongoDB（我正在学习的第一个NOSQL数据库）。

谢谢你。

有帮助吗？

解决方案

首先，这实际上是在下一版本中提出的 8MB 或者 16MB ...但是我认为要透视这一点，来自10Gen（开发MongoDB）的艾略特（Eliot）认为这是最好的：

编辑： 大小已经 正式 “长大”到 16MB

因此，在您的博客示例中，4MB实际上是很多。 http://www.gutenberg.org/etext/36

如果您的博客文章有那么多评论，那么我不会阅读它:)

对于回顾，如果您将1MB专用于它们，则可以轻松拥有超过10k（可能接近20k）

因此，除了真正奇怪的情况外，它将效果很好。而且，在例外情况或垃圾邮件中，我真的不认为您想要一个20MB的对象。我认为，无论表现如何，都可以将反射率限制为15k左右。或至少有特殊的套管。

-Eliot

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

极限的要点是，因此您不会用服务器上的所有RAM用光（因为您需要加载全部 MB查询文档的s进入RAM。）

因此，限制是普通系统上普通可用的RAM的百分比……这将使年度增长。

注意在MongoDB中存储文件

如果您需要存储大于大于的文档（或文件） 16MB 您可以使用 gridfs api 它将自动将数据分为细分市场并将其流式传输给您（因此避免了具有尺寸限制/RAM的问题。）

Gridfs没有将文件存储在单个文档中，而是将文件分为部分或块，并将每个块存储为单独的文档。

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

您可以像在SQL数据库中一样使用此方法将图像，文件，视频等存储在数据库中。我已经用它来存储多千兆视频的视频文件。

其他提示

社区中的许多人对绩效的警告毫不犹豫，请参阅此评论，以了解一个有理由的论点：https://jira.mongodb.org/browse/server-431?focusedCommentId=22283&page=com.atlassian.jira.jira.plugin.system.sissuetstem.issuetabpanels：Comment-tabpanel#comment-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。

sbudocuments和嵌套对象都计入文档的大小。

我尚未看到限制的问题，该限制不涉及文档本身中存储的大文件。已经有多种数据库在存储/检索大文件方面非常有效。它们被称为操作系统。数据库作为操作系统上的图层存在。如果出于性能原因，您使用NOSQL解决方案，为什么要通过将DB层放置在应用程序和数据之间的数据层来访问数据？

JSON是文本格式。因此，如果您要通过JSON访问数据，那么如果您有二进制文件，则尤其如此，因为必须在UUENCODE，HEXACIMAL或BASE 64中编码它们，因此转换路径可能看起来像是

二进制文件<> json（编码）<> bson（编码）

将路径（URL）放到文档中的数据文件并将数据本身保留在二进制文件中会更有效。

如果您真的想将这些长度不明的文件保留在数据库中，那么最好将这些文件放入GRIDF中，而不会冒险访问大文件时杀死您的并发状况。

BSON文件的嵌套深度：MongoDB为BSON文档提供了不超过100级的嵌套。

更多信息Vist

也许存储博客文章 - >评论 关系 在非关系中，数据库并不是真正的最佳设计。

无论如何，您可能应该将评论存储在单独的博客文章中。

编辑

请参阅下面的评论以进行进一步讨论。

根据 https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-part-1

如果您期望博客文章可能超过16MB文档限制，则应将评论提取到单独的集合中，并从评论中引用博客文章并进行应用程序级别的加入。

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top