16 мегабайт данных для одного агрегата сущностей это... довольно много. Если у вас выходит больше - вполне вероятно что что-то пошло не так и вам нужно разделить это дело (на несколько агрегатов в разных коллекциях, никаких связей). Возможно у вас там графы хранятся, или то что хранится как поддокументы на самом деле самостоятельная коллекция агрегатов. Словом вариантов много, но все же бывают случаи когда "не влазит".
В целом есть варианты с GridFS (разбить жирный документ на маленькие куски) но это скорее кастыль и с ним могут быть проблемы.
Ну и опять же, свет клином на монге не сошелся. Есть и другие документно-ориентированные базы данных. Просто они все намного более специфичны. Монга больше тянет на базу общего назначения.
iGarett: а никто и не говорит что все это легко. Это легко когда поработаешь с этим пару лет.
В целом можете попытаться разобраться с таким термином как "агрегат сущностей" и "корень агрегата сущностей", принимая что в одной коллекции должен лежать агрегаты сущностей с явно выделяемым корнем вверху. Вот в нашем примере аргегат сущностей это категория и картинки относящиеся к ней. Корень - категория. Соответственно у нас одна коллекция категорий, каждая из которых хранит массив картинок.
Ну и обязательно почитать что такое нормализация и денормализация. Чем сущности от объектов-значений отличаются и т.д.
gog69: профит в том что мы не раздуваем контроллер. Допустим у нас был просто бложик и мы решили комментарии добавить. Причем мы еще не знаем будем ли мы оставлять нашу реализацию или водключим потом какой discuss. так мы изолируем это в отдельном экшене отдельного контроллера и следовательно изолируем изменения связанные с выводом комментариев в будущем.
Делать это или нет - это вам решать. Для таких простых задач это не столь критично.
gog69: вопервых шаблонизатор - это часть слоя контроллера. Контроллер активен а вьюшки пассивны (по сути Request и Response - это View в нашем случае). Следовательно делать "подзапросы" в шаблонах вполне себе можно.
- больше времени на разработку
- дороже поддержка.
- больше возможностей накосячить
- мнимый контроль (разработка на отдельных компонентах дает больше контроля на самом деле).
Вывод, в 2016-ом для бизнеса CI не эффективный инструмент. А для себя можно использовать что угодно.
> Бинарная сериализация не даст выигрыша, если это не нативный формат данных в памяти v8 или другого движка.
Я что-то подозреваю что все же накладные расходы на это все добро не меньше обычного парсинга JSON. Но нужны бенчмарки. В целом идея интересная и я как-нибудь попробую.
foundationick: что тут подробнее? Очереди. Добавляем в одном процессе задачу в очередь, в другом обрабатываем задачи. Из списка что я привел все умеют "сохранять" очередь на диске.
chupasaurus: лучше концентрироваться на чем-то одном. Скажем пару лет пофронтэндить а когда станет скучно подключать бэкэнд. Ну и опять же что бы запилить апишку при нормальном знании js много ума не требуется.
