Co je dělení dat a sharding?

Question

Accepted Answer

**Dělení dat** (sharding) rozděluje data mezi více serverů/databází tak, aby každý held podmnožinu — umožňuje horizontální škálování dat a zátěže mimo jeden server. Volba způsobu dělení (klíč dělení a strategie) je kritická.

## Co je dělení/sharding

```text
PARTITIONING / SHARDING → divide data into pieces (partitions/shards) across multiple
servers, each holding a SUBSET:
  → no single server holds (or is overwhelmed by) all the data
  → scales STORAGE and LOAD horizontally (each shard handles its portion)
  → enables handling data/throughput beyond one machine's capacity
```

## Strategie dělení

```text
HASH-based → hash the partition key → assign to a shard:
  ✓ EVEN distribution (avoids hotspots)  ✗ range queries hard; resharding is tricky
RANGE-based → partition by value ranges (e.g. A-M, N-Z; date ranges):
  ✓ efficient range queries  ✗ risk of HOTSPOTS (uneven load if data/access is skewed)
DIRECTORY/lookup → a lookup table maps keys to shards (flexible, but the lookup is overhead)
GEOGRAPHIC → partition by region (data locality)
```

## Kritická volba: klíč dělení

```text
The PARTITION KEY (shard key) is the most important decision:
  ✓ HIGH CARDINALITY + EVEN distribution → spreads data/load evenly (no hot shards)
  ✓ Aligns with QUERY patterns → queries hit one shard (efficient) vs all (scatter-gather)
  ✗ A BAD key → hotspots (one shard overloaded), uneven data, or queries hitting all shards
  → hard to change later → choose carefully
```

## Výzvy

```text
⚠️ CROSS-SHARD queries/joins are hard (data spread across shards) and slow (scatter-gather)
⚠️ REBALANCING / adding shards is complex (moving data)
⚠️ Transactions across shards are difficult; hotspots; operational complexity
→ powerful for scale, but adds significant complexity → use when truly needed
```

## Proč je to důležité

Porozumění dělení dat a shardingu je cenné, protože jde o **klíčovou techniku pro škálování dat mimo jeden server**, kritickou výzvu pro velké systémy, takže jde o důležité znalosti při návrhu systémů.

Dělení/sharding — rozdělení dat mezi více serverů tak, aby každý held podmnožinu — umožňuje **horizontální škálování úložiště a zátěže** mimo kapacitu jednoho počítače, nezbytné, když data nebo propustnost překročí to, co jeden server zvládne.

Porozumění **strategiím** a jejich kompromisům — **na základě haše** (rovnoměrná distribuce vyhýbající se hotspotům, ale ztěžující range dotazy a přešardování), **na základě rozsahu** (efektivní range dotazy, ale riziko hotspotů ze zkreslenosti), na základě adresáře (flexibilní s overhead vyhledávání) a geografické — je nezbytné pro volbu způsobu dělení.

Nejdůležitější je pochopit, že **klíč dělení je nejdůležitější rozhodnutí** je klíčová myšlenka: dobrý klíč (vysokou kardinalitou, rovnoměrnou distribucí, sladěný se vzory dotazů tak, aby dotazy zasáhly jeden shard místo všech) rovnoměrně rozkládá zátěž a umožňuje efektivní dotazy, zatímco špatný klíč způsobuje hotspoty (jeden shard přetížený), nerovnoměrná data nebo scatter-gather dotazy — a protože je to těžké změnit později, pečlivá volba je nezbytná.

Porozumění **výzvám** — že dotazy a joiny mezi shardy jsou těžké a pomalé, vyvažování a přidání shardů je složité a transakce mezi shardy jsou obtížné — je důležité, protože to dělá sharding mocným, ale významně složitým, takže by měl být použit, když je to skutečně nutné (po jednodušších technikami škálování jako cachování a replikace).

Protože škálování dat mimo jeden server je kritická výzva pro velké systémy a dělení/sharding (s rozhodující volbou klíče dělení a jejími kompromisy a výzvami) je technika pro to, a protože porozumění strategiím, důležitosti klíče dělení a výzvám je důležité pro návrh velkých systémů, je porozumění dělení dat a shardingu cenné, prakticky relevantní znalosti při návrhu systémů — klíčová technika pro horizontální škálování dat vyžadující pečlivé porozumění strategiím dělení, kritické volbě klíče dělení a významným výzvám, a centrální pro navrhování systémů, které škálují data mimo kapacitu jednoho serveru.