Все любят «хайлоад». Билеты на всякие «хайлоадконфы» стоят больших денег и моментально раскупаются охочими послушать, что же там новенького в больших конторах и какое специализированное nosql-решение сегодня в моде.
Любой доклад, в котором упоминаются «большие нагрузки» и «кластера на тысячи подов», собирает полный зал слушателей. Это логично: люди любят инструменты (особенно новенькие) и не любят простые и понятные старые вещи.
Мало кому интересен доклад «Как сделать веб-приложение на LAMP-стеке за два дня без кластеров и HA». Мало кому интересен доклад «Server-side rendering (не тот, который react SSR, а тот, который erb/blade/ninja) и фронтенд на Vanilla JS». Никому не интересно услышать, как можно более эффективно делать ежедневную простую работу без упарывания по «кубернетесам», микросервисам, «серверлессам» и кластерам в «облаках».
Но ведь над «хайлоадом», на самом деле, работает не так много людей! Даже в больших конторах есть специальные отделы, в которых сидят головастые ребята (они же типа «системные» программисты), которые пишут очередной «кликхаус». Все остальные, «прикладные», так сказать, программисты, просто пользуются этим «кликхаусом», как инструментом. Не особо запариваясь, что там внутри.
Большинство компаний, на самом деле, делают обычные решения, которым или не нужна высокая нагрузка (ввиду небольшой пользовательской базы), или они и так работают «норм».
И вот человек, который пошёл и наслушался про кластера, приходит на работу и видит монолитные «круды». Какой толк ему от кластеров? У него ведь проблемы совсем иного толка!
Корень почти всех зол, связанных с производительностью (в моей практике) — неправильный дизайн хранилища данных или неправильное его использование. Готов поспорить что 80% всех проблем легко решаются убиранием N+1, продуманными индексами и архивированием устаревших записей. Оставшиеся проблемы исправляются грамотным использованием шаблонов организации данных (например, частая проблема — считать записи по определённому критерию; и вам совершенно не нужно наворачивать для этого redis или firehose, или ещё чёрт знает что).
Нет, я совершенно не против расширения кругозора или обсуждения, как держать 299kk req/sec на t3-инстансе. Но, как по мне, людям не хватает здорового интереса к тому, что можно значительно оптимизировать в рамках своей ежедневной деятельности без всякого «хайлоада» и нанотехнологий.
Когда я только начал работать, я не знал, что такое «join» и зачем оно надо. Вместо меня запросы писали шарящие люди. Ну, а я гонял одинокие «фасолины» по необъятным пространствам «веблоджика». Потом-то я, конечно, научился всем (или, по крайней мере, многим) премудростям SQL, но вот когда речь заходила про «хинты», то я немного терялся, зачем оно вообще. И вот пару месяцев назад наткнулся на статью «How does a relational database work», которая за один час чтения здорово заполнила пустоты в голове, возникшие за десяток лет игнорирования сведений о работе «реляционок». Эта статья и банальные факты оттуда (вроде того, что такое b-tree) позволяют мне решать проблемы с производительностью на своих проектах прямо щас просто правильной подстройкой индексов. Всего лишь часик вдумчивого чтения — и ты уже неплохо начинаешь понимать, что и как работает. И это я даже ещё не открывал мануал по тюнингу параметров движка!
Мне кажется, в какой-то момент мы не туда свернули. Вместо изучения и мастерского владения инструментами, которым десяток лет, мы бросаемся, как голодный пёс, на кости уродцев, выращенных в тёмных подвалах больших корпораций, и гордо несём их в свой проект, порождая безобразные поделия — франкенштейнов, собранных из карго-культа, resume-driven development и полного отсутствия фундаментального образования. Вместо изучения проблемы и выбора инструментов под неё, мы держим молоток в руках и видим вокруг множество гвоздей, которые срочно надо забить.
Автор: Рожок.