Прочитал, что MongoDB имеет ограничение в 4Мб на документ. Я не ошибся?

Question

[Виталий Ф.]

Особенно не понятно, если рекомендуется де-нормализовать данные — например, хранить комментарии к комментарию…

comment:{Id:..., Text: ..., comments: []}


Это ведь упрешься в лимит и труба…

Answer 1

[xSkyFoXx]

В версии 2.2 размер одного документа увеличен до 16М. Хотя, как сказали многие вверху, GridFS позволит хранить файлы любых размеров. Даже таких, который превышают размер одного физического компьютера в кластере.

Answer 2

[Владимир Чернышев]

Для обхода ограничения есть GridFS, кажется :)

Answer 3

[Masterkey]

у монго есть другое более интересное ограничение www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

оно меня больше беспокоит чем 4мб на запись

Comments

[vansickle]

1) Для текстовых данных — 4MB — это очень много, все бинарные данные уйдут в GridFS
2) В версии 1.7 это возможно будет настраиваться
3) Если вы все же выйдете за пределы 4MB, то решается изменением структуры БД — для приведенного примера делаем коллекцию комментариев «плоской» со ссылками. Подробнее по вариантам работы с древовидными данными в Mongo см www.mongodb.org/display/DOCS/Trees+in+MongoDB

[vansickle]

прошу прощения, не туда

[MagaSoft]

>оно меня больше беспокоит чем 4мб на запись
Я так понимаю, вам каждый день приходится работать с базами данных с 24 тысячами таблиц в каждой. Верно?

[Masterkey]

неверно.
просто я не хочу менять паравоз на скрости света ;)

Answer 4

[TravisBickle]

Это настраивается.

Answer 5

[miolini]

Мне кажется проблема несколько надуманная, потому что комментарий к комментарию можно хранить плоско с foreign key. Для данных более 4мб есть GridFS.

Answer 6

[MagaSoft]

Это же сколько комментариев писать для 4 мб. Еще на 32 битных машинах общий объем базы ограничен 2 гб, раз начали.
GridFS все же для бинарников, не думаю что это лучшее решение.
В крайнем случае можно в приложении указать максимальный объем комментариев хранимых в одном документе и при достижении открывать новый с DBRef (foreign key) к основному.

Comments

[Владимир Чернышев]

По-моему, логика приложения проще будет, если хранить в посте либо сами комменты, либо ссылку на гридфс, где эти комменты хранятся в сериализованном виде. Хотя всё зависит от задачи, если поиск по комментам нужен, то тут да, если не писать свой поиск, то либо продолжение текущего документа, либо хранить комменты в «нормализованном» виде в отдельной коллекции

[MagaSoft]

В варианте с отдельной колекцией на каждый запрос поста нужен второй запрос для комментов.
В варианте с продолжением нам надо а)каждый раз проверять достижение максимума, б)второй запрос при достижении, в)мы лишаемся атомарного добавления комментария, т.к. надо будет сначала запросить заново пост, проверить ограничение и потом уже добавлять. Этот шаг можно оптимизировать если в форму добавить сразу ObjectID поста или документа с продолжением комментариев, и мы сможем и атомарно добавлять их.
В общем, я не вижу проблемы в 4 мб, к тому же если грубо подсчитать что в комменты на русском в юникоде и ограничить их 1000 символов, это 2 кб на комментарий, и 2000 комментариев в посте. ИМХО в таких ситуациях их лучше разнести для удобства читателя в первую очередь.

Answer 7

[vansickle]

1) Для текстовых данных — 4MB — это очень много, все бинарные данные уйдут в GridFS
2) В версии 1.7 это возможно будет настраиваться
3) Если вы все же выйдете за пределы 4MB, то решается изменением структуры БД — для приведенного примера делаем коллекцию комментариев «плоской» со ссылками. Подробнее по вариантам работы с древовидными данными в Mongo см www.mongodb.org/display/DOCS/Trees+in+MongoDB vansickle, Сегодня в 23:07