Что такое Database Sharding по сравнению с Read Replicas? Когда пора переносить часть данных на другой физический сервер?
## Database Sharding и Read Replicas: в чём разница?
Оба подхода решают проблему масштабирования базы данных, но делают это принципиально по-разному.
### Read Replicas (реплики чтения)
Read Replica — это полная копия основной базы данных (master/primary), которая принимает только запросы на чтение (SELECT). Запись по-прежнему идёт на основной узел, а изменения асинхронно или синхронно реплицируются на реплики.
**Когда помогает:**
— Нагрузка на чтение значительно превышает нагрузку на запись (типичное соотношение 80/20 или 90/10).
— Нужно снизить нагрузку на основной сервер без изменения схемы данных.
— Требуется географическое распределение (реплика в другом регионе для низкой латентности).
**Ограничения:**
— Не решает проблему объёма данных — вся БД по-прежнему хранится целиком на каждом узле.
— Запись масштабируется слабо — всё равно упирается в один master.
— Возможна задержка репликации (replication lag), что может приводить к чтению устаревших данных.
### Database Sharding (горизонтальное секционирование)
Шардинг — это разбиение данных на независимые фрагменты (шарды), каждый из которых хранится на отдельном физическом или логическом сервере. Каждый шард содержит только часть данных, а не всю базу целиком.
**Типичные стратегии шардинга:**
— **По диапазону (range-based):** user_id от 1 до 1 000 000 — шард 1, от 1 000 001 до 2 000 000 — шард 2.
— **По хэшу (hash-based):** hash(user_id) % N определяет номер шарда.
— **По географии или бизнес-логике:** данные европейских пользователей — в EU-шарде, американских — в US-шарде.
**Когда помогает:**
— Объём данных превышает возможности одного сервера (терабайты и выше).
— Нагрузка на запись слишком высока для одного узла.
— Нужна горизонтальная масштабируемость без ограничений.
**Ограничения:**
— Значительно усложняет архитектуру: JOIN между шардами дорог или невозможен.
— Транзакции между шардами требуют распределённых протоколов (2PC, Saga).
— Перебалансировка шардов при росте — сложная операция.
—
## Когда пора переносить данные на другой физический сервер?
Ориентируйтесь на следующие сигналы:
1. **CPU/RAM сервера постоянно загружены выше 70–80%** даже после оптимизации запросов и индексов.
2. **Время ответа на запросы растёт** несмотря на кэширование и оптимизацию.
3. **Объём данных приближается к физическому пределу** диска или начинает влиять на производительность (например, таблицы с сотнями миллионов строк без секционирования).
4. **IOPS диска исчерпан** — даже SSD не справляется с количеством операций ввода-вывода.
5. **Replication lag на репликах растёт** — значит, master перегружен записью.
**Рекомендуемая последовательность масштабирования:**
1. Оптимизация запросов и индексов.
2. Кэширование (Redis, Memcached).
3. Вертикальное масштабирование (upgrade сервера).
4. Добавление Read Replicas.
5. Партиционирование таблиц (на одном сервере).
6. Шардинг (разнесение на несколько серверов).
Шардинг — крайняя мера. Переходите к нему только тогда, когда остальные методы исчерпаны, так как он кардинально усложняет разработку и эксплуатацию.