Шардирование БД без боли: когда пора и как не пожалеть

Шардирование решает реальные bottleneck, но ломает простые операции навсегда.

Ключевой принцип: сначала исчерпать вертикальные и логические оптимизации, потом шардировать.

Проще говоря

Как принять решение о шардировании на основе метрик, а не хайпа: практический план миграции и контроль рисков. Ниже — что именно делать на практике и где чаще всего ошибаются.

Признаки, что пора обсуждать шарды

• один кластер стабильно у потолка CPU/IOPS,
• hot partitions не лечатся индексами/архивом,
• read-replica уже не спасают путь записи,
• рост данных/трафика прогнозно «ломает» SLA в горизонте 6–12 месяцев.

Что проверить до старта

1. Можно ли разделить домен логически (tenant/region/account)?
2. Есть ли явный shard key с равномерным распределением?
3. Сколько критичных cross-shard запросов останется?
4. Готовы ли процессы миграций/backfill/repair?

Как это выглядит в реальном проекте

Коротко про вводные.

Контекст: SaaS с B2B-tenant моделью: один Postgres-кластер упёрся в write IOPS, p95 вырос до 900ms.

Что сделали:

• выбрали shard key = tenant_id;
• вынесли 20 крупнейших tenant-ов в отдельные шарды;
• ввели routing layer и запретили cross-shard join в product-path;
• nightly reconciliation для отчётов.

Результат:

p95 вернулся к 240ms, write headroom +65%.

Частые ошибки

• шардируют по автоинкрементному id,
• оставляют бизнес-критичные cross-shard транзакции,
• нет инструментов rebalance,
• нет единой наблюдаемость по shard health.

План миграции

• Фаза 1: shadow reads + dual writes на ограниченном сегменте,
• Фаза 2: cutover для части трафика,
• Фаза 3: поэтапный перенос оставшихся сегментов,
• Фаза 4: cleanup старый контур-маршрутов.

Короткая история из команды

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

Вывод

Шардирование должно быть экономическим решением с ясным профитом по SLA/стоимости.

Если делать его как «архитектурный апгрейд ради апгрейда», цена поддержки съест выигрыш.

Термины простыми словами

• SLA/SLI/SLO — договорённость о качестве сервиса: что измеряем, какой целевой уровень и какие последствия при деградации.
• Sharding — горизонтальное разделение данных на сегменты (шарды), чтобы масштабировать хранение и запись.
• Multi-tenant — модель, где одна система обслуживает несколько клиентов (tenant-ов) с логической изоляцией данных и доступа.
• ADR (Architecture Decision Record) — короткая запись архитектурного решения: контекст, выбор и последствия.
• Наблюдаемость — способность понимать внутреннее состояние системы по логам, метрикам и трассировкам.

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

Как применять это в живом проекте

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

Хорошая последовательность: сначала фиксируем baseline, затем внедряем минимально жизнеспособную версию решения, после чего смотрим на метрики 1–2 недели. Если эффект подтверждается, масштабируем на соседние сценарии. Если нет — откатываем без драм и пересобираем гипотезу.