Jak byste shardovali databázi pro 1 miliardu uživatelů?

Question

IT Interview Practice · Accepted Answer

Shardujte podle klíče, který je **přítomen téměř v každém dotazu a rozprostírá zátěž rovnoměrně** — obvykle hashovaný `user_id` — a od prvního dne plánujte resharding a cross-shard dotazy. 1 miliarda uživatelů se nevejde ani nebude výkonná na jednom nodu; řádky rozdělíte přes mnoho databází a každý dotaz směrujete na shard, který ho vlastní.

```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
```

## Volba shard key — rozhodnutí, které se těžko vrací

Volte klíč s **vysokou kardinalitou, rovnoměrným rozložením a přítomností ve většině dotazů**. `user_id` obvykle vyhrává: dotazy vázané na uživatele („můj profil, mé objednávky“) zasáhnou přesně jeden shard. Špatný klíč (např. `country`) tvoří hotspoty — jeden shard drží celou Indii, zatímco jiný zahálí.

## Hash vs range

- **Hash sharding** (`shard = hash(user_id) % N`): rozprostírá rovnoměrně, zabíjí hotspoty — ale range dotazy („uživatelé vytvoření minulý týden“) musí dělat scatter-gather přes všechny shardy.
- **Range sharding** (`user_id 0–1M → shard 0`): drží rozsahy lokální a usnadňuje resharding, ale riskuje hotspoty (nejnovější uživatelé dopadnou všichni na poslední shard).
- Častá odpověď: **hash kvůli rovnoměrné zátěži**, s **lookup/directory tabulkou**, abyste mohli přesouvat rozsahy bez rehashování všeho.

## Resharding — plánujte dřív, než ho budete potřebovat

`% N` je past: přidání jednoho shardu přemapuje téměř každý klíč. Použijte **consistent hashing** nebo **virtuální buckety** (mapujte klíče → 4096 logických bucketů → fyzické shardy). Rozdělení shardu pak přesune buckety, ne celý keyspace. Nástroje jako **Vitess** (používaný YouTube/Slackem) automatizují živý resharding s cutoverem.

## Cross-shard dotazy

Cokoli neklíčované shard klíčem je bolestivé: globální dotaz „top posts“ se rozvětví na každý shard a slévá. Zmírníte to **denormalizací** nebo držením samostatného index/search storu (Elasticsearch) pro průřezová čtení.

## Pohled z pohovoru

Tazatelé zkoumají, zda chápete, že volba shard key je **polopermanentní** a zda jste přemýšleli o **reshardingu a cross-shard joinech** — dvou věcech, které v produkci koušou. Dobré: „shardujte podle user_id.“ Skvělé: zmíníte consistent hashing, zmírnění hot shardu a fakt, že distribuovaným transakcím napříč shardy je nejlepší se úplně vyhnout.

**Častá past:** `hash % N` s pevným N — z budoucího růstu udělá plnou migraci dat.

## Kompromisy a režimy selhání

- **Ztracené cross-shard ACID:** žádné levné joiny/transakce napříč shardy; použijte sagy nebo denormalizujte.
- **Hot shard:** virální uživatel; sub-shardujte nebo tuto entitu nacachujte.
- **Riziko rebalancingu:** živá migrace musí dvojitě zapisovat a ověřovat před cutoverem.
- **Provozní náklady:** N shardů × repliky = mnoho databází k monitorování, zálohování a failoveru.

Volba shard key — rozhodnutí, které se těžko vrací

Hash vs range

Resharding — plánujte dřív, než ho budete potřebovat

Cross-shard dotazy

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky