<b>Горизонтальное и вертикальное масштабирование: где выигрывает база, а где только бюджет</b>

<b>Горизонтальное и вертикальное масштабирование: где выигрывает база, а где только бюджет</b>

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

Вертикаль проще: меньше сетевой сложности, транзакции живут ближе к данным, меньше боли с консистентностью. Но у нее жесткий потолок: один сервер, один отказ, один набор блокировок. Когда упираетесь в I/O или latch contention, добавление ядер уже не лечит. Посмотрим, что тут с I/O в реальности: если диск и память уже в красной зоне, масштабировать CPU — это дорогой способ греть воздух.

Горизонталь дает отказоустойчивость и рост по мере нагрузки, но платите сложностью: распределенные транзакции, лаг репликации, перекосы по ключам, дорогие JOIN’ы между узлами. Самая частая ошибка — начать шардинг до того, как поняли профиль запросов. В продакшене так лучше не делать, и вот почему: потом любая выборка по «неправильному» ключу превращается в обход половины кластера.

Схема простая, но дьявол кроется в статистике: сначала снимите реальные метрики по CPU, RAM, IOPS, p95 latency и блокировкам; потом решайте, что дешевле — усилить узел или дробить систему. Если одна машина еще держит нагрузку с запасом, вертикаль обычно дешевле. Если нужен рост без единой точки отказа — тогда горизонталь, но только после проверки, что модель данных и запросы это переживут.

Золотое правило: сначала мониторинг, потом индексы; потом уже выбор между «мощнее» и «больше».