9 сентября 2010 в 18:28

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

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

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


Это ведь упрешься в лимит и труба…
1
FuN_ViT –1,8

сортировка по дате по рейтингу
ответы (7)

+2
VolCh, #
Для обхода ограничения есть GridFS, кажется :)
0
TravisBickle, #
Это настраивается.
0
miolini, #
Мне кажется проблема несколько надуманная, потому что комментарий к комментарию можно хранить плоско с foreign key. Для данных более 4мб есть GridFS.
0
MagaSoft, #
Это же сколько комментариев писать для 4 мб. Еще на 32 битных машинах общий объем базы ограничен 2 гб, раз начали.
GridFS все же для бинарников, не думаю что это лучшее решение.
В крайнем случае можно в приложении указать максимальный объем комментариев хранимых в одном документе и при достижении открывать новый с DBRef (foreign key) к основному.
VolCh, 9 сентября 2010 в 21:48
По-моему, логика приложения проще будет, если хранить в посте либо сами комменты, либо ссылку на гридфс, где эти комменты хранятся в сериализованном виде. Хотя всё зависит от задачи, если поиск по комментам нужен, то тут да, если не писать свой поиск, то либо продолжение текущего документа, либо хранить комменты в «нормализованном» виде в отдельной коллекции
MagaSoft, 10 сентября 2010 в 08:08
В варианте с отдельной колекцией на каждый запрос поста нужен второй запрос для комментов.
В варианте с продолжением нам надо а)каждый раз проверять достижение максимума, б)второй запрос при достижении, в)мы лишаемся атомарного добавления комментария, т.к. надо будет сначала запросить заново пост, проверить ограничение и потом уже добавлять. Этот шаг можно оптимизировать если в форму добавить сразу ObjectID поста или документа с продолжением комментариев, и мы сможем и атомарно добавлять их.
В общем, я не вижу проблемы в 4 мб, к тому же если грубо подсчитать что в комменты на русском в юникоде и ограничить их 1000 символов, это 2 кб на комментарий, и 2000 комментариев в посте. ИМХО в таких ситуациях их лучше разнести для удобства читателя в первую очередь.
+1
Masterkey, #
у монго есть другое более интересное ограничение www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

оно меня больше беспокоит чем 4мб на запись
vansickle, 9 сентября 2010 в 23:07
1) Для текстовых данных — 4MB — это очень много, все бинарные данные уйдут в GridFS
2) В версии 1.7 это возможно будет настраиваться
3) Если вы все же выйдете за пределы 4MB, то решается изменением структуры БД — для приведенного примера делаем коллекцию комментариев «плоской» со ссылками. Подробнее по вариантам работы с древовидными данными в Mongo см www.mongodb.org/display/DOCS/Trees+in+MongoDB
vansickle, 9 сентября 2010 в 23:07
прошу прощения, не туда
MagaSoft, 10 сентября 2010 в 07:53
>оно меня больше беспокоит чем 4мб на запись
Я так понимаю, вам каждый день приходится работать с базами данных с 24 тысячами таблиц в каждой. Верно?
Masterkey, 10 сентября 2010 в 14:38
неверно.
просто я не хочу менять паравоз на скрости света ;)
0
vansickle, #
1) Для текстовых данных — 4MB — это очень много, все бинарные данные уйдут в GridFS
2) В версии 1.7 это возможно будет настраиваться
3) Если вы все же выйдете за пределы 4MB, то решается изменением структуры БД — для приведенного примера делаем коллекцию комментариев «плоской» со ссылками. Подробнее по вариантам работы с древовидными данными в Mongo см www.mongodb.org/display/DOCS/Trees+in+MongoDB vansickle, Сегодня в 23:07
0
xSkyFoXx, #
В версии 2.2 размер одного документа увеличен до 16М. Хотя, как сказали многие вверху, GridFS позволит хранить файлы любых размеров. Даже таких, который превышают размер одного физического компьютера в кластере.

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

Про переводы
Дистрибутив Fedora Linux для Raspberry PI теперь…
Почему мы (всё ещё) верим в удалённую работу