Усі люблять хайлоад. Квитки на хайлоадоконфи коштують купу грошей і моментально розкуповуються охочими послухати що там нового у лідерах ринку і яке спеціалізоване NoSQL рішення сьогодні у моді.
Будь-яка доповідь де згадуються «великі навантаження» та «кластери на тисячі подів» збирають повний зал слухачів. Це логічно — люди люблять нові та блискучі інструменти, і не люблять прості та зрозумілі старі речі.
Нікому цікава доповідь «як зробити веб-апку на LAMP за два дні без кластерів та HA». Нікому цікава доповідь «server-side rendering (не той котрий react SSR, а erb/blade/ninja) та фронтенд на vanilla js». Нікому не цікаво почути як більш ефективно виконувати щоденну роботу без угорання по кубернетесам, мікросервісам та кластерам у хмарах.
Але насправді над хайлоадом працює не так багато людей! Навіть у великих конторах є спеціальні відділи, де сидять головасті люди, вони ж типу «системні» програмісти, та пишуть черговий клікхауз. Решта, «прикладні» програмісти, просто користуються цим клікхаузом як інструментом, не надто переймаючись, що всередині.
Більшість компаній насправді роблять звичайні рішення, яким не потрібні високі навантаження через невелику користувацьку базу, або вони й так працюють нормально.
І ось людина яка наслухалась про кластери, приходить на роботу та бачить монолітні круди. Яка користь йому від кластерів? У нього ж зовсім інші проблеми та задачі!
Корінь майже всіх зол, пов'язаних з перформенсом (у моїй практиці) — неправильний дизайн сховища даних або неправильне його використання. Готовий битися об заклад, що 80% усіх проблем легко вирішуються прибиранням N+1, продуманими індексами та архівацією застарілих записів. Все що лишилося виправляється грамотним використанням шаблонів організації даних (наприклад часта проблема — робити count(*) по деякому критерію. І вам зовсім не потрібно навертати для цього redis або firehost або ще казнащо).
Ні, я зовсім не проти розширення світогляду або обговорення як тримати 299kk req/sec на t3 інстансі, але, як на мене, людям не вистачає здорової цікавості до того, що можна суттєво оптимізувати в рамках повсякденної діяльності без всілякого хайлоаду та нанотехнологій.
Коли я тільки почав працювати, то не знав, що таке join та навіщо воно потрібно. Замість мене запити писали щарящі тіпи, а я ганяв одинокі квасолини по неосяжних просторах веблоджика. Потім я звісно навчився всім (або принаймні багатьом) нюансам SQL, але коли мова заходила про хінти, то я губився. І ось кілька місяців тому я натрапив на статтю «How does a relational database work» яка за годину заповнила порожнини в голові, що утворилися за десяток років ігнорування знань про роботу реляціонок. Ця стаття та банальні факти звідти (типу що таке b-tree) дозволяє мені розв'язувати проблеми зі швидкодією на своїх проєктах прямо зараз просто правильним налаштуванням індексів. Всього година вдумливого читання — і ти вже непогано починаєш розуміти що і як працює. І це я ще навіть не відкрив мануал по тюнингу параметрів рушія БД!
Здається, ми не туди повернули. Замість вивчення та опановування інструментів яким десятки років, ми кидаємося, наче голодні пси на кістки потвор, вирощених у темних підвалах великих корпорацій, та гордо несемо їх до свого проєкту, породжуючи неподобство, франкеншейни зібрані з карго-культа, resume-driven development та повної відсутності базової освіти. Замість вивчення проблеми та вибору інструментів під неї ми тримаємо молоток в руках, та бачимо навколо купу цвяхів, які терміново треба забити.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred
