Hogyan shardelnél egy adatbázist 1 milliárd felhasználóhoz?

Question

IT Interview Practice · Accepted Answer

Shardelj egy olyan kulcs szerint, amely **szinte minden lekérdezésben jelen van és egyenletesen teríti a terhelést** — általában egy hashelt `user_id` — majd tervezz reshardolásra és cross-shard lekérdezésekre az első naptól. 1 milliárd felhasználó nem fér el vagy nem teljesít egy node-on; sorokat osztasz szét sok adatbázis között és minden lekérdezést arra a shardra irányítasz, amelyik birtokolja.

```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 kulcs választás — a döntés, amit nehéz visszacsinálni

Válassz egy kulcsot **magas kardinalitással, egyenletes eloszlással, és a legtöbb lekérdezésben jelen lévővel**. A `user_id` általában nyer: a felhasználó-hatókörű lekérdezések ("a profilom, a rendeléseim") pontosan egy shardot érnek. Egy rossz kulcs (pl. `country`) hotspotokat hoz létre — egy shard tartja egész Indiát, míg egy másik tétlen.

## Hash vs range

- **Hash shardelés** (`shard = hash(user_id) % N`): egyenletesen terít, megöli a hotspotokat — de a tartomány-lekérdezéseknek ("múlt héten létrehozott felhasználók") scatter-gathert kell végezniük minden shardon át.
- **Range shardelés** (`user_id 0–1M → shard 0`): lokálisan tartja a tartományokat és megkönnyíti a reshardolást, de hotspotokat kockáztat (a legújabb felhasználók mind az utolsó shardra kerülnek).
- Gyakori válasz: **hash az egyenletes terhelésért**, egy **lookup/directory táblával**, hogy tartományokat mozgathass anélkül, hogy mindent újrahashelnél.

## Reshardolás — tervezz mielőtt szükséged lenne rá

A `% N` egy csapda: egy shard hozzáadása szinte minden kulcsot átképez. Használj **konzisztens hashelést** vagy **virtuális vödröket** (kulcsok → 4096 logikai vödör → fizikai shardok). Egy shard felosztása ekkor vödröket mozgat, nem az egész kulcsteret. Az olyan eszközök, mint a **Vitess** (a YouTube/Slack használja), automatizálják az élő reshardolást átkapcsolással.

## Cross-shard lekérdezések

Bármi, ami nem a shard kulcs szerint van kulcsolva, fájdalmas: egy globális "top posztok" lekérdezés minden shardra kifan-outol és merge-el. Enyhítsd **denormalizációval** vagy egy külön index/kereső store (Elasticsearch) fenntartásával a keresztmetsző olvasásokhoz.

## Interjú szemszög

Az interjúztatók azt vizsgálják, érted-e, hogy a shard-kulcs választás **félig-állandó**, és gondoltál-e a **reshardolásra és cross-shard joinokra** — a két dologra, ami éles környezetben megharap. Jó: "shardelj user_id szerint." Kiváló: felveted a konzisztens hashelést, a forró-shard enyhítést, és azt a tényt, hogy a shardok közötti elosztott tranzakciókat teljesen érdemes elkerülni.

**Gyakori csapda:** `hash % N` fix N-nel — a jövőbeli növekedést teljes adatmigrációvá teszi.

## Kompromisszumok és hibamódok

- **Elveszett cross-shard ACID:** nincs olcsó join/tranzakció shardok között; használj sagákat vagy denormalizálj.
- **Forró shard:** egy vírusos felhasználó; sub-shardelj vagy cache-eld azt az entitást.
- **Rebalancing kockázat:** az élő migrációnak duplán kell írnia és ellenőriznie az átkapcsolás előtt.
- **Üzemeltetési költség:** N shard × replika = sok adatbázis, amit monitorozni, menteni és failoverolni kell.

Shard kulcs választás — a döntés, amit nehéz visszacsinálni

Hash vs range

Reshardolás — tervezz mielőtt szükséged lenne rá

Cross-shard lekérdezések

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések