Горизонтальное или вертикальное масштабирование: как не лечить БД «на глаз»

Горизонтальное или вертикальное масштабирование: как не лечить БД «на глаз»

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

— Если упираетесь в память, буферы и сортировки, сначала смотрите на вертикаль: часто дешевле и безопаснее.
— Если потолок уже в одном узле и проблема в параллелизме, пригодности к отказу или географии, нужна горизонталь.
— Если запросы держат много блокировок и есть горячие строки, масштабирование само по себе не спасет: сначала убирают контеншн.

Золотое правило: сначала мониторинг, потом индексы. Посмотрим, что тут с I/O в реальности: чтение, запись, fsync, latency, очередь диска, CPU steal, локи. Без этого «давайте шардировать» часто означает просто перенести боль в 10 мест вместо одного.

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

Вывод простой: масштабируют не базу, а конкретное узкое место. Если его не нашли, любое расширение — дорогая форма самоуспокоения.