Что такое Database Sharding и в каких случаях его стоит применять для масштабирования высоконагруженных проектов?

Database Sharding (шардирование баз данных) — это техника горизонтального масштабирования, при которой данные разбиваются на несколько независимых частей (шардов), каждый из которых хранится на отдельном сервере или узле. В отличие от вертикального масштабирования (увеличения мощности одного сервера), шардирование позволяет распределить нагрузку между множеством машин, преодолевая физические ограничения одного узла.

**Как работает шардирование?**

Каждый шард содержит подмножество данных всей базы. Например, пользователи с ID от 1 до 1 000 000 хранятся на шарде A, с ID от 1 000 001 до 2 000 000 — на шарде B и так далее. Для маршрутизации запросов к нужному шарду используется шард-ключ (shard key) — поле или набор полей, по которым определяется, на каком шарде находятся данные. Распределение может быть:

— **Диапазонным (Range-based)** — данные делятся по диапазонам значений ключа.
— **Хэш-based** — применяется хэш-функция к ключу, результат определяет шард.
— **Географическим (Geo-based)** — данные распределяются по регионам.
— **Справочным (Directory-based)** — отдельная таблица маппинга хранит информацию о расположении данных.

**Когда стоит применять шардирование?**

1. **Объём данных превышает возможности одного сервера** — когда база данных достигает сотен гигабайт или терабайт и вертикальное масштабирование становится нецелесообразным по стоимости.
2. **Высокая нагрузка на запись и чтение** — если один сервер не справляется с потоком транзакций (тысячи и десятки тысяч операций в секунду).
3. **Необходимость географического распределения** — для снижения латентности пользователей из разных регионов.
4. **Требования к отказоустойчивости** — выход из строя одного шарда не парализует всю систему.

**Недостатки и сложности шардирования**

Шардирование существенно усложняет архитектуру. Основные проблемы:
— Сложность выполнения JOIN-запросов между шардами.
— Трудности с поддержкой транзакционности (ACID) между несколькими шардами.
— Неравномерное распределение данных (hotspot-проблема) при неправильном выборе шард-ключа.
— Сложность ребалансировки при добавлении новых шардов.

**Альтернативы перед шардированием**

Прежде чем переходить к шардированию, стоит рассмотреть: оптимизацию запросов и индексов, кэширование (Redis, Memcached), репликацию с read-репликами, партиционирование таблиц внутри одной БД.

Шардирование применяют такие компании, как Instagram, Pinterest, Airbnb. Поддержку шардирования предлагают MongoDB, Cassandra, MySQL Cluster, Vitess (для MySQL) и другие решения.