Comment corriger les données déséquilibrées et les partitions chaudes ?

Question

IT Interview Practice · Accepted Answer

**Identifiez d’abord ce qui est déséquilibré : le volume stocké, le trafic ou les mises à jour d’un même enregistrement.** Ajouter des serveurs n’aide que si le travail saturé peut leur être transféré.

Supposons que les commandes soient réparties par identifiant marchand. La plupart des marchands sont petits, mais l’un lance une grande campagne. Son shard sature alors que les autres restent peu chargés. C’est une partition chaude : elle reçoit plus de travail qu’elle ne peut en traiter.

## 1. Mesurer le déséquilibre avant de changer la clé

Comparez volume de données, débit des requêtes, latence et pression sur le CPU ou les disques entre shards. Détaillez ensuite le shard surchargé par marchand et opération. Un shard contenant un historique volumineux peut être inactif ; un petit shard peut saturer à cause de mises à jour répétées du même article populaire.

Pour notre campagne, cherchez si la charge vient de la lecture des fiches produits, de nombreuses commandes indépendantes ou des modifications répétées du même stock. Ces trois cas nécessitent des réponses différentes.

## 2. Comprendre pourquoi la répartition reste inégale

La clé de sharding détermine la destination des enregistrements. Hacher les identifiants marchands peut répartir les marchands entre shards, mais toutes les commandes portant la même clé marchand suivent toujours la même règle de placement. Le hachage ne divise pas automatiquement la charge d’un marchand.

Une clé avec peu de valeurs distinctes limite les possibilités de répartition. Une plage temporelle peut concentrer les nouvelles écritures sur la partition la plus récente. Une clé plus dispersée améliore parfois l’équilibre, mais oblige les requêtes courantes à contacter plusieurs shards. Les [conseils MongoDB sur la clé de sharding](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) expliquent ces compromis.

## 3. Adapter la solution au travail qui sature

| Observation | Piste à évaluer | Limite importante |
|---|---|---|
| Plusieurs partitions déplaçables occupent le même shard | Les répartir selon la capacité disponible | Le déplacement aide seulement si le travail associé suit les données |
| Lectures répétées du même produit | Cache ou réplicas de lecture, si la fraîcheur exigée le permet | Cela ne répartit pas les écritures de ce produit |
| Un marchand crée de nombreuses commandes indépendantes | Ajouter une clé liée à la commande ou un compartiment | Les requêtes globales du marchand peuvent nécessiter plusieurs lectures et une fusion |
| Plusieurs écritures se disputent le même stock | Réduire la contention ou revoir l’allocation du stock | Ajouter des shards ne supprime pas la coordination nécessaire à l’exactitude |

Isoler le grand marchand peut protéger les autres clients et donner du temps. Cela ne lui procure pas une capacité illimitée : mesurez toujours sa propre limite.

## 4. Évaluer le coût de la subdivision d’un marchand

Imaginons un routage combinant l’identifiant marchand et un compartiment calculé depuis l’identifiant de commande. Les commandes indépendantes de la campagne peuvent alors se répartir entre plusieurs partitions.

```text
Merchant A + bucket 0 -> Partition 1
Merchant A + bucket 1 -> Partition 2
Merchant A + bucket 2 -> Partition 3
```

Lire une commande est plus simple si son compartiment peut être calculé. Lire toutes les commandes récentes du marchand A exige désormais plusieurs lectures puis une fusion dans le bon ordre. Pagination, totaux et transactions entre partitions deviennent plus complexes. Choisissez cette subdivision seulement si ce surcoût de lecture et de coordination est acceptable.

## 5. Migrer en pouvant démontrer l’exactitude

Modifier le routage pendant que les écritures continuent exige un plan de migration. Copiez les enregistrements existants, capturez les changements survenus pendant la copie et comparez les nombres d’enregistrements ainsi que les totaux métier avant de basculer. Un simple comptage peut masquer des montants erronés.

Définissez le traitement des écritures en cours à la bascule et le retour éventuel à l’ancien routage sans perdre les écritures acceptées par la nouvelle organisation. La double écriture exige une gestion des échecs : écrire à deux endroits ne garantit pas leur égalité.

Enfin, testez avec la charge réellement déséquilibrée, grand marchand compris, plutôt qu’avec un trafic uniforme. La réussite combine une pression réduite sur le shard saturé, un coût de requête acceptable et des résultats métier inchangés. **Une bonne clé équilibre la répartition du travail avec les modes de lecture et de mise à jour de l’application.**

Observation	Piste à évaluer	Limite importante
Plusieurs partitions déplaçables occupent le même shard	Les répartir selon la capacité disponible	Le déplacement aide seulement si le travail associé suit les données
Lectures répétées du même produit	Cache ou réplicas de lecture, si la fraîcheur exigée le permet	Cela ne répartit pas les écritures de ce produit
Un marchand crée de nombreuses commandes indépendantes	Ajouter une clé liée à la commande ou un compartiment	Les requêtes globales du marchand peuvent nécessiter plusieurs lectures et une fusion
Plusieurs écritures se disputent le même stock	Réduire la contention ou revoir l’allocation du stock	Ajouter des shards ne supprime pas la coordination nécessaire à l’exactitude

1. Mesurer le déséquilibre avant de changer la clé

2. Comprendre pourquoi la répartition reste inégale

3. Adapter la solution au travail qui sature

4. Évaluer le coût de la subdivision d’un marchand

5. Migrer en pouvant démontrer l’exactitude

Questions connexes