MishaXXL, высоконагруженные проекты проектируются не так, как обычные. Там будут кэши, шардинг, полнотекстовые индексы и прочее, и прочее. Впрочем тысячу сложных запросов в секунду можно вывезти и вполне обычными методами, если у разработчиков руки откуда надо растут.
Вы сначала у безопасников выясните разрешат ли они исключить админов из процесса. Заодно неплохо бы понять, почему вообще аналитики вносят какие-либо изменения на проде, притом часто - это выглядит противоестественным.
derasoft, буквально не за что просить. Умение найти информацию многого стоит, продолжайте в том же духе и вас ждут великие свершения на профессиональном поприще.
dkis, Прежде всего для ответа необходимо знать детали вашего бизнес-процесса. Если это просто запись на мероприятия, то обеспечить тысячу rps можно без особых ухищрений парой самых дешёвых VPS. Если там какие-нибудь хитрости есть, типа составления оптимального расписания - это уже совсем другая история будет. А дальше профилирование, профилирование и ещё раз профилирование. В зависимости от его результатов оптимизация запросов к БД, оптимизация кода, кэширование, горизонтальное масштабирование и т.д. и т.п. Волшебного рецепта подходящего всегда и всем просто не существует, у каждого проекта собственный путь к высокой эффективности, который лучше прокладывать под руководством человека с опытом в высоких нагрузках.
Дмитрий, мы конечно не знаем всех деталей, а потом мои предположения могут быть ошибочными, но в свои фрилансерские времена я интернет-магазины, с очевидно на много более сложной функциональностью, писал в одиночку за пару недель. а они потом легко обрабатывали 300 rps с соразмерными объёмами данных.
Дмитрий, если предложения переданы именно так, как были озвучены, то они выдают некомпетентность. CDN вообще не при чём, если с сервака не тащат статику гигабитами, что вряд ли. Развернуть Redis и MySQL на отдельных серваках в той же среде - разумное решение, но пункты сформулированы очень странно. Как бы их авторы ещё больше тормозов на сетевых издержках не наловили. Упоминание о том, что у некоторых таблиц куча полей может служить сигналом, что нормализация БД отсутствует, что обычно соседствует с неумением писать оптимальные запросы. Наконец, 2000-4000 человек за 20 минут - это 2-4 запроса в секунду. Если сайт на серваке со 128 гигами памяти и 24-я ядрами ложится от 3 RPS, то руки разработчика кривые чуть более, чем полностью.
mollya, правильный способ делать параметризированные sql-запросы. Формирование запросов конкатенацией или интерполяцией строк - это очень плохая практика, за которую в порядочном обществе бьют.
mercciful, не надо ничего создавать. Прописываете в dns-зоне wildcard-запись, web-сервер настраиваете все запросы к поддоменам отправлять вашему web-сервису, в web-сервисе у всех прилетающих запросов из заголовка host выделяете субдоменную часть, находите в БД соответствующую ей запись и возвращаете клиенту редирект на ссылку.
