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

Из MongoDB Окончательное Руководство:

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

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

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

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

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

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

спасибо.

127
bson mongodb

6 ответов

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

EDIT: размер официально "довела" до 16MB

Итак, на вашем примере блога 4MB на самом деле много.. Например, полный распаковывает текст " войны миры" - это только 364k (HTML-код): http://www.gutenberg.org/etext/36

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

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

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

-Элиот

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

основной момент ограничения-это то, что вы не используете всю ОЗУ на своем сервере (так как вам нужно загрузить все MBs документа в ОЗУ, когда вы запроса.)

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

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

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

вместо того, чтобы хранить файл в одном документе, GridFS делит файл на части или куски и сохраняет каждый кусок как отдельный документ.

GridFS использует две коллекции для хранения файлов. В одной коллекции хранятся фрагменты файлов, а в другой-метаданные файлов.

вы можете использовать этот метод для хранения изображений, файлов, видео и т. д. В базе данных так же, как в базе данных SQL. Я использовал это даже для хранения видео файлов с несколькими гигабайтами.

110

многие в сообществе предпочли бы без ограничений с предупреждениями о производительности, см. Этот комментарий для аргументированного аргумента: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22283

мой взгляд, ведущие разработчики упрямы в этой проблеме, потому что они решили, что это важная "функция" на раннем этапе. Они не собираются менять его в ближайшее время, потому что их обидно, что кто-то усомнился в этом. Еще один пример того, как личность и политика умаляют продукт в сообществах с открытым исходным кодом, но на самом деле это не проблема.

26

чтобы опубликовать ответ на уточнение здесь для тех, кто направляется сюда 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 и вложенные объекты подсчитываются по размеру документа.

21

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

больше информации вист

4

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

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

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

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

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

3

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

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

[edit]

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

2