Как заставить вашу базу данных летать, а не ползать. Часть 1 масштабирование и репликация

Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь). 

На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам. 

Согласны? Узнали? Тогда поехали!

Когда база данных кричит «Помогите!»

Представьте, ваше приложение стало популярным. Но теперь база данных тормозит, как старый компьютер с Windows XP, а пользователи жалуются, что «все зависает» (а вы уже мечтаете о побеге в Гималаи). Что делать?

Масштабирование: два принципиально разных подхода

Прежде чем переходить к сложным решениям, важно понять базовые стратегии.

1. Вертикальное масштабирование (Scale Up): когда больше — не значит лучше

По сути, мы делаем наш сервер мощнее по четырем ключевым направлениям:

1. CPU (процессор)
   Добавляем ядер — теперь сервер может пережевывать больше запросов одновременно. Как шеф-повар с четырьмя руками, который успевает и суп мешать, и котлеты переворачивать.

2. RAM (оперативная память)
   Увеличиваем «кратковременную память» сервера. Теперь он может держать в уме не 10 таблиц, а 100. И не нужно постоянно «вспоминать», лезть за данными на медленный диск.

3. Диски (HDD → SSD/NVMe)
   Меняем старый жёсткий диск (как велосипед) на SSD (спортивный мотоцикл). Скорость чтения/записи вырастает в 50-100 раз!

4. Сеть
   Улучшаем «дороги», по которым данные ходят к пользователям. Было как грунтовка — стало как шестиполосное шоссе.

Почему это так популярно?

✅ Проще некуда
Никаких изменений в коде, никаких сложных настроек. Купил сервер мощнее — воткнул вместо старого. Всё работает как прежде, только быстрее.

✅ Один сервер — одна головная боль
Не нужно думать о синхронизации между узлами, распределении запросов. Всё в одном месте — и следить проще, и чинить.

✅ Совместимость 100%
Ваше приложение даже не заметит подмены. Та же база, те же драйверы — просто теперь летает.

Но есть и подводные камни

❗️ Физические пределы
Как бы вы ни прокачивали свой внедорожник, он никогда не станет космическим кораблём. Максимум RAM в одном сервере — около 6 ТБ (и это будет стоить как небольшой самолёт).

❗️ Цена растёт экспоненциально с увеличением мощности
Первые 32 ГБ RAM — 200. Следующие 32ГБ — уже 300. А когда добираетесь до 1 ТБ — каждая добавленная планта памяти увеличивает стоимость на тысячи долларов.

❗️ «Я упал — все упали»
Один сервер = одна точка отказа. Если он отвалится, поминай как звали.

❗️ Апгрейд = downtime
Чтобы добавить памяти, часто нужно выключать сервер. Для многих систем даже небольшая недоступность критически важных сервисов недопустима.

Когда вертикальное масштабирование — идеальный выбор?

1. Стартапы на этапе роста
   Пока у вас 50-100 тысяч пользователей — проще раз в полгода переезжать на сервер мощнее.

2. Системы с предсказуемой нагрузкой
   Если у вас нет резких скачков трафика (как во время Черной пятницы), вертикальное масштабирование покрывает все нужды.

3. Когда важна простота
   Нет команды DevOps? Нет времени на настройку кластеров? Scale-up спасает ситуацию.

Кейс

Один интернет-магазин столкнулся с проблемой: их PostgreSQL начал захлебываться при RPS == 5000 (запросов в секунду). Решение?

• Было: Сервер с 16 ядрами CPU, 64 ГБ RAM, HDD

• Стало: 32 ядра, 256 ГБ RAM, NVMe

Результат?

• Время отклика упало с 1200 мс до 90 мс;

• Стоимость сервера выросла в 3 раза;

• Но! Разработчики потратили время на миграцию. К счастью, всего 2 дня.

Для сравнения: выполнение шардирования потребовало бы 2-3 месяца работы и увеличение штата на двух инженеров.

Вертикальное масштабирование — как костыль, который иногда превращается в супер-протез. Да, у него есть пределы, но часто именно оно становится самым быстрым и экономичным решением. 

2. Горизонтальное масштабирование (Scale Out): путь современных высоконагруженных систем

