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

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

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

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

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

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

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

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

Спасибо.

6 Solutions collect form web for “Понимание ограничений размера документа MongoDB BSON”

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

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

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

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

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

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

-Eliot

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

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

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

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

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

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

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

Вы можете использовать этот метод для хранения изображений, файлов, видео и т. Д. В базе данных так же, как и в базе данных 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 мг.

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

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

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

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

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

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

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

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

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

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

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

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

  • MongoDB: вспомогательный субподряд
  • $ искать несколько уровней без $ unwind?
  • Как автоматически перезапустить MySQL и MongoDB, когда они не реагируют?
  • $ lookup для ObjectId's в массиве
  • Как обойти отсутствие транзакций в MongoDB?
  • Автоматически сокращать удаленное пространство в mongodb?
  • Могут ли mongo обновить данные массива?
  • MongoDB reverse regex
  • Разница между count () и find (). Count () в MongoDB
  • Возвращать только согласованные элементы субдокумента внутри вложенного массива
  • Запрос после заполнения в Mongoose
  • Давайте будем гением компьютера.