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

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

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

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

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

Сервер для старта выбрал не дорогой, за 13 долларов, 3 ядра Intel Xeon, 8 гиг. памяти, 48 гигов SSD.
  • Вопрос задан
  • 1871 просмотр
Пригласить эксперта
Ответы на вопрос 5
@d-sem
Если не мучаться с нормализацией данных на входе как в реляционных базах данных, то придется мучаться с ней на выходе. Обратная сторона удобства.

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

Лучше не заниматься преждевременной оптимизацией. Сделать прототип на том стеке, что лучше известен. Уточнить требования и уже дальше решить - стоит оптимизировать или нет. А еще лучше сделать два прототипа и решить, что лучше на практическом сравнении. Практическое же сравнение делать на основании тестов из сформированных требований.
Ответ написан
@casoer
nestjs crud для nestjs и typeorm
Ответ написан
batyrmastyr
@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% оперативки, строить индексы на все подряд поля и несмотря на это терпеть её тормоза.
Ответ написан
LORiO
@LORiO
Функционал простой, прототип собрать быстро и протестировать взлетит или нет...
Почему бы за пару дней не собрать на том же wp, oktober cms(Laravel)?
Ответ написан
@gBACTAKAHA
Nextjs + keystonejs. Просто собрать и посмотреть.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы