Partitionnement et routage

#Partitionnement et routageCopier le lien

Distribuer les données sur plusieurs fragments permet de faire évoluer la capacité horizontalement. Le partitionnement garde chaque shard dans sa propre enveloppe de cohérence et évite qu’une requête ne bloque le cluster entier. Reste à choisir un découpage qui respecte le modèle d’accès, limite les jointures inter-shards et simplifie les opérations (ajout/retrait de nœuds, migrations de données, restauration).

#Motiver le partitionnementCopier le lien

• Scalabilité : un nœud unique plafonne ; en répartissant les clés on augmente linéairement la capacité CPU/disk/IO.
• Isolement des incidents : un shard en difficulté ne doit pas perturber les autres. On peut le redémarrer, limiter son trafic ou le déplacer sans toucher au reste.
• Localité : placer les données au plus près des utilisateurs (clusters multi-région) ou de la logique métier (équipes autonomes par domaine).
• Économie : dimensionner chaque shard selon son profil (stockage chaud vs froid) et réduire les surprovisions globales.

#Déterminer les clés de partitionCopier le lien

#Hachage cohérent — visualisationCopier le lien

Un anneau de hachage projette les clés sur un cercle logique [0, 2^m), où chaque nœud possède un segment. Ajouter ou retirer un nœud ne déplace qu’une fraction des clés (celles situées entre l’ancien et le nouveau successeur), ce qui limite les migrations massives. Les nœuds virtuels (plusieurs positions par serveur) lissent la distribution.

#Animation : rebalancement contrôléCopier le lien

Cette animation montre comment un cluster applique un rehash partiel lors d’un pic, puis draine un nœud pour maintenance. Clés à retenir : ajouter la capacité avant la saturation, monitorer la chauffe des caches froids et planifier la sortie d’un nœud à faible charge résiduelle.

#Chemins de lecture et d’écritureCopier le lien

#Patterns de routageCopier le lien

• Client-side : le client calcule la destination (ex. Cassandra) — éviter les clients obsolètes via discovery dynamique.
• Smart proxy : un routeur proche des clients tient la table des shards (ex. Vitess). On centralise la logique mais on ajoute un saut réseau.
• Service directory : un service (etcd/Zookeeper/Consul) publie la topologie et les routeurs la mettent en cache.

#Multi-région et acheminement des requêtesCopier le lien

• Écriture locale + réplication asynchrone : idéal pour lecture rapide, mais attention à la cohérence éventuelle (utiliser vecteurs, versionnage).
• Élection régionale : chaque région possède un leader local ; un méta-consensus arbitre les conflits entre régions (Spanner, Yugabyte).
• Anycast / GeoDNS : router le trafic vers la région la plus proche ; prévoir un fallback en cas d’indisponibilité (failover piloté par la santé des shards).
• Partitionnement fonctionnel : découper par domaines métier (billing, analytics) plutôt que par zone géographique quand la cohérence locale prime.

#Opérations et observabilitéCopier le lien

• Automatiser les migrations (jobs idempotents, throttling, pré-vérifications d’intégrité).
• Mesurer le temps de réchauffement des caches après déplacement de shards.
• Tracer les split/merge pour auditer qui a initié un changement de topologie.
• Tester les scénarios de « double écriture » pendant les migrations (write mirror + compare).

#QuizCopier le lien