了解MongoDB BSON文档大小限制 [英] Understanding MongoDB BSON Document size limit

问题描述

来自MongoDB权威指南:

From MongoDB The Definitive Guide:

大于4MB的文档(转换为BSON时)不能 保存到数据库.这是一个任意限制(可能是 将来提出)；这主要是为了防止不良的架构设计并确保 一致的性能.

Documents larger than 4MB (when converted to BSON) cannot be saved to the database. This is a somewhat arbitrary limit (and may be raised in the future); it is mostly to prevent bad schema design and ensure consistent performance.

我不了解这个限制，这是否意味着包含博客文章且带有大量评论且恰好大于4MB的文档不能存储为单个文档?

I don't understand this limit, does this mean that A Document containing a Blog post with a lot of comments which just so happens to be larger than 4MB cannot be stored as a single document?

这也算嵌套文档吗?

如果我想要一个审核值更改的文档该怎么办. (它最终可能会增长，超过4MB的限制.)

What if I wanted a document which audits the changes to a value. (It will eventually may grow, exceeding 4MB limit.)

希望有人能正确解释这一点.

Hope someone explains this correctly.

我刚刚开始阅读有关MongoDB(我正在学习的第一个nosql数据库)的信息.

I have just started reading about MongoDB (first nosql database I'm learning about).

谢谢.

推荐答案

首先，实际上是在下一个版本中将其提升到8MB或16MB的问题……但我想将它放在一个角度，艾略特(Eliot) 10gen(开发了MongoDB的人)最擅长:

First off, this actually is being raised in the next version to 8MB or 16MB ... but I think to put this into perspective, Eliot from 10gen (who developed MongoDB) puts it best:

编辑:该大小已正式> 提升"到16MB

The size has been officially 'raised' to 16MB

因此，在您的博客示例中，4MB是 实际上很多.例如， 完整解压缩"War of 世界"仅为36.4万(html): http://www.gutenberg.org/etext/36

So, on your blog example, 4MB is actually a whole lot.. For example, the full uncompresses text of "War of the Worlds" is only 364k (html): http://www.gutenberg.org/etext/36

如果您的博客文章与 这么多评论，我不是一个 将要阅读:)

If your blog post is that long with that many comments, I for one am not going to read it :)

对于引用，如果您专用1MB 对他们来说，您可以轻松拥有更多 超过10k(可能接近20k)

For trackbacks, if you dedicated 1MB to them, you could easily have more than 10k (probably closer to 20k)

所以除了真正的怪异 情况下，它会很好用.而在 例外情况或垃圾邮件，我真的 不要以为你想要20mb的物体 反正.我认为将引用限制为 15k左右很有意义 表现如何无关紧要.或 最少的特殊外壳(如果有) 发生.

So except for truly bizarre situations, it'll work great. And in the exception case or spam, I really don't think you'd want a 20mb object anyway. I think capping trackbacks as 15k or so makes a lot of sense no matter what for performance. Or at least special casing if it ever happens.

-艾略特

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

I think you'd be pretty hard pressed to reach the limit ... and over time, if you upgrade ... you'll have to worry less and less.

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

The main point of the limit is so you don't use up all the RAM on your server (as you need to load all MBs of the document into RAM when you query it.)

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

So the limit is some % of normal usable RAM on a common system ... which will keep growing year on year.

有关在MongoDB中存储文件的说明

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

If you need to store documents (or files) larger than 16MB you can use the GridFS API which will automatically break up the data into segments and stream them back to you (thus avoiding the issue with size limits/RAM.)

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

Instead of storing a file in a single document, GridFS divides the file into parts, or chunks, and stores each chunk as a separate document.

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

GridFS uses two collections to store files. One collection stores the file chunks, and the other stores file metadata.

您可以使用此方法在数据库中存储图像，文件，视频等，就像在SQL数据库中一样.我甚至用它来存储多GB的视频文件.

You can use this method to store images, files, videos, etc in the database much as you might in a SQL database. I have used this to even store multi gigabyte video files.

这篇关于了解MongoDB BSON文档大小限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！