Как бы вы шардировали базу данных на 1 миллиард пользователей?

Question

IT Interview Practice · Accepted Answer

Шардируйте по ключу, который **присутствует почти в каждом запросе и равномерно распределяет нагрузку** — обычно хешированный `user_id` — и с первого дня планируйте ре-шардинг и кросс-шардовые запросы. 1 млрд пользователей не поместится и не будет работать на одном узле; вы распределяете строки по многим базам и направляете каждый запрос на шард, которому они принадлежат.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Выбор shard key — решение, которое трудно отменить

Выбирайте ключ с **высокой кардинальностью, равномерным распределением и присутствием в большинстве запросов**. `user_id` обычно побеждает: user-scoped запросы («мой профиль, мои заказы») попадают ровно на один шард. Плохой ключ (например, `country`) создаёт hotspot — один шард держит всю Индию, пока другой простаивает.

## Hash против range

- **Hash-шардинг** (`shard = hash(user_id) % N`): распределяет равномерно, убивает hotspot — но диапазонные запросы («пользователи, созданные на прошлой неделе») вынуждены делать scatter-gather по всем шардам.
- **Range-шардинг** (`user_id 0–1M → shard 0`): держит диапазоны локальными и упрощает ре-шардинг, но рискует hotspot (новейшие пользователи все падают на последний шард).
- Частый ответ: **hash для равной нагрузки**, с **lookup/directory-таблицей**, чтобы можно было перемещать диапазоны без полного рехеширования.

## Ре-шардинг — планируйте до того, как понадобится

`% N` — ловушка: добавление одного шарда перераспределяет почти каждый ключ. Используйте **consistent hashing** или **виртуальные бакеты** (ключи → 4096 логических бакетов → физические шарды). Разделение шарда тогда перемещает бакеты, а не всё пространство ключей. Инструменты вроде **Vitess** (используется YouTube/Slack) автоматизируют live-ре-шардинг с cutover.

## Кросс-шардовые запросы

Всё, что не по shard key, болезненно: глобальный запрос «топ постов» разлетается на каждый шард и мержится. Смягчайте **денормализацией** или отдельным индексом/поисковым хранилищем (Elasticsearch) для кросс-секущих чтений.

## Взгляд с точки зрения интервью

Интервьюеры прощупывают, понимаете ли вы, что выбор shard key **полупостоянен**, и думали ли вы о **ре-шардинге и кросс-шардовых join** — двух вещах, которые кусаются в продакшене. Хорошо: «шардировать по user_id». Отлично: вы поднимаете consistent hashing, смягчение горячего шарда и тот факт, что распределённых транзакций между шардами лучше избегать полностью.

**Частая ловушка:** `hash % N` с фиксированным N — это превращает будущий рост в полную миграцию данных.

## Компромиссы и режимы отказа

- **Потеря кросс-шардового ACID:** нет дешёвых join/транзакций между шардами; используйте саги или денормализацию.
- **Горячий шард:** вирусный пользователь; суб-шардируйте или кэшируйте эту сущность.
- **Риск ребалансировки:** live-миграция должна писать дважды (double-write) и проверять перед cutover.
- **Операционная стоимость:** N шардов × реплики = много баз для мониторинга, бэкапа и failover.

Выбор shard key — решение, которое трудно отменить

Hash против range

Ре-шардинг — планируйте до того, как понадобится

Кросс-шардовые запросы

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы