Понимание MongoDB BSON Ограничение размера документа

От MongoDB Полное руководство:

Документы размером более 4 МБ (при преобразовании в BSON) не могут быть сохранены в базе данных. Это несколько произвольный предел (и может быть повышен в будущем); это в основном для предотвращения неправильного проектирования схемы и обеспечения стабильной производительности.

Я не понимаю этого ограничения. Означает ли это, что документ, содержащий сообщение в блоге с большим количеством комментариев размером более 4 МБ, не может быть сохранен как один документ?

Также учитывает ли это вложенные документы?

Что делать, если я хотел документ, который проверяет изменения стоимости. (В конечном итоге он может возрасти, превысив предел 4 МБ.)

Надеюсь, кто-то объясняет это правильно.

Я только начал читать о MongoDB (первая база данных nosql, о которой я узнаю).

Спасибо.

Во-первых, это на самом деле поднимается в следующей версии 8MBили 16MB... но я думаю, чтобы представить это в перспективе, Элиот из 10gen (который разработал MongoDB) считает это лучше:

РЕДАКТИРОВАТЬ: размер был официально "поднят" до16MB

Итак, в вашем примере с блогом, 4MB на самом деле очень много. Например, полный несжатый текст «Войны миров» составляет всего 364k (html): http://www.gutenberg.org/etext/36

Если ваш блог так долго с таким количеством комментариев, я, например, не буду его читать :)

Для трекбэков, если вы выделите им 1 МБ, вы можете легко получить более 10 КБ (возможно, ближе к 20 КБ).

Так что за исключением действительно странных ситуаций, это будет прекрасно работать. И в случае исключения или спама, я действительно не думаю, что вы все равно хотите объект 20 МБ. Я считаю, что ограничение трекбэков как 15k или около того имеет большой смысл независимо от производительности. Или, по крайней мере, специальный корпус, если это когда-нибудь случится.

-Eliot

Я думаю, что вам будет довольно трудно достичь предела ... и со временем, если вы обновитесь ... вам придется беспокоиться все меньше и меньше.

Суть ограничения заключается в том, что вы не используете всю оперативную память на своем сервере (так как вам нужно загрузить все MBдокументы в оперативную память при запросе).

Таким образом, ограничение составляет несколько% от нормальной используемой оперативной памяти в общей системе ... которая будет расти из года в год.

Замечание о хранении файлов в MongoDB

Если вам нужно хранить документы (или файлы) больше, чем 16MBвы можете использовать GridFS API, который автоматически разбивает данные на сегменты и направляет их обратно вам (таким образом, избегая проблемы с ограничениями размера / оперативной памяти.)

Вместо того, чтобы хранить файл в одном документе, 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},{}]}
    ]
}

Максимальный размер 16мг.

Вложенные документы и вложенные объекты учитываются по размеру документа.

Я еще не видел проблемы с лимитом, который не затрагивал большие файлы, хранящиеся в самом документе. Уже существует множество баз данных, которые очень эффективны для хранения / извлечения больших файлов; они называются операционными системами. База данных существует как слой над операционной системой. Если вы используете решение NoSQL по соображениям производительности, почему вы хотите добавить дополнительные издержки обработки к доступу к вашим данным, поместив слой БД между вашим приложением и вашими данными?

JSON - это текстовый формат. Итак, если вы обращаетесь к своим данным через JSON, это особенно верно, если у вас есть двоичные файлы, потому что они должны быть закодированы в uuencode, шестнадцатеричном или Base 64. Путь преобразования может выглядеть следующим образом

двоичный файл <> JSON (кодированный) <> BSON (кодированный)

Было бы эффективнее поместить путь (URL) к файлу данных в вашем документе и сохранить сами данные в двоичном виде.

Если вы действительно хотите сохранить эти файлы неизвестной длины в вашей БД, то вам, вероятно, лучше поместить их в GridFS и не рисковать уничтожением параллелизма при обращении к большим файлам.

Вложенная глубина для документов BSON: MongoDB поддерживает не более 100 уровней вложенности для документов BSON.

Более подробная информация Вист

Возможно хранение в блоге -> комментарии отношение в не реляционную базу данных на самом деле не лучший дизайн.

Вероятно, вы все равно должны хранить комментарии в отдельной коллекции к сообщениям в блоге.

[редактировать]

Смотрите комментарии ниже для дальнейшего обсуждения.

Согласно https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Если вы ожидаете, что запись в блоге может превышать ограничение в 16 МБ, вы должны извлечь комментарии в отдельную коллекцию, сослаться на запись блога из комментария и выполнить соединение на уровне приложения.

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

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]