@Gates VP, я согласен на использование отдельного полнотекстового движка. Я думал о поиске метаданных. Что, если у вас есть набор Книжных документов, и вы хотите найти все книги, изданные в 1982 году? Если каждая книга содержит + 100 КБ текста, вы не хотите передавать несколько мегабайт только для отображения первых 20 названий книг.

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

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

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

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

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

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

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

Спасибо.

 saint12 янв. 2011 г., 15:48
@alexpopescu, ты прав.
 alexpopescu12 янв. 2011 г., 15:03
Я думаю, что вопрос должен прояснить, что это ограничение размеров хранимых документов MongoDB, а не формата BSON.
 Nik So24 февр. 2011 г., 20:21
Хотя я только что попытался сохранить огромный документ, который наверняка превышает 4 МБ, чтобы получить сообщение «BSON :: InvalidDocument: слишком большой документ: документы BSON ограничены 4194304 байтами». Если это так, разве это не вводит в заблуждение в предупреждении / сообщении об ошибке?
 Rizwan Patel19 авг. 2016 г., 13:17
Какова цель nosql без схемы, где вы не можете создавать дампы больше чем 16 мегабайт и строить на нем операции crud!
 AhmetB - Google28 окт. 2011 г., 18:39
Вы можете легко найти ваш максимальный размер документа BSON сdb.isMaster().maxBsonObjectSize/(1024*1024)+' MB' командовать вmongo ракушка.

Ответы на вопрос(6)

связь в нереляционной базе данных не самый лучший дизайн.

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

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

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

 Matt Briggs12 янв. 2011 г., 15:51
@Mchel: «блог» - это нехорошо, но хранить комментарии в отдельной коллекции так же плохо по тем же причинам. Сообщения с массивом комментариев, как, канонический пример документа БД.
 Mchl12 янв. 2011 г., 11:44
Возможно, я был слишком строг в своем ответе. Нет ничего плохого в хранении постов в блоге и связанных комментариев в MongoDB или аналогичной базе данных. Более того, люди склонны злоупотреблять возможностями баз данных на основе документов (наиболее радикальный пример - хранить все ваши данные в одном документе под названием «блог»).
 Justin Jenkins12 янв. 2011 г., 11:34
Я совсем не согласен. Комментарии в ваших публикациях в блоге должны быть в порядке в MongoDB ... это очень распространенное использование (я использую его более чем в одном месте, и оно работает довольно хорошо).
 mikerobi07 июн. 2011 г., 18:43
@Gates VP, я согласен на использование отдельного полнотекстового движка. Я думал о поиске метаданных. Что, если у вас есть набор Книжных документов, и вы хотите найти все книги, изданные в 1982 году? Если каждая книга содержит + 100 КБ текста, вы не хотите передавать несколько мегабайт только для отображения первых 20 названий книг.
 Gates VP13 янв. 2011 г., 00:21
@SoPeople: хранение комментариев внутри поста похоже на канонический пример документно-ориентированных баз данных. (как хранение всего текста вики внутри одного документа) Если бы я написал SO, он бы полностью работал на MongoDB. Ни одна из этих записей SO не собираетсяразумно превышать 4 МБ. Craigslist делает гигантскую миграцию БД своей истории в MongoDB. У них было только несколько документов, превышающих этот лимит, и ведущий разработчик предположил, что сами документы действительно были повреждены (результат некоторых ошибок). Опять же 4 мег это несколько романов текста.

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

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

 Sharjeel Ahmed15 февр. 2016 г., 09:43
Я полностью согласен с вами, так как теперь это противоречит цели встраивания документов, так как большинство встроенных документов теперь легко пересекают границы. Esp с массивом документов внутри них
 Mafii27 апр. 2016 г., 09:11
@ marr75 сейчас написано исправлено, исправлено?
 marr7502 июн. 2016 г., 20:56
