Comment fonctionne le sharding dans MongoDB ?

Question

Accepted Answer

**Sharding** est la méthode de MongoDB pour la **mise à l'échelle horizontale** — distribuer les données sur plusieurs serveurs (**shards**) pour que la base de données puisse gérer des ensembles de données et des débits au-delà de ce qu'un seul serveur peut. Il partitionne les données par une **clé de sharding**, MongoDB acheminant les requêtes vers les bons shards.

## Pourquoi c'est important

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

## Comment fonctionne le 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.
```

## La clé de sharding — la décision la plus critique

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

## Requêtes ciblées vs scatter-gather

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

## Pourquoi c'est important

Le sharding est une connaissance importante pour **mettre à l'échelle MongoDB pour de très grands ensembles de données et un haut débit**, comprendre cela est donc une connaissance précieuse au niveau senior pour les déploiements MongoDB à grande échelle.

La valeur fondamentale est la **mise à l'échelle horizontale** : quand les données ou la charge dépasse ce qu'un seul serveur peut gérer, le sharding distribue les données sur plusieurs shards, mettant à l'échelle la capacité horizontalement pour gérer d'énormes ensembles de données et un haut débit d'écriture que la mise à l'échelle verticale (un serveur plus grand) ne peut pas atteindre — une capacité clé pour les systèmes à grande échelle.

Comprendre l'**architecture** (chaque shard contenant un sous-ensemble de données, le routeur de requêtes `mongos` dirigeant les requêtes, les serveurs de configuration stockant les métadonnées) est fondamental.

Mais surtout, comprendre la **clé de sharding** — le(s) champ(s) déterminant la distribution des données — est essentiel car **c'est la décision de sharding la plus importante et la plus difficile à modifier** : une bonne clé de sharding (haute cardinalité, distribution uniforme, alignée avec les motifs de requête) répartit les données et la charge uniformément et permet les requêtes ciblées, tandis qu'une mauvaise cause des hotspots (charge inégale), des requêtes scatter-gather (frappant tous les shards, lent), et une mauvaise mise à l'échelle.

Comprendre les **requêtes ciblées vs scatter-gather** (les requêtes incluant la clé de sharding s'acheminent vers des shards spécifiques efficacement ; celles sans frappent tous les shards) renforce la conception de la clé de sharding autour des motifs de requête.

Puisque la mise à l'échelle vers de très grandes données est un vrai défi pour les applications en croissance rapide, et puisque le sharding (le mécanisme de mise à l'échelle horizontale de MongoDB) nécessite une compréhension prudente — en particulier la décision critique et difficile à modifier de la clé de sharding et son impact sur la distribution et l'efficacité des requêtes — comprendre le sharding est une connaissance importante au niveau senior pour mettre à l'échelle MongoDB, un sujet démontrant la compréhension de la mise à l'échelle horizontale des bases de données et un sujet où la décision de clé de sharding en particulier reflète une expertise MongoDB en mise à l'échelle profonde et conséquente attendue pour les rôles seniors gérant des systèmes à grande échelle.