Старт проекта на NodeJS+MongoDB или PHP+MySQL?

Question

[livetick2]

Всем привет. Собственно нужен совет, кто уже хорошо знаком с технологиями NodeJS+MongoDB.

Есть проект - сайт афиш, событий. Он не комбайн, не слишком сложный, по сути только профиль, главная(список афиш), и страница с афишой, где выводится время, описание и авторские блоки(текст, опрос, галерея, стена с комментариями).

Есть большой соблазн не мучиться с нормализацией mysql баз данных(куча join для сборки блоков и афиши ), и попробовать реализовать это все на Монго. Тогда документ данных к афише будет одним объектом со свойствами(время, описание, автор и т.д.), с подмножествами (блоки -> тип блока -> уникальный набор свойств), выбирается все одним запросом.

В блоке "стена" хочу сделать реалтайм-комменты. В общем, поэтому NodeJS+MongoDB. Главный совет по производительности. Стоит овчинка выделки? Я поверхностно знаком с этими технологиями, но курсов правда до хрена. Часто слышал про неконтролируемые утечки памяти у Ноды. Или не морочить себе голову, да начать с PHP+MySQL...

Сервер для старта выбрал не дорогой, за 13 долларов, 3 ядра Intel Xeon, 8 гиг. памяти, 48 гигов SSD.

Comments

[Виталий Першин]

NodeJS+MySQL

[Sanes]

А с сортировкой, фильтрацией проблем не будет на Монго?

[livetick2]

Sanes, у меня поиск только по описанию/заголовку и дате отсчета/создания, естественно индексы. И все. Фильтров нет. Только сортировка по дате убыв./возр., и популярности. Но это уже не в базе сортируется, а в результирующем массиве.

Answer 1

[d-sem]

Если не мучаться с нормализацией данных на входе как в реляционных базах данных, то придется мучаться с ней на выходе. Обратная сторона удобства.

В целом, итоговая производительность будет больше зависеть больше зависит от качества конкретной реализации, нежели от конкретного стека. У каждого есть куча ньюансов, которые могут создать проблем. Из них низкая сферическая производительность PHP + MySQL на старте - далеко не самая большая проблема.

Лучше не заниматься преждевременной оптимизацией. Сделать прототип на том стеке, что лучше известен. Уточнить требования и уже дальше решить - стоит оптимизировать или нет. А еще лучше сделать два прототипа и решить, что лучше на практическом сравнении. Практическое же сравнение делать на основании тестов из сформированных требований.

Comments

[livetick2]

Спасибо, быстро тут отвечают!) В том то и дело, что сайт не сложный, перекрестных данных не много, по сути, весь трафик должен идти на конкретную страницу с афишей. Денормализацию можно и в MySQL сделать... но в Монго можно сразу вытащить все одним запросом. Единственное, там лимиты на документ, вроде 16 метров, хотя комментов вряд ли столько наберется на один документ...

Просто не хочется начать на одном (PHP+MySQL), а потом лихорадочно переходить на NodeJS+MongoDB, тем более импорт/экспорт данных - будет тот еще квест.

[Михаил]

livetick2, не силён в бд, но говорят что лучше postgres вместо mysql, а в монго проблема с миграциями была (хз осталась ли)

В любом случае php/node всё равно, они заменяемы

[d-sem]

Если не сложный, то тем более надо попробовать оба пути)

Конкретный путь зависит от конкретных скиллов разработчика. Если с нодой и монгой раньше не работали, то может много времени уйти на дебаг и обеспечение стабильной работы.

А с той же PHP и Laravel вполне себе можно довольно шустро быстро и качественно сделать сайт, которые просто будет расширять. Не говоря о том, что ORM позволяет быстро поменять СУБД. На туже монгу, только тогда надо ставить Laravel 6 (так как она LTS и основной пакет для монги пока не переписан для 7 версии). Узким местом останется сам бекенд на PHP, но чтобы захлебывался бекенд на PHP проект уже должен будет сильно востребован или кардинально неправильно спроективан. И даже тогда можно будет средствами фреймворка отмасштабироваться, перенеся те же сессии в редис и разнеся PHP бек по разным серверам. Ну или использовать сразу разные СУБД для разных данных.

Тут уже вопрос - есть ли желание погружаться в Laravel и PHP.

[d-sem]

Ну а собственно в монге + ноде никто не мешает комменты вынести в отдельную коллекцию, решая проблему размера документа. И при запросе поста одновременно промисами делать два запроса - один на документ, а другой на комменты к документу.

