Jak funguje sharding v MongoDB?

Question

Accepted Answer

**Sharding** je metoda MongoDB pro **horizontální škálování** — distribuce dat across multiple serverů (**shards**), takže se databáze může vypořádat s datovými sadami a propustností přesahující kapacitu jednoho serveru. Rozděluje data podle **shard key**, a MongoDB směruje dotazy ke správným shardům.

## Proč shardovat: škálování mimo jeden server

```text
A single server has limits (storage, RAM, write throughput). When data/load exceeds
what one server (even a powerful one) can handle, SHARDING distributes it:
  → data is split across multiple SHARDS (each a replica set)
  → each shard holds a SUBSET of the data → combined capacity scales horizontally
  → handles huge datasets and high write throughput
```

## Jak sharding funguje

```text
The sharded cluster has three parts:
  SHARDS    → each holds a portion of the data (each shard is itself a replica set)
  mongos    → query ROUTER — apps connect here; it routes queries to the right shard(s)
  CONFIG SERVERS → store metadata (which data is on which shard)

Data is partitioned by the SHARD KEY into CHUNKS, distributed across shards.
MongoDB balances chunks across shards automatically.
```

## Shard key — nejkritičtější rozhodnutí

```js
sh.shardCollection("mydb.orders", { customerId: 1 });   // shard by customerId
```

```text
The SHARD KEY determines how data is distributed — choosing it well is CRITICAL:
  ✓ HIGH CARDINALITY (many distinct values) → data spreads evenly
  ✓ EVEN DISTRIBUTION of reads/writes → no hot shards
  ✓ Queries include the shard key → routed to ONE shard (targeted, fast)
  ✗ A BAD shard key → uneven distribution (hotspots), or queries hitting ALL shards
    (scatter-gather, slow) → poor scaling. Hard to change later!
Strategies: ranged sharding, HASHED sharding (even distribution), zoned sharding.
```

## Cílené versus scatter-gather dotazy

```text
Query INCLUDES the shard key → routed to the specific shard(s) → fast (targeted)
Query WITHOUT the shard key → must query ALL shards (scatter-gather) → slower
→ Design the shard key around your common query patterns.
```

## Proč to důležité

Sharding je důležité znalosti pro **škálování MongoDB na velmi velké datové sady a vysokou propustnost**, proto je jeho pochopení cenné znalosti na úrovni senior pro velké MongoDB nasazení.

Hlavní hodnota je **horizontální škálování**: když data nebo zatížení překročí to, co zvládne jeden server, sharding distribuuje data across multiple shards, škáluje kapacitu horizontálně, aby zvládl obrovské datové sady a vysokou propustnost zápisu, kterou vertikální škálování (větší server) nedosáhne — klíčová schopnost pro rozsáhlé systémy.

Pochopení **architektury** (shards obsahující podmnožinu dat, `mongos` router dotazů směrující dotazy, config servery ukládající metadata) je základní.

Nejkritičtěji, pochopení **shard key** — pole určující distribuci dat — je nezbytné, protože **jde o nejdůležitější a nejhůře měnitelné rozhodnutí při shardingu**: dobrý shard key (vysoká kardinalita, rovnoměrná distribuce, zarovnané s vzory dotazů) rozšiřuje data a zatížení rovnoměrně a umožňuje cílené dotazy, zatímco špatný způsobuje hotspoty (nerovnoměrné zatížení), scatter-gather dotazy (zasahující všechny shards, pomalé) a slabé škálování.

Pochopení **cílených versus scatter-gather dotazů** (dotazy včetně shard key se směrují na specifické shards efektivně; ty bez něj zasahují všechny shards) posílí návrh shard key kolem vzorů dotazů.

Když je škálování na velmi velká data reálnou výzvou pro rychle rostoucí aplikace, a protože sharding (mechanismus horizontálního škálování MongoDB) vyžaduje pečlivé pochopení — zejména kritické, těžko měnitelné rozhodnutí shard key a jeho dopad na distribuci a efektivitu dotazů — je pochopení shardingu důležitou znalostí na úrovni senior pro škálování MongoDB, téma demonstrující porozumění horizontálnímu databázovému škálování a oblast, kde rozhodnutí shard-key obzvláště odráží hlubokou, podstatnou znalost MongoDB škálování očekávanou na senior rolích zvládajících rozsáhlé systémy.