Я имею в виду, предел был увеличен до 16 МБ, что не решает проблему в долгосрочной перспективе; ИМО предел должен быть просто устранен.
 marr7524 мая 2018 г., 20:46
6 лет нить некро. Я совершенно не убежден в вашем конкретном неудачном примере использования / примере дизайна. Кроме того, этот пример гораздо лучше иллюстрирует необходимость проверки входных данных, чем ограничение размера одного документа в базе данных. Заставить приложение разделить вложенные документы как отдельные документы в другой коллекции или запустить новый документ «продолжение» (решения, которые я использовал несколько раз для работы в рамках этого лимита) оказало небольшое влияние на производительность, но сильно повлияло на сложность кода. Весь смысл БД документов - локальность данных.

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

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

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

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

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

 redcalx13 июл. 2015 г., 14:01
«Уже существует множество баз данных, которые очень эффективны для хранения / извлечения больших файлов; они называются операционными системами.»; Видетьblog.mongodb.org/post/183689081/...

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

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

кто направляется сюда от 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мг.

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

Решение Вопроса

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

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

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

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

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

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

-Eliot

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

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

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

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

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

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

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

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

 schmidlop22 сент. 2016 г., 16:51
@savvas, почему бы тебе поместить все твиты в один документ? Используйте один документ на твит, добавьте тему обсуждения в качестве другого поля в документе. поместите индекс в это поле темы и затем агрегируйте в этом поле, используя конвейер Монго. чтобы настроить nosql, нужно внести некоторые коррективы в то, как вы настроите свои методы и решите, что он отлично работает для многих случаев использования больших данных.
 Robert Christ28 авг. 2014 г., 19:21
милый Иисус, так что аргумент Монго таков: "16 МБ должно быть достаточно для всех"? Это не похоже на то, что когда-либо было неверным в прошлом.
 Savvas24 янв. 2016 г., 13:47
Это кажется слишком плохим для меня. Mongo должен быть полезен для больших данных, не иметь таких ограничений. В моем проекте мне нужно объединить и сгруппировать твиты, связанные с одной и той же тенденцией, и это может закончиться более чем 20000 твитами за период времени в 20 часов (и вполне возможно, что тренды будут длиться дольше, чем 20 часов в моем БД). Наличие такого большого количества твитов и одновременного хранения их текста является разрушительным, и после группировки нескольких небольших трендов это заканчивается исключением большого тренда.
 Justin Jenkins12 дек. 2011 г., 07:46
Удивительно, что у вас достаточно ОЗУ для всей вашей базы данных ... Обычно «рабочий набор» находится в ОЗУ, а не во всей базе данных (как в моем случае, у меня более одной базы данных по x ГБ, где, если все сложение будет превышать мою ОЗУ, но это нормально, потому что рабочий набор намного, намного меньше.) Кроме того, если бы не было предела, вы могли бы загрузить документ объемом 800 МБ в ОЗУ с одним запросом и документ объемом 400 КБ с другим, что немного затруднило бы балансировку ОЗУ и т. д. Таким образом, «предел» составляет несколько% от типичной оперативной памяти сервера (таким образом, она увеличивается со временем.)mongodb.org/display/DOCS/Checking+Server+Memory+Usage
 AlexGad24 дек. 2011 г., 17:52
Здорово, что вы можете хранить все в оперативной памяти, но учитывайте эффективность и идиому в блоге. Вы, очевидно, хотите, чтобы сообщение было в памяти, если оно прочитано. Но действительно ли вы хотите, чтобы 10 страниц комментариев для поста блога оставались в памяти, когда большинство людей никогда не будут читать мимо первой страницы? Конечно, вы можете сделать это, и если ваша база данных достаточно мала, чтобы она могла вместиться в память, тогда проблем нет. Но с точки зрения чистой эффективности, вы не хотите, чтобы бесполезные биты занимали место в памяти, если вы можете этого избежать (и это касается и RDBMS).

Ваш ответ на вопрос