Масштабирование БД: Репликация или Шардирование?
Ваш стартап взлетел. Но радость сменяется паникой: база данных "задыхается". CPU в полке, запросы висят по 5 секунд. Просто "добавить RAM" уже не помогает. Пришло время выбирать архитектурную пилюлю: Репликация или Шардирование?
Дилемма архитектора
Выбор стратегии зависит от того, где именно у вас "узкое место": в чтении (Read) или записи (Write).
Рис 1. Слева: Master-Slave Репликация. Справа: Горизонтальное Шардирование.
1. Репликация (Replication): Масштабируем Чтение
Суть: У вас есть один "Босс" (Master), который принимает все изменения, и много "Подчиненных" (Slaves), которые только отдают данные.
- Когда применять: 80-90% нагрузки — это чтение (Read-heavy). Типично для СМИ, блогов, e-commerce каталогов.
- Плюсы: Легко настроить (PostgreSQL Streaming Replication, MySQL Binlog). Данные дублируются (бэкап).
- Минусы: Задержка репликации (Replication Lag). Вы записали данные на Master, но на Slave они появятся через 100мс. Пользователь может не увидеть свой комментарий сразу.
2. Шардирование (Sharding): Масштабируем Запись
Суть: Master не справляется с записью. Мы режем базу на куски. Пользователи A-M едут на Сервер 1, N-Z на Сервер 2.
- Когда применять: Данных так много, что они не влезают на один диск. Или когда один Master не успевает писать (Write-heavy).
- Плюсы: Теоретически бесконечное масштабирование.
- Минусы: Это больно. Вы теряете транзакции ACID между шардами. Вы теряете JOIN (как соединить таблицу с Сервера 1 и Сервера 2?). Бэкапы становятся ночным кошмаром.
Вердикт NineLab
Золотое правило: Откладывайте шардирование до последнего. Это "ядерная кнопка".
Сначала — индексы. Затем — кэширование (Redis). Затем — репликация. И только если у вас трафик уровня Telegram или Uber — шардирование. Не усложняйте архитектуру раньше времени.
Сервисы и материалы по теме
Частые вопросы по теме
Профиль трафика и данные на стенде редко совпадают с боем. Нужны сценарии, те же метрики, что в проде, и поэтапное наращивание с возможностью отката.
Часто первыми «краснеют» база и планы запросов, пулы соединений, синхронные вызовы внешних API и очереди — это даёт быстрый чек-лист проверки.
Не обязательно: инвалидация, холодный старт и неравномерность ключей могут навредить. Кэш проектируют под конкретные read-модели и SLO.
Когда вертикальное масштабирование и оптимизация запросов упёрлись в потолок, а рост данных предсказуем по ключу партиционирования.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Микросервисы для маркетплейса: когда это необходимость, а когда — лишние миллионы
Рамка решения для CEO и CTO: 5 сигналов, что пора дробить систему, 4 признака преждевременного перехода и честный расчёт — сколько стоит «архитектура как у Ozon» на старте маркетплейса.
Читать статьюRedis, очереди и кэширование: как сделать сайт в 10 раз быстрее без покупки нового железа
Разбираем, почему сайт тормозит при «нормальном» сервере, что кешировать в Redis, какие задачи уводить в очереди, когда подключать CDN — и какие цифры ждать после оптимизации без роста счёта за хостинг.
Читать статьюСколько стоит 1 час простоя вашего сайта: считаем на конкретных примерах
Формула расчёта стоимости простоя для e-commerce, B2B и SaaS: прямые и скрытые потери, коэффициент пика и чеклист подготовки к инцидентам. С привязкой к реальным сбоям инфраструктуры в 2026 году.
Читать статьюРеклама на 10 миллионов и ошибка 503: как техническая неготовность сжигает маркетинговые бюджеты
Разбираем, почему рекламные кампании сгорают из-за упавшего сайта: считаем реальные потери, объясняем три системные причины и даём чеклист подготовки инфраструктуры перед крупным запуском.
Читать статью