Kako funkcionira sharding u MongoDBu?

Question

Accepted Answer

**Sharding** je Mongodbova metoda za **horizontalno skaliranje** — distribuiranje podataka preko više servera (**shards**) tako da baza podataka može rukovati skupovima podataka i propusnostima koje jedan server ne može. Particionira podatke prema **shard key**, s MongoDBom rutira upite prema odgovarajućim shardima.

## Zašto shardirati: skaliranje izvan jednog servera

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

## Kako funkcionira sharding

```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 — najkritičnija odluka

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

## Ciljani vs scatter-gather upiti

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

## Zašto je važno

Sharding je važno znanje za **skaliranje MongoDBa na vrlo velike skupove podataka i visoku propusnost**, tako da je razumijevanje toga vrijedna znanja na seniorskoj razini za velikoskalne MongoDB distribucije.

Krzna vrijednost je **horizontalno skaliranje**: kada podaci ili opterećenje preplavi što jedan server može rukovati, sharding distribuira podatke preko više shardima, skalirajući kapacitet horizontalno kako bi se nosio s ogroman skupovima podataka i visokom propusnosti pisanja koju vertikalno skaliranje (veći server) ne može doseći — ključna mogućnost za velikoskalnih sustava.

Razumijevanje **arhitekture** (svaki shard drži podskup podataka, `mongos` upitni router usmjerava upite, config serveri pohrani metapodatke) je temeljno.

Najkriitčnije, razumijevanje **shard key** — polje(a) koja određuje distribuciju podataka — je neophodno jer je **to najveća i najteže mjenljiva sharding odluka**: dobar shard key (visoka kardinalnost, ujednačena distribucija, usklađena s upitnim uzorcima) raspoređuje podatke i opterećenje ravnomjerno i omogućuje ciljane upite, dok loš uzrokuje hotspotove (neujednačeno opterećenje), scatter-gather upite (pogađanje svih shardima, spora), i loše skaliranje.

Razumijevanje **ciljanih vs scatter-gather upita** (upiti koji uključuju shard key rutiraju se na specifične shardime učinkovito; oni bez njega pogađaju sve shardime) ojačava osmišljavanje shard keya oko upitnih uzoraka.

Jer skaliranje na vrlo velike podatke je pravi izazov za brzorazvijajuće aplikacije, a jer sharding (Mongodbov mehanizam horizontalnog skaliranja) zahtijeva pažljivo razumijevanje — posebno kritična, teško mjenljiva shard key odluka i njena utjecaj na distribuciju i učinkovitost upita — razumijevanje shardinga je važno znanje na seniorskoj razini za skaliranje MongoDBa, tema koja demonstrira razumijevanje horizontalnog skaliranja baza podataka i tema gdje shard-key odluka posebno odražava duboko, značajno MongoDB skaliranje znanja očekivanog za seniorske uloge koje rukuju velikoskalnim sustavima.