Масштабирование БД: Репликация или Шардирование?
Ваш стартап взлетел. Но радость сменяется паникой: база данных "задыхается". 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 минуты.
Сервисы и материалы по теме
Частые вопросы по теме
Профиль трафика и данные на стенде редко совпадают с боем. Нужны сценарии, те же метрики, что в проде, и поэтапное наращивание с возможностью отката.
Часто первыми «краснеют» база и планы запросов, пулы соединений, синхронные вызовы внешних API и очереди — это даёт быстрый чек-лист проверки.
Не обязательно: инвалидация, холодный старт и неравномерность ключей могут навредить. Кэш проектируют под конкретные read-модели и SLO.
Когда вертикальное масштабирование и оптимизация запросов упёрлись в потолок, а рост данных предсказуем по ключу партиционирования.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
SEO больше не хватит: магазину нужны API под ИИ-агентов
SEO находит клиента, API даёт ИИ-агенту купить. OpenAPI для e-commerce и МСБ: чеклист контура, риски в ₽ и рамка «когда пора».
Читать статьюПиковый сезон: чеклист нагрузки за месяц до акции
Пиковый сезон и чеклист нагрузки за месяц до акции: план по неделям, расчёт потерь в ₽ при 503 и подготовка сайта к Чёрной пятнице и рекламному всплеску.
Читать статьюNo-code vs кастомная разработка: где ловушка масштабирования
No-code и low-code vs кастомная разработка: когда платформа ускоряет старт, где ловушка масштаба, сравнение TCO в ₽ и чеклист миграции для CEO и CTO.
Читать статьюMVP SaaS за 2 месяца: реальный scope и сроки запуска
Разработка MVP SaaS за 2 месяца: что войти в scope, бюджет от 1,5 млн ₽, план по неделям и чеклист приёмки для CEO и продукта без раздутого ТЗ.
Читать статью