Что значит «добавить сервер»?

Это как превратить уютную кофейню в сеть ресторанов. Есть три основных способа оптимизации:

1. Репликация (клонирование)
   Создаем копии главного сервера. Заказы принимает только шеф-повар (master), но готовить помогают другие повара (replicas). Клиенты получают блюда быстрее, ведь официанты (requests) для приготовления своего заказа могут найти любого свободного повара.

2. Шардинг (разделение меню)
   Даем клиентам возможность посещать разный набор ресторанов: в первом подают суши, во втором — пиццу, в третьем — стейки. Каждый повар специализируется на своём блюде (шарде данных), за счет чего можно достичь увеличения необходимых показателей.

3. Кластеризация (франшиза по доставке еды)
   Сеть ресторанов с единым стандартом. Каждый может принимать заказы, а данные синхронизируются и маршрутизируются между всеми точками в соответствии с установленными параметрами.

Почему крупные компании выбирают scale-out?

✅ Масштабируемость до бесконечности
Нужно больше мощности? Просто добавьте ещё серверов. Технически ограничений нет — Facebook использует десятки тысяч серверов для своих баз данных.

✅ Отказоустойчивость
Упал один сервер? Система даже не заметит. Данные хранятся в нескольких экземплярах, как важные документы в сейфе с дубликатами.

✅ Экономия на железе
10 серверов по 5 тыс долларов часто дешевле одного за 100 тыс долларов.

✅ Гибкость распределения нагрузки
Пик активности в Азии? Увеличиваем количество серверов в Сингапуре. Ночью можно часть выключить для экономии.

Но не все так просто

❗️ Архитектурная головная боль
Теперь ваше приложение должно понимать:

• куда писать новые данные;

• откуда читать актуальную информацию;

• как работать с транзакциями между серверами.

❗️ CAP-теорема — приходится выбирать
Как в том анекдоте про «быстро, дёшево, качественно» — можно выбрать только два из трёх:

• Консистентность (все данные актуальны);

• Доступность (система всегда отвечает);

• Устойчивость к разделению (работает при обрывах связи).

❗️ Сложность администрирования
Теперь нужно следить не за одним сервером, а за целым зоопарком. Автоматизация становится must-have.

❗️ Особенности шардинга
Cross-shard запросы как заказ комплексного обеда из разных ресторанов. Сложно, долго, иногда блюда приходят в разное время.

Когда горизонтальное масштабирование — идеальный выбор?

1. Высоконагруженные сервисы
   Соцсети, маркетплейсы, SaaS-платформы — где десятки тысяч запросов в секунду.

2. Глобальные проекты
   Нужно размещать данные ближе к пользователям в разных регионах.

3. Критически важные системы
   Когда простой недопустим даже на минуту — банки, платежные системы.

Кейс

Один игровой сервис столкнулся с проблемой: 2 млн активных пользователей ежедневно, PostgreSQL не справлялся при RPS==5000. Решение?

1. Разделили данные по игровым регионам (шардинг)

2. Для каждого региона сделали 3 реплики

3. Настроили автоматическое переключение при сбоях

Результат:

• Пропускная способность выросла в 20 раз

• Задержки уменьшились с 2 секунд до 50 мс

• Отказоустойчивость — система переживет падение любого из серверов

Правда, пришлось:

• Переписать 30% кода приложения

• Нанять двух DevOps-инженеров

• Внедрить сложную систему мониторинга

Горизонтальное масштабирование — как переход от ларька с шаурмой к сети ресторанов. Сложнее управлять, зато нет ограничений по масштабированию. Главное — правильно выбрать стратегию (Репликация, шардинг или кластер. А может и вовсе решение, совмещающее приведенные механизмы) и быть готовым к новым архитектурным вызовам.

Вертикальное vs горизонтальное масштабирование

Критерий	🔼 Вертикальное масштабирование	↔️ Горизонтальное масштабирование
Принцип работы	"Вырасти выше" Апгрейд одного сервера	"Расширяйся шире" Добавление новых узлов
Скорость внедрения	🟢 Быстро (дни) Замена железа	🟡 Долго  (недели/месяцы) Изменение архитектуры и кодовой базы
Макс. мощность	🔴 Жесткие ограничения Физические лимиты железа	🟢 Безгранично Можно добавлять узлы бесконечно. Если сможете за ними уследить
Отказоустойчивость	🔴 Единая точка отказа Сбой сервера критичен и приводит к недоступности	🟢 Автовосстановление Работает при падении узлов
Экономика	🔴 Дорогой апгрейд Цена растет экспоненциально	🟢 Линейные затраты Экономия на массовости
Администрирование	🟢 Простое 1 сервер = 1 точка управления	🔴 Сложное Требует оркестрации и тех. поддержания
Изменения кода	🟢 Минимальные Часто не требуются	🔴 Значительные Поддержка распределенности
Идеальный кейс	Стартапы Средние нагрузки MVP	Highload-системы Глобальные проекты Критически-важные сервисы

Репликация данных: как создать непотопляемую систему-броненосец

После сравнения подходов становится ясно: горизонтальное масштабирование — это не только про мощность, но и про надежность. И здесь на первый план выходит репликация — технология, которая:

• Делает вашу БД практически неуязвимой к сбоям;

• Ускоряет чтение в десятки раз;

• Позволяет пережить даже падение дата-центра.

Почему это важно?

Представьте, что ваша база данных — это единственный экземпляр важного документа. Если он потеряется или будет поврежден — катастрофа неизбежна. Репликация решает эту проблему, создавая несколько синхронизированных копий данных. Это как сделать нотариально заверенные копии паспорта и хранить их в разных местах.

Что такое репликация на практике?

Это процесс автоматического копирования данных с главного сервера (мастера) на подчинённые (реплики).

Как это работает на примере кейса с рестораном, который был рассмотрен в рамках предыдущей статьи:

1. Управляющая компания (мастер) получает поставку расходных материалов, приуроченных к новому году (новую информацию);

2. Он сразу рассылает её во все филиалы (реплики);

3. Клиент может обратиться в любой филиал и получить продукт в сезонной упаковке, на которой он найдет приятное поздравление с новым годом.

Основные типы репликации: как выбрать правильный подход

Окей, поиграем с аналогиями еще. Представьте, что вы капитан корабля, перевозящего ценный груз (данные). Можно отправить его:

1. С охраной, которая подтвердит доставку (синхронная репликация);

2. Быстро, но без гарантий (асинхронная репликация);

3. С частичным сопровождением (полусинхронная репликация).

Выбор типа репликации определяет, насколько надёжно и быстро будут доставлены ваши данные. Давайте разберем каждый вариант.

Синхронная репликация: надёжность прежде всего

Как работает:
Мастер ждёт подтверждения от ВСЕХ реплик перед завершением операции записи. Это как отправка документов с курьером, который требует подпись о получении в каждом отделении.

Техническая реализация в PostgreSQL:

synchronous_standby_names = 'FIRST 2 (node1, node2, node3)'

Плюсы:

✅ Полная гарантия сохранности данных;

✅ Простота аварийного восстановления.

Минусы:

❗️ Большие временные задержки (200-500 мс);

❗️Процессы в системе могут быть приостановлены при проблемах с репликами;

❗️ Ограниченная геораспределенность.

Пример из практики:
В банковской системе при 3 синхронных репликах:

• Обычная задержка перевода: 300 мс;

• При падении одной реплики: система продолжает работать;

• При падении двух: переводы временно блокируются.

Асинхронная репликация: скорость любой ценой

Как работает:
Мастер записывает данные локально и сразу отвечает клиенту. Реплики обновляются в фоновом режиме. Это как отправить письмо по электронной почте — вы знаете, что оно дойдёт, но не знаете когда и будет ли оно прочитано.

Настройка в MySQL:

CHANGE MASTER TO MASTER_DELAY = 3600; -- Задержка репликации 1 час

Плюсы:

✅ Минимальные задержки (1-5 мс);

✅ Работает при любых проблемах с репликами;

✅ Идеально для географического распределения.

Минусы:

❗️ Возможна потеря последних данных;

❗️ Сложное восстановление после аварий;

❗️ Время обновления для каждой из реплик может быть разным.

