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

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

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

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

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

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

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

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

Спасибо.

Ответ 1

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

EDIT: Размер официально 'поднят' до 16MB

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

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

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

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

-Eliot

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

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

Таким образом, предел - это некоторый процент нормальной полезной ОЗУ на общей системе..., которая будет расти с каждым годом.

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Больше информации vist

Ответ 5

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

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

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

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

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

Ответ 6

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

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

[править]

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