Никто же в принципе не запрещает использовать монгу с джоинами на уровне логики приложения, а сами официальные курсы из монгоуниверситета поощряют этот способ

[d-sem]

Опять же, не надо забывать про кеширование. Если у вас данные обновляются реже, чем читаются, то имеет смысл кешироваться в какой-нибудь memcache/redis, и на чтение отдавать данные из кеша и менять его только при изменении данных в основной базе. Тогда СУБД вообще не особо важна будет.

Answer 2

[casoer]

nestjs crud для nestjs и typeorm

Comments

[livetick2]

Интересно, изучу. Но я про скорость приложения, а не разработки.

[casoer]

livetick2, если прям быстро-быстро то restana и нативный драйвер для mongodb.

Answer 3

[batyrmastyr]

Независимо от выбора БД, отделять комментарии от расписаний нужно обязательно и каждый комментарий хранить отдельным документом/строкой. Так вы сможете забирать из базы не всю гипотетическую тысячу сообщений, а только новые.

Для сообщений в реальном времени: а правда ли вам нужно оно нужно или устроит задержка в 1 - 5 секунд? Если нужно, то стоит посмотреть на модуль HTTP Push Stream для nginx.

В 2020 чистый JavaScript только для «хренак-хренак и в продакшен» пригоден. Если и выбирать, то между TypeScript / Dart / PHP.

1) Типизация: PHP / TS / Dart
2) По скорости: для сайтов с < 200 000 просмотров в сутки даже на классическом php-fpm хватит пары ядер. Но если хочется «чтобы не хуже ноды», то смотрите в сторону swoole, roadrunner, amp и workerman с phpsocket.io.
3) Возможность писать клиентский и серверный код на одном языке: JavaScript / TypeScript / Dart.

В роли базы данных лучше возьмите постгрес - он лучше монги почти всем параметрам (скорость почти любых запросов, потребление памяти), только сложные запросы по json у него выглядят, кхм, страшненько. Но уж лучше страшные запросы, чем отдавать монге от 1 гига до 50% оперативки, строить индексы на все подряд поля и несмотря на это терпеть её тормоза.

Comments

[livetick2]

Спасибо за развернутый ответ. Я уже настроился на Монгу) Там всего пять коллекций получается. В реляционных 11 таблиц вышло. Умом, конечно, понимаю, что нормализация - это благо, прежде всего для миграций, масштабируемости... но сердцу не прикажешь))
Ну посмотрим. Скорее всего попробую оба варианта(Монга | PostgreSQL).

Реалтайм вообще не принципиально. Модуль nginx-push-stream хороший, много о нем слышал. Как вариант.

Считаете стек NodeJS/Express+Mongo+Socket.io | nginx-push-stream быстро сожрет мои 8 гиг. памяти?
Как альтернатива, PHP/любой микро рестфул фреймворк, вроде comet + PostgreSQL + nginx-push-stream перспективнее?

[livetick2]

Кстати, если не затруднит, подскажите общую логику работы по nginx-push-stream (nginx на статику брошу, мануал по модулю буду завтра курить).

Правильно ли я понимаю, что юзер пишет коммент, отправляет его в базу (не важно каким способом), а модуль на адреса pub/sub делает запросы и показывает результат с задержкой 1-5 секунд...

[batyrmastyr]

livetick2, не думаю, что вы так уж скоро упрётесь в оперативку.
Монга старается всю базу и индексы запихнуть в оперативку, так что при гиговой базе она запросто съест 1,5 - 2 гига оперативки. Едва ли нода сожрёт больше гига-двух, так что минимум гига 4 в запасе будет.
Для socket.io был (а может и сейчас работает) адаптер для постгреса. Попробуйте, может заведётся.

[batyrmastyr]

livetick2, ваш код http запросами отправляет сообщения в нужные каналы, а модуль уже раскидывает их подписчикам. На клиентах без поддержки вебсокетов передаёте заголовок x-nginx-pushstream-mode:long-polling (или просто polling).
Примеры на гитхабе оказались намного понятнее.

Answer 4

[LORiO]

Функционал простой, прототип собрать быстро и протестировать взлетит или нет...
Почему бы за пару дней не собрать на том же wp, oktober cms(Laravel)?

Answer 5

[gBACTAKAHA]

Nextjs + keystonejs. Просто собрать и посмотреть.