Реальный кейс:
Пользователь публикует контент от своего имени:

• Он же сможет видеть его сразу после отправки;

• Подписчики могут увидеть его с задержкой 2-5 сек;

• При аварии возможна всего контента, опубликованного за последние 5 минут.

Полусинхронная репликация: золотая середина

Как работает:
Мастер ждёт подтверждения только от N реплик (обычно 1-2). Это как отправка документов с требованием хотя бы одного подтверждения о получении.

Конфигурация в MySQL:

rpl_semi_sync_master_wait_for_slave_count = 1

Плюсы:

✅ Разумный баланс скорости и надёжности;

✅ Частичная защита от потерь данных;

✅ Хорошая геораспределенность.

Минусы:

❗️ Более сложная настройка;

❗️ Нужен мониторинг работы всех реплик, особое внимание к «отстающим»;

❗️ Возможная потеря данных.

Пример использования:
Предположим, мы реализовали данный механизм для интернет-магазина:

• Подтверждение заказа происходит после сохранения в мастере и одной реплике;

• Задержка около 50-100 мс;

• Потеря данных возможна только при одновременном падении мастера и основной реплики.

Как выбрать тип репликации?

1. Для финансовых систем → Синхронная
   Пример: Банковские переводы, где важен каждый бит данных

2. Для соцсетей/аналитики → Асинхронная
   Пример: Лента новостей, где скорость важнее актуальности

3. Для e-commerce → Полусинхронная
   Пример: Корзина покупок, где нужен баланс скорости и надёжности

Совет: Современные СУБД позволяют комбинировать разные типы репликации для разных таблиц!

Выбор типа репликации — это всегда компромисс между:

• Скоростью (асинхронная);

• Надежностью (синхронная);

• Балансом (полусинхронная).

Как опытный капитан, вы должны выбрать оптимальный маршрут для своего ценного груза данных. Правильный выбор сделает вашу систему быстрой, надежной и устойчивой к штормам.

Почему репликация — must have для серьёзных проектов?

✅ Живучесть системы
При падении мастера одна из реплик мгновенно берет управление на себя. Как в авиации — если пилот теряет сознание, его сразу заменяет второй пилот.

✅ Молниеносное чтение данных
Запросы можно распределять по всем репликам. Представьте магазин, где 100 кассиров вместо одного. Разница очевидна!

✅ Географическая независимость
Данные можно разместить ближе к пользователям. Для москвичей — сервер в Москве, для жителей Владивостока — во Владивостоке.

✅ Безболезненное обновление
Можно выводить мастера на обслуживание без остановки работы — система автоматически переключится на реплики.

Тёмная сторона репликации

❗️ Головная боль с синхронизацией
Когда реплики отстают от мастера, пользователи могут видеть устаревшие данные. Представьте, что баланс на карте обновляется с задержкой в 5 минут… Приятного тут явно мало!

❗️ Дорогое удовольствие
Каждая реплика требует ресурсов. В некоторых случаях эти затраты нецелесообразны.

❗️ Сложность настройки
Нужно грамотно настроить параметры репликации, иначе можно получить "мёртвые" реплики, которые не успевают за мастером.

Когда репликация спасает проект?

1. Высоконагруженные сервисы
   Соцсети, где чтений в 100 раз больше, чем обновления/создания записей

2. Системы, работающие с критически важными данными
   Банки, биржи, медицинские учреждения

3. Глобальные проекты
   Сервисы с пользователями в разных часовых поясах

Репликация — это страховой полис для ваших данных. Она требует инвестиций и грамотной настройки, но когда случается беда, вы понимаете, что каждая копейка была потрачена не зря. 

Итог

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

Да, в некоторых случаях легче, быстрее и даже правильнее будет просто «накинуть железа», но по-настоящему мощные системы сложно создать без грамотного проектирования и применения методов репликации и шардирования – подхода, при котором данные и нагрузка распределяются между несколькими узлами. Мы рассмотрим устройство шардинга, кейсы для внедрения и сложности, с которыми придется столкнуться. 

А пока давайте обсудим, как вы решаете проблему «внезапного» роста нагрузки и объёма данных. Буду рад узнать про Ваш опыт в комментариях!