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