Comments 37
Спасибо за интересный опыт!
Насчёт серверов, вы взяли классические x86 или на arm? Монга хостится на том же хосте, где и бэкенд?
Конфигурации, которые нам показались оптимальными:
Фронтенд: 16 CPU + 64 GB RAM
Бэкенд: 24 CPU + 128 GB RAM
Один большой сервер на фронтенд и один большой сервер на бакенд это, не слишком оптимально - единая точка отказа.
Если уж все в докер контейнерах, то стоило-бы попробовать AWS ECS который хостит контейнеры в Fargate + автоскейлер и все это за ALB, вышло-бы сильно дешевле 200 долларов в месяц, за счет автоскейрера, плюс надежность существенно выше, ибо контейнеры распределяются по разным физическим машинам, и даже по-умолчанию по двум авайлабилити зонам, так что даже если у Амазона датацентр целиком умрет, у вас все будет работать.
Про фронтенд, есть какая-то острая необходимость в серверном рендеринге? Просто если обычное Реакт приложение с рендерингом на клиенте, то фронтнд сервер вообще не нужен, файлы кладутся в S3 и дистрибьюция через CloudFront, там FreeTier что-то типа 10 терабайт, так что обошлось-бы вам оно бесплатно.
Спасибо за комментарий!
На этапе первого запуска мы сознательно выбрали простой и предсказуемый сетап — тот, в котором всё работает именно так, как мы ожидаем, и стоит заранее известную сумму. При этом да, у нас есть единая точка отказа, это не очень надёжно.
Сейчас уже начинаем рассматривать более гибкие решения, похожие на то, что вы описали.
Наш характер нагрузки хорошо под это подходит: чаще всего в приложении онлайн до 500 пользователей, но бывают резкие всплески — когда за несколько секунд заходят 10–15 тысяч человек.
Автоскейлинг и распределение по нескольким зонам доступности действительно сделают систему надёжнее. Возможно, это окажется и дешевле при нашей текущей нагрузке — хотя многое будет зависеть от её характера. Сейчас пики редкие и кратковременные, но уже в следующем футбольном сезоне (через 3 месяца) мы ожидаем изменения.
Мы планируем серьёзные продуктовые доработки и хотим, чтобы пользователи заходили не только во время матчей, но и между ними. Это может привести к росту постоянного онлайна и изменению профиля нагрузки — соответственно, изменятся и расходы.
Я думаю, что ваш подход на текущей нагрузке точно будет надежнее и выгоднее. Но в будущем нужно будет посчитать.
Острой необходимости в SSR нет, и на текущий момент мы уже полностью перешли на SSG, про это будет подробнее во второй части статьи. Вы правы, на счёт того, что фронтенд сервер вообще не нужен, планируем убирать его.
100т уников за 3 суток для вебаппки это же околонулевая нагрузка. Что надо делать что бы для этого не хватило 5 долларовой впс от ноунейм провайдера?
Мне вот тоже кажется, что основной вывод из статьи - никогда не использовать стек JS+MongoDB. Ну или искать тех, кто умеет им пользоваться. Такого железа хватит на нагруженный сервер на несколько миллионов DAU...
Не соглашусь с тем выводом, который вы делаете.
Соглашусь с тем, что несколько миллионов DAU можно держать на таком железе. Поэтому мы его и брали, чтобы был запас. И тут я хотел скорее подчеркнуть именно то, что за такие небольшие деньги можно получить такие мощности, которые позволят держать несколько миллионов DAU.
Мы понимали, что вопрос именно в оптимизациях и корректной конфигурации.
На самом деле, сейчас у нас всё очень комфортно по нагрузке: даже в пиковые моменты фронтенд сервер загружен не больше чем на 4%, а бэкенд — максимум на 18%. Это ситуации когда большой единомоментный трафик, больше чем 15 тысяч пользователей заходят за несколько секунд. А в обычных ситуациях нагрузка на фронт в районе 1%, на бэк - 3%.
Поэтому, не думаю, что есть какая-то проблема в стеке JS + MongoDB.
Запас по ресурсам у нас сейчас приличный, и видно, что есть ещё куда оптимизировать, например, внедрить кэширование уже на уровне бэкенда (пока его у нас нет). Так что вопрос скорее не в стеке, а в том, как его использовать и насколько грамотно всё настроено.
Т.е. вы поставили железа примерно в пять раз больше, чем планировали?
Тогда о чем статья-то? О том, что надо нанимать опытных разработчиков?
Да и получить 800rps на 16 CPU и 1200rps на 24 CPU - это очень грустно. Там же не платежи за каждым rps-ом прячутся, а что-то более простое...
а на сколько% железо должно быть использовано в пике, по вашему мнению?
20% это имхо как раз хорошо (пока денег на такое железо хватает)
Если в пиках, то там речь скорее о 70-80%. 20% в пиках (т.е. меньше процента в среднем) - это про совсем неэффективное использование ресурсов.
ок, пожалуй согласен
хорошо - это когда в среднем утилизация ресурсов 10%-30% а в пиках 30%-60%
выше не стоит, потому что при 70%-80% система будет уже заметно тормозить
а в облаках в некоторых ситуациях уже и после 40% становится заметно что времена отклика начинают расти
Хм, почему это при 70-80% система будет заметно тормозить? В облаках там все чуть по другому, там проще уметь просто быстро подключать новые узлы.
Ну и если в пиках 60, то в среднем обычно меньше 10, а то и около одного процента (но зависит от конкретного бизнеса, не всюду бывают всплески в два порядка от среднего. У топикстартера - бывают...)
тут такой нюанс, проц (ядро) ведь на самом деле не может быть занят на 60%
Он либо занят либо нет.
А 60% просто означает что "за последние 5 секунд он был занят 60% времени"
Соответственно, % загрузки означает сколько времени вам нужно будет ждать своей очереди. Чем больше загрузка - тем с бОльшим количеством других задач придётся толкаться.
А ещё второй нюанс действует (это мы в AWS словили):
в x86 процессорах ядра "располовинены" гипертрейдингом. И это круто, но - это не полноценные ядра. это просто возможность использовать незанятые инструкции ядра для других задач.
То есть если у у вас все задачи одинаковые (простейшие задачи для проца) - гипертрейдинг не даст плюса вовсе.
На деле так, конечно, не бывает - если вы кидаете http-запрос это порождает пачку разнообразных задач для процессора и за счёт этого гипертрейдинг даёт хороший прирост.
Но всё же не х2
Полагаю что поэтому, когда проц увеличивается выше 60% (а порой и выше 40%) мы уже начинаем ощущать тормоза ("половинка каждого ядра" выделенная как целое ядро из-за гипертрейдинга занята почти полностью)
я не говорю, что это дикие тормоза. Просто время отклика чуточку начинает плавать.
PS это не для всех систем актуально. Но в нашей системе у многих операций время отклика по вебсокету 1-8ms, так что мы замечаем.
Хм, для меня "загрузка на 80%" - это 8 ядер из 10 загружены (ну или да, каждый 20% простаивает). Но если это свое железо, то в этом случае latency не увеличивается, так как ресурсов для планирования еще хватает и избытком (и даже гипертрейдинг не начинает сказываться, опять-таки из-за свободных ресурсов).
Но это для своего железа, где никто другой за ресурсы не борется и когда процессор простаивает - он просто простаивает, никакой очереди.
А в облаке - там скорее по числу экземпляров скалируешься, благо их дешево поставить. И там у тебя меняется не загрузка сервера, а число контейнеров.
Соглашусь, 100 000 уников за 3 дня это не много. Но, ключевой фактор тут - это характер нагрузки. Есть ярковыраженные вспелски, когда за несколько секунд 10-15 тысяч пользователей одновременно заходят в приложение.
Мы изначально брали сервера с запасом, потому что не было чёткого понимания, сколько реально придёт пользователей. По прогнозам, максимум могло быть до миллиона за три дня, минимум — тысяч 50. В итоге, вышло что-то среднее, но инфраструктуру закладывали именно с прицелом на максимальные значения, чтобы не получить аврал в случае удачного запуска.
VPS за 5 долларов у ноунейм-провайдера, как правило, сильно ограничена по ресурсам. Если вдруг в течение пары секунд в приложение зайдёт 20 тысяч человек — такой сервер просто ляжет, особенно если это не статичный сайт, а динамическое приложение с авторизацией, API и базой данных. Тут вы, мне кажется, немного не учитываете реальные ограничения дешёвых VPS.
Ну и плюс — мы специально брали инфраструктуру с запасом, чтобы потом не возвращаться к этому вопросу через месяц и не заниматься экстренным переносом. Это даёт возможность спокойно развивать продукт, не боясь внезапных всплесков трафика. При этом соглашусь, мы бы могли обойтись серверами не за 200 $, а скажем за 50 $, реалистично. Но разница между этими цифрами не такая уж существенная.
1) Зачем, а главное для чего(цензура) для вашего приложения нужен Next.js? Это якорь который:
- Тупо вставляет палки в колеса при разработке, накладывая свои ограничения.
- Ставит на колени производительность из-за ненужного в вашем случае SSR на ровном месте.
2) Зачем вы берете Nest.js, когда есть Express.js? Nest в свою очередь:
- Так же тупо вставляет палки в колеса из-за своих ограничений и прихотей, это же именно фреймворк монструозный, жирнющий и уродливый.
- Ставит на колени производительность просто тупо за счет своего runtime. А если вы ещё используете ORM, то вы ставите производительность ан колени в квадрате.
- С точки зрения кода, на выходе получается месиво из декораторов.
3) Зачем вы взяли MongoDB? Это же классическая ошибка и классический эпик фэйл, через который проходят все кто ее берет, потом в любом случае будет переезд на Postgres или MariaDB/MysQL. Почему просто сразу не взять Postgres или MariaDB и всё?
4) Надеюсь вы знаете, что когда вы запускаете в Docker'e базу данных или Node.js приложение или что угодно ещё, вы теряете так же в районе 20-30% производительности на ровном месте. В зависимости от сценария, я тестил по классике через apache bencmark замеряя RPS, где endpoint делает 3 запроса в БД, парсит json, преобрзаует объект в json и отдает ответ. Я проводил бенчмарки и в том время когда Docker только появился, и в прошлом году, в плане просадки по производительности ничего не изменилось в лучшую сторону. Всё так же приходится платить эту цену запуская что-то в докер контейнере.
2) Зачем вы берете Nest.js, когда есть Express.js? Nest в свою очередь:
...
- Ставит на колени производительность просто тупо за счет своего runtime
Разве? Есть какие-нибудь тесты, которые показывают это? Быстрогуглом нашел только минимальное влияние, но я особо долго и не искал. И что там за рантайм? По идее, DI разруливается во время запуска, а во время работы уже прямые вызовы.
Есть какие-нибудь тесты, которые показывают это?
Единственный, самый правильный и самый правдивый вариант - провести бенчмарк самому и вы сами во всем убедитесь и будете на 100% уверены в результатах. Все цифры в статьях и в видосах в 95% случаев оказываются лажей и когда проводишь тест самостоятельно, в этом убеждаешься.
Сделайте типичный тест:
- Nest: самое приближенное к реальности, обычно его используют в связке с TypeORM, со встроенной валидацией входящих данных, вот используя это сделайте эндпоинт, который будет валидировать данные входные, 3 запроса в БД слать и отдавать ответ с одного из запросов.
- Для Express, а если нужно ещё быстрее процентов на 20%, то Fastify или самописный аналог Express. А дальше т.к. руки у вас уже не связанные и есть свобода выбора, то возьмите для БД postgres https://github.com/porsager/postgres и разумеется никаких orm, мы же про производительность говорим, для валидации какой нибудь zod или самописный аналог.
Дальше прогоните через ab -c 1000 -n 50000 http://localhost:3000 допустим и все циферки увидите.
Хм, но это будет сравнение орм вс прямой доступ. Nest никак не ограничивает в выборе того как работать с базой данных, не заставляет использовать TypeORM или что-то еще. Из коробки он дает самый минимум, DI и модульную структуру, все остальное ставится дополнительно, или не ставится. Хочется работать с базой напрямую sql запросами - никаких проблем, или палок в колеса.
Более того, если хочется использовать Fastify вместо дефолтного Express это тоже легко делается.
Но тесты, пожалуй, сделаю, какраз недавно запилил пет проект на Nestjs, чтоб понять что это такое, а то раньше им не пользовался, запилю аналог на чистом экспресс и сравню производительность.
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
2. NestJS / Express / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляет FastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. И медленный тут именно Express, а не NestJS, обратите внимание. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.
3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
в Docker'e базу данных или Node.js приложение или что угодно ещё, вы теряете так же в районе 20-30% производительности на ровном месте
Очень спорное утверждение. Почему вы так считаете?
Очень спорное утверждение. Почему вы так считаете?
Я лично это проверял и проводил бенчмарки, в 2017 году и этой зимой. результат тот же, 20-30% потеря производительности внутри докер контейнера, за 8 лет изменений в этом плане не произошло.
Проведите замеры сами и убедитесь в этом. Мне какой резон врать, я говорю только то, что вижу своими глаза, а не на основании "где-то прочитал", особенно в "авторитетном" источнике, у меня критическое мышление, я на такие штуки не ведусь.
на самом деле это очень интересно - почему тесты приложения в докере могут выдавать результаты, сильно отличающиеся от того же приложения, не в докере.
В смысле - я не сомневаюсь в ваших результатах, но мне важно, в каких условиях они воспроизводятся (много работаю с приложениями в докере, хочется лучше понимать его ограничения)
Можете рассказать о подходе к тестированию?
Для затравки я расскажу, как я это вижу:
Интересен тест близкий к целевому, так что будем не просто нагружать проц а кидать HTTP-запросы
- Нужно 2 сервера на Linux (источник нагрузки и объект тестирования)
- на серверах выполняем настройки, типа увеличения диапазона портов, tw_reuse, всякое такое, чтобы настройки операционки не мешали
Часть настроек можно взять отсюда
https://docs.gatling.io/concepts/operations/
==========
тест 1: запускаем приложение на сервере объекта тестирования
тест 2: Запускаем то же самом приложение на том же самом сервере, но в докер-контейнере.
У контейнера прописаны Request достаточные, чтобы запустить приложение, а Limit не прописаны вовсе (можно прописать для лимит для памяти равный 80% от свободной оперативки на сервере, но для CPU) точно не нужно прописывать лимит, троттлинг может очень сильно зааффектить на приложение в контейнере
==========
Сами тесты одинаковые, со второго сервера подаём постепенно увеличивающуюся нагрузку.
Смотрим где захлебнётся (прекратится рост производительности, начнут расти времена отклика или ошибки)
Для проверки лучше брать приложение, которое не работает с диском.
Можете рассказать о подходе к тестированию?
Я тестил по классике через apache bencmark замеряя RPS, сделал endpoint, который делает 3 запроса в БД, парсит json, преобрзаует объект в json и отдает ответ. Получается усредненный сценарий работы бэкенда, именно реальный, а не просто кто быстрее в цикле посчитает до миллиарда.
Дальше запускаем наше микро приложение-эндпоинт без докера и замеряем, раз 5, чтобы усреднить результат
ab -c 1000 -n 50000 http://localhost:3000
Потом то же самое микро приложение-эндпоинт запускаем в докере (полностью без ограничений) и так же замеряем раз 5
ab -c 1000 -n 50000 http://localhost:3000Сравниваем циферки, вот и все методика.
При этом сама БД у меня была в обоих случая без докера.
Можно сделать ещё лучше, добавить ещё сценарии и БД тоже завернуть в докер и замерить.
Docker файл
FROM node:22-alpine
WORKDIR /app
COPY . ./
RUN npm install
CMD node ./master.js
EXPOSE 8080Где master.js
const cluster = require('cluster');
const os = require('os');
const numCPUs = os.cpus().length;
(async () => {
// If process is master
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers.
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
// When worker dies we do new fork
cluster.on('exit', (worker, code, signal) => {
console.log('worker %d died (%s). restarting...',
worker.process.pid, signal || code);
cluster.fork();
});
}
// If process is worker
else {
console.log('Worker is forked...');
require('./index.js');
}
})();
Без докера так же запускался этот файл node ./master.js
Это ваш первый проект на Node?
Нет, в целом конечно не первый.
Но из таких, которые получают реально существенный трафик за несколько дней и где надо думать про оптимизации - первый.
Нет, в целом конечно не первый.
Судя по тому, что вы вообще абсолютно бездумно и не понимания для чего конкретно нужны те или иные инструменты и технологии выбрали mongodb, nextjs, nestjs, ещё и в докере это все запустили ещё и с надеждой что это даст какую-то производительность... Это явно ваш первый проект в карьере и первые грабли. Ничего страшного, наберетесь опыта, научитесь и рано или поздно всё получится, но это не точно.
Если хотите реальную производительность на Node.js:
1) Никаких докеров!
2) Fastify или самописный аналог Express.
3) PostgreSQL или MariaDB.
4) Драйвер для БД postgres https://github.com/porsager/postgres
5) Nginx
6) Никаких SSR, тем более Next.js в вашем случае в принципе быть не должно.
При таком раскладе виртуалка за 5$ с одним ядром будет держать такие же нагрузки, как ваш текущий сетап. А на вашем железе, такой расклад легко и не прbнужденно будет держать 10к+ RPS, и это вообще без кэша(redis/memcached не знаю, слышали о таком или нет), с кэшом там вообще мама не горюй. А для статики так вообще будут чудовищные цифры, скорее упретесь в пропускную способность сети)
Меня зовут Женя, сейчас я работаю разработчиком в Google. В стартапах был в роли CTO более 4 лет, а всего в IT — уже больше 9 лет, преимущественно в крупных компаниях и в области веб-разработки
А обманывать конечно не хорошо, ой как не хорошо. Не верею что за 9 лет в разработке вы обладаете знаниями такими, какими обладаете.
Очень рад, что у меня появился первый хейтер!
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
2. NestJS / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляет FastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.
3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. NGINX
Спасибо большое за совет, но у нас он и так используется в качестве Reverse Proxy. Тут пустая болтовня.
5. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
Резюмируя: выглядит так, что вы всю жизнь сидите на одном стеке с любимым потсгресом, а свои проекты деплоите по FTP (попробуйте CI/CD, не знаю слышали о таком или нет).
Обвинять меня в обмане вы, конечно же, не имеете ни прав, ни оснований. Мои данные открытые и публичные.
По вопросам веры - в церковь.
Ваш заминусованный профиль только подтверждает мои слова, что это просто рандомные набросы, чтобы потешить своё эго. Сегодня не выйдет. По фактам вы уничтожены. Приходите завтра.
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Собственно ручные проверки и бенчмарки это рандомные набросы? Ну тогда рандомные набросы.
1. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%.
А, т.е. вот так вы решаете что хорошо, а что плохо? Ахаха, да, это чисто "инженерный" подход. На заборе тоже написано много всего. Прямые эксперименты и бенчмарки как раз таки показывают падение производительности на 20-30%. Я делал это замеры сам, лично и не один раз, я ведь инженер, а не доверчивая домохозяйка, которая на веру берет все, что кто-то пишет или говорит. Последний раз несколько месяцев назад замерял, чтобы проверить за 8 лет(первый раз замерял его как раз 8 лет назад) изменилась ли просадка в производительности у докера в лучшую сторону, оказалось что нет. Он как гадил ощутимо по производительности, так и гадит. Это же легко проверить, просто возьмите и проверьте. Сами всё увидите.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
Я не заявляю, я констатирую факты неоднократных собственноручных замеров. В которых легко вы можете убедиться собственноручно. В этом даже близко нет ничего сложного и долгого. ab -c 1000 -n 50000 http://localhost:3000 на бэк вне докера и потом на бэк в докере, и все станет понятно.apt-get install apache2-utils для того, что работала команда ab она же apache benchmark.
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности
Так проведите прямые замеры и все увидите. У вас опять апелляция к - "Я видел, так на заборе написано, значит это правда". А это опять же подход кого угодно, только не инженера и не разработчика.
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных
Такой "аргумент" был ещё в 2012 году, только он быстренько стал не актуальным.
1) Если у вас меняются схемы данных, после выхода в продакшен, то вы не архитектор, вы не инженер, вы не разработчик, вы даже не понимаете что вообще должен делать вам проект и что вы от него хотите. Проекты "продуманные" на таком уровне априори мертворожденные. Поэтому ваш "аргумент" из 2012 года не применим к реальности, я имею ввиду когда проекты делают реальные разработчики.
2) В PostgreSQL уже 100 лет в обед есть тип данных JSON. Раньше для произвольного набора данных использовали тип TEXT.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
Да да, все джуны так говорят которые решили заюзать монгу, а потом оказывает что нужны транзакции, нужна нормализация данных, нужны Join'ы и т.д. и т.п. И приходится все смывать в унитаз и делать по новой, только уже с нормальной базой данных.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Да ладно?)
Во первых упереться в БД, тем более на выделенном сервере это задача из разряда нужно быть гуглом, яндексом, вк и т.п., где реальная нагрузка в виде сотен тысяч RPS. 99.9999% даже реальные 10k RPS которые дойдут до БД в пиках не снились, между прочим для постгреса 10k RPS это вообще семечки, а не нагрузка.
Во вторых, даже если каким чудным образом вы упретесь в БД по операция чтения, то это решается легко и просто, репликацией и добавлением кэша.
В третьих, это уже сценарий из разряда ВК, и т.п., если вы упретесь в операции чтения, что на выход приходит шардирование, у него нет универсального метода(это вы так на монгу по надеялись, смешно), в каждом проекте это всегда индивидуально.
Обвинять меня в обмане вы, конечно же, не имеете ни прав, ни оснований
По-моему оснований придостаточно, набор технологий, детские проколы с SSR и т.п. это подтверждают)
Ваш заминусованный профиль только подтверждает мои слова
Это лишь результат обиженок, которым больно когда им говорят правду.
По фактам вы уничтожены
Ахахх, смешно. Слова того, кто не знает что такое факты) Наивно пологая, что факты это то, что на заборе написано.
Ахахах, спасибо за ваш комментарий. С кайфом почитал, посмеялся, зарядили хорошим настроением!
Успехов!
Про MongoDB хорошо масштабируется - это ж классика :)
Будьте готовы к тому, что cloudflare и ркн плохо дружат. Уже не первый раз возникают учения, из-за которых сайт днями не открывается для некоторых регионов. Может зеркало какое-то использовать..
100K юзеров за 3 дня — как готовились к релизу