Tech • IA • Robotique • Jeu
Le sharding de base de données expliqué aux débutants (avec travaux pratiques)
5/10INTRO
Le sharding de base de données répartit les lignes sur plusieurs machines afin de faire évoluer les systèmes à forte charge d’écriture au-delà des limites d’une base primaire unique.
POINTS CLÉS
Pourquoi le sharding devient nécessaire
Une petite application sociale comme Chirp peut démarrer avec un serveur d’application et une base de données, en gérant les comptes utilisateurs et les courts messages avec des lectures et écritures simples. Quand l’usage passe de centaines à milliers d’utilisateurs, les équipes augmentent généralement la capacité en louant des machines plus puissantes. Mais lorsque la base atteint les millions d’utilisateurs, une base unique peut se heurter à des limites strictes de débit et de stockage.
Les lectures peuvent être soulagées avec des réplicas
Les lectures lentes apparaissent souvent en premier. Des pages de profil qui se chargeaient autrefois en environ 30 millisecondes peuvent se dégrader jusqu’à près de 3 secondes lorsque trop de requêtes s’accumulent sur une seule machine. Les réplicas aident en conservant des copies exactes des données et en servant le trafic de lecture, tout en améliorant aussi le basculement si la base primaire tombe en panne.
Les écritures restent liées au primaire
La réplication ne résout pas la saturation des écritures, car plusieurs machines ne peuvent pas accepter en toute sécurité des mises à jour contradictoires sur la même ligne sans risquer des incohérences. Une publication avec 99 likes pourrait à tort rester à 100 si deux écritures simultanées atteignent des réplicas différents. Pour cette raison, le primaire reste la source de vérité, et un trafic d’écriture élevé finit par en faire le goulet d’étranglement du système.
Ce que le sharding change
Le sharding, aussi appelé scalabilité horizontale, répartit les lignes entre plusieurs machines ordinaires au lieu de dépendre d’un seul serveur plus gros. Chaque shard ne contient qu’une partie des données, mais conserve le même schéma que les autres. Répartir les utilisateurs sur quatre shards, par exemple, crée quatre cibles d’écriture au lieu d’une, ce qui permet au système de gérer bien plus d’écritures simultanées.
Les clés de sharding déterminent le succès ou l’échec
La colonne utilisée pour placer les données est la clé de sharding. Une bonne clé de sharding doit avoir une forte cardinalité, répartir la charge de manière homogène, correspondre aux schémas d’accès courants, rester stable dans le temps et préserver la colocalisation des enregistrements liés. L’ID utilisateur répond mieux à ces critères que des champs comme le pays, l’année d’inscription ou le nom d’utilisateur, qui peuvent créer des déséquilibres, des requêtes scatter-gather ou des déplacements de données coûteux.
Le hachage associe n’importe quelle clé à un shard
Quand la clé de sharding n’est pas naturellement numérique, une fonction de hachage transforme des valeurs comme les noms d’utilisateur ou les adresses e-mail en nombres. La même entrée doit toujours produire la même sortie, c’est pourquoi les hachages d’exécution instables ne conviennent pas au sharding. Des systèmes comme MongoDB prennent en charge le sharding haché afin de disperser largement des valeurs adjacentes et de maintenir une répartition plus homogène.
D’autres stratégies de sharding existent
Le sharding par plage fonctionne bien lorsque la plupart des requêtes ciblent des intervalles de valeurs, comme des dates, mais il peut surcharger le shard le plus récent avec les nouvelles écritures. Le sharding par annuaire utilise une table de correspondance pour placer manuellement de gros tenants, au prix d’une dépendance critique de routage. Le sharding géographique stocke les données par région pour des raisons de vitesse ou de conformité légale, souvent avant d’appliquer une autre méthode comme le hachage dans chaque région.
Le routage est une partie centrale de la conception
Chaque requête a besoin d’une couche de routage qui calcule le shard cible et transmet correctement le trafic. Cette logique peut vivre dans chaque service applicatif, dans un proxy central ou dans la couche de base de données elle-même. Le routage côté application est rapide mais difficile à mettre à jour partout; les proxys sont plus simples à gérer mais peuvent ajouter de la latence et devenir des goulets d’étranglement; le routage géré par la base réduit le travail applicatif mais limite la flexibilité.
Les points chauds créent le problème des célébrités
Même des shards bien équilibrés peuvent échouer face à une popularité inégale. Une célébrité avec 40 millions d’abonnés peut surcharger un shard pendant que les autres restent peu utilisés. Les réponses courantes incluent le déplacement de ce compte vers un shard dédié via une règle d’annuaire, le service de la plupart des lectures depuis un cache, et la répartition des compteurs très sollicités par salage, où une clé très chaude est divisée en plusieurs clés logiques sur les shards existants.
Le sharding simple par modulo se casse lors de la croissance
Une règle fréquente chez les débutants consiste à hacher une clé, diviser par le nombre de shards, puis utiliser le reste. Cela fonctionne au début, mais provoque un resharding douloureux lorsqu’on ajoute de la capacité. Passer de 4 à 5 shards peut changer la destination de la majorité des enregistrements, imposant une migration à grande échelle alors que les données sous-jacentes n’ont pas changé.
Le hachage cohérent réduit les déplacements de données
Le hachage cohérent place les shards sur un anneau de hachage et envoie chaque clé vers le premier shard trouvé dans le sens horaire à partir de sa valeur de hachage. Lorsqu’un shard est ajouté, seule une partie de l’anneau est déplacée, au lieu de la majeure partie du jeu de données. Pour éviter une répartition inégale, les systèmes placent chaque shard physique plusieurs fois sur l’anneau sous forme de nœuds virtuels, ce qui améliore l’équilibre et réduit l’impact lorsqu’on ajoute ou retire des machines.
CONCLUSION
Le sharding est la principale voie pour faire évoluer les écritures en base de données, mais il introduit des choix difficiles autour des clés de sharding, du routage, des points chauds et du rééquilibrage. Des conceptions efficaces à petite échelle peuvent devenir coûteuses plus tard, d’où l’importance de bien planifier la répartition et la croissance dès le départ.
Poser une question