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

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

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

Вертикаль хороша, когда упираетесь в один тяжелый серверный узел: cache miss, нехватку памяти под рабочий набор, медленный I/O. Плюс простой: меньше сложности в приложении и операционке. Минус тоже простой: есть потолок, а еще один большой сервер часто становится дорогой точкой отказа.

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

Золотое правило: сначала мониторинг, потом индексы. Смотрите на CPU, RAM, I/O wait, p95/p99, блокировки и размер рабочего набора. Если одна машина не влезает по памяти или диск — сначала вертикаль. Если узкое место в параллельной нагрузке и чтении — думайте о горизонтали.

Схема простая: масштабируйте не «как модно», а туда, где у вас узкое место. Иначе вы не решаете проблему, а переносите ее в более дорогую форму.