Горизонтальное и вертикальное масштабирование — не выбор «на вкус», а выбор по узкому месту

Горизонтальное и вертикальное масштабирование — не выбор «на вкус», а выбор по узкому месту

Коллеги, давайте разберем план выполнения. Вертикаль — это усилить одну машину: больше CPU, RAM, быстрые диски. Горизонталь — добавить узлы и разнести нагрузку. Ошибка одна и та же: лечат симптом, не смотрят, где реально упирается запрос.

Схема простая, но дьявол кроется в статистике. Если упор в CPU и запросы хорошо параллелятся, вертикальное масштабирование дает быстрый эффект. Если база уже упирается в память, кэш и I/O, добавление ядер может лишь ускорить деградацию. Посмотрим, что тут с I/O в реальности: иногда «медленно» — это не база, а диск, сеть или блокировки.

Горизонталь помогает, когда нагрузка делится по ключу: чтение можно увести на реплики, запись — шардировать или вынести горячие таблицы отдельно. Но за это платят сложностью: консистентность, реплика-лаг, распределенные транзакции, балансировка, новые точки отказа. В продакшене так лучше не делать, и вот почему: без плана на фейловер и восстановление вы просто размазываете инцидент по нескольким серверам.

Золотое правило: сначала мониторинг, потом индексы. Снимите план запроса, wait events, lock graph, профиль I/O и только потом решайте, что масштабировать. Если узкое место одно — расширяйте его. Если система уже распалась на несколько горячих точек — дробите нагрузку. Иначе купите железо, а получите более дорогой дедлок.