Репликация или шардирование БД: когда что выбрать
Ваш стартап взлетел. Но радость сменяется паникой: база данных "задыхается". 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 — шардирование. Не усложняйте архитектуру раньше времени.
Что дальше
Разберём вашу нагрузку и узкие места: high-load под ключ, нагрузочное тестирование или квиз оценки за 2 минуты.
Сервисы и материалы по теме
Репликация или шардирование — вопросы
Если узкое место — чтение (каталог, СМИ, витрина) — сначала реплики (master + slaves). Если не влезает запись или диск одного мастера — шарды. RAM «ещё чуть-чуть» не лечит ни то ни другое, когда CPU уже в полке.
Пока 80–90% нагрузки — SELECT, а мастер успевает писать. PostgreSQL streaming или MySQL binlog закрывают чтение. Минус — replication lag: пользователь может не сразу увидеть свою запись на слейве.
Теряете JOIN и транзакции ACID между шардами, бэкапы и миграции усложняются. Резать по ключу стоит, когда данные или запись реально не помещаются на один узел — не «на вырост с первого дня».
Снять профиль: read vs write, медленные запросы, индексы, кеш. Часто хватает реплики и Redis, а не шардов. Шард — следующий шаг после исчерпания чтения со слейвов.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Как мы готовим проект к HighLoad: взгляд на систему до пика
Метод NineLab: как смотрим на проект перед HighLoad — цель нагрузки, модель пика, карта узких мест, порядок правок и проверка стресс-тестом до рекламы.
Читать статьюЛК клиента B2B: MVP из 7 экранов, которые реально открывают
Личный кабинет клиента B2B: какие 7 экранов нужны в MVP, что отложить на v2, ориентир сроков и бюджета и чеклист приёмки для дилерского / партнёрского портала.
Читать статьюКак мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот
Как устроен поиск компаний в Найде (asknayda.ru): OpenSearch, модель bge-m3, когда включается семантический слой, RRF-гибрид и стадия пилота продукта.
Читать статьюSEO больше не хватит: магазину нужны API под ИИ-агентов
SEO находит клиента, API даёт ИИ-агенту купить. OpenAPI для e-commerce и МСБ: чеклист контура, риски в ₽ и рамка «когда пора».
Читать статью