Что подразумевается под «знанием особенностей высоконагруженных проектов»?

Question

[Dave]

В некоторых вакансиях на hh.ru, встречется ну очень прям таки обязательный пункт для всех кандидатов - это опыт и знание особенностей высоконагруженных проектов. Гугление приводит к неоднозначным результатам - все найденные статьи трактуют разные подходы и приоритеты.

Так что конкретно должен знать веб-программист об особенностях высоконагруженных проектов?
Про кеширование и Memcached - знают все, но наверняка в эти особенности еще входит масса всего?

Answer 1

[Alex Safonov]

БД.
Репликация, нормализация-денормализация, оптимизация индексов, настройка ур. изоляции транзакций. Выбор и разнесение различных данных на различные движки и типы хранилищ. (NoSql, Couch, elastic...)

Код.
Профилирование. Оптимизация. Оценка сложности реализованного алгоритма и поиск менее затратных решений. Переписывание некоторых задач в другой яп. (Haskel, scala, go, C ) Распаралеливание. Воркеры (gearman).

Проблемы деплоя. Релизная политика.

Answer 2

[Оптимус Пьян]

Шардирование, партицирование, особенности оптимизации БД, запросов, настроек СУБД.
Возможность спроектировать так что бы когда запросов будет 1000 в секунду база не упала.
Оптимизацию скриптов желательно знать, какие функции больше ресурсов потребляют, какие меньше.

Comments

[Сергей Протько]

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

Answer 3

[Пума Тайланд]

Подразумевается что вы работали в проекте которому мало одного сервера и столкнулись с проблемой развязывания сервиса и БД на кучку серверов.

Answer 4

[Александр Черных]

Это комбинация факторов, железо,настойка софта и собственно сам код. Кривизна в одном сведет на нет преймущества остального. Так что тут сотрудничество должно быть толкового админа и вебмастера

Answer 5

[Максим Кудрявцев]

Лично я бы переформулировал "опыт и знание особенностей высоконагруженных проектов" в "Умение пользоваться Blackfire Profiler".
В подавляющем большинстве "типа высоконагруженных" проектах просто нужно сесть и отрефакторить узкие места, например:

1. 11 вложенных друг в друга циклов
   
2. Ассоциативный массив на 27 уровней вложенности
   
3. Привести наконец-таки БД в 3-ю нормальную форму
   
4. Не хранить огромную тучу настроек в БД как json-строку и т.п.
   

Сейчас, конечно, мне могут сказать, что под высоконагруженные сервисы нужно проектировать отдельную архитектуру приложения, настраивать репликацию БД, ставить два и более сервера приложений и балансировать нагрузку на них через DNS и т.п. Я соглашусь с Вами, что это реально и есть highload, однако, в подавляющем большинстве проектов, с которыми работал, настоящими высокими нагрузками и не пахнет... Просто какой-нибудь junior, студент 3-го курса не столичного ВУЗа в силу отсутствия опыта и диких криков проджект-менеджера о просроченном дедлайне писал код с опухшей головой в 3 часа ночи под 4-й банкой энергетика...

Comments

[MegaMufa]

По поводу нормализации бд не факт. При хайлоаде наоборот часто прибегают к осознанной денормализации. И эта мера применяется не в самую последнюю очередь. ЗАчастую денормализовать бд выходит проще и выгоднее, чем оптимизировать алгоритмы.

[Alex Safonov]

Да, согласен. Сначала проектируем в 1-2 нф. А потом из соображений повышения скорости приходится добавлять поля.