Diagramme de sharding de base de données : clés de sharding, routage et resharding

Le sharding découpe une base de données en plusieurs, chacune contenant une partie des données. C'est la réponse quand une seule machine ne tient plus les écritures ou ne peut plus contenir les données, et c'est aussi l'une des décisions les plus coûteuses de la vie d'un système : requêtes, transactions, changements de schéma et exploitation deviennent tous plus difficiles.

Cet article explique quand le sharding vaut la peine, comment choisir une clé de sharding, les principaux schémas de sharding, comment les requêtes trouvent le bon shard et comment resharder sans interruption. Le diagramme montre une base de commandes shardée par hachage avec des shards logiques.

Essayez tout le reste d'abord

Avant de sharder, vérifiez les options moins chères, à peu près dans cet ordre :

1. Corrigez les requêtes et les index. La plupart des problèmes de « base trop lente » viennent d'un index manquant ou d'une requête qui lit trop.
2. Montez en gamme. Une machine plus grosse, avec plus de mémoire et des disques plus rapides, fait gagner des années à beaucoup de systèmes.
3. Ajoutez des réplicas en lecture pour une charge dominée par les lectures ; l'article sur la réplication de bases de données couvre le retard qui les accompagne.
4. Mettez en cache les lectures fréquentes, comme dans l'article sur les stratégies de cache.
5. Découpez par fonction : déplacez les tables d'analytique, de recherche ou d'audit dans leurs propres bases.

Shardez quand les écritures ou le volume de données dépassent ce qu'un primaire peut gérer, même après ces étapes, et que la tendance annonce pire.

Choisir une clé de sharding

La clé de sharding décide sur quel shard vit une ligne. Une bonne clé a trois propriétés :

• Toutes les requêtes fréquentes l'incluent. Si la requête de liste des commandes filtre par client, customer_id permet au routeur de l'envoyer à un seul shard. Une requête sans la clé doit interroger tous les shards.
• Elle répartit la charge uniformément. Beaucoup de valeurs distinctes, sans qu'une seule valeur produise une grande part du trafic.
• Elle garde ensemble les données liées. Toutes les commandes, lignes et paiements d'un client sur un même shard : les transactions et les jointures restent locales.

Pour un SaaS multi-tenant, la clé est en général l'ID du tenant. Pour une application grand public, l'ID de l'utilisateur ou du client. Méfiez-vous des clés qui semblent bonnes mais concentrent la charge, comme un horodatage (toutes les nouvelles écritures vont sur un shard) ou un code pays (un pays domine).

Range, hash ou annuaire

Un hybride courant : hachez la clé vers un nombre fixe de shards logiques (disons 1 024), et gardez un petit annuaire qui associe les shards logiques aux hôtes physiques. Les clés ne changent jamais de shard logique ; seuls des shards logiques entiers changent d'hôte. L'équipe d'ingénierie d'Instagram a décrit cette approche en 2012, avec des milliers de shards logiques sur bien moins de serveurs de base de données.

Router les requêtes

Quelque chose doit savoir où vit chaque clé :

• Dans l'application, via une bibliothèque qui hache la clé et cherche l'hôte. Simple, mais chaque service et chaque langage ont besoin de la même logique.
• Dans un proxy entre l'application et les bases. Vitess le fait pour MySQL avec son proxy VTGate, et Citus le fait pour Postgres via un nœud coordinateur.

Dans les deux cas, mettez la carte des shards en cache et rechargez-la quand elle change. Une carte périmée pendant un déplacement est le bug classique du resharding : un routeur écrit sur l'ancien hôte après la bascule, et la ligne disparaît sans bruit du nouveau. Versionnez la carte et rejetez les écritures qui portent une ancienne version. Les requêtes sans clé de sharding sont envoyées à tous les shards et les résultats fusionnés : cela marche pour des tâches d'administration rares, et échoue comme chemin d'accès normal.

Resharder sans interruption

Avec des shards logiques, ajouter de la capacité revient à déplacer certains shards logiques vers un nouvel hôte :

1. Copiez les données des shards logiques vers le nouvel hôte pendant que l'ancien continue de servir.
2. Diffusez les changements en cours, via la réplication de la base ou le change data capture, jusqu'à ce que la copie ait rattrapé son retard.
3. Bloquez brièvement les écritures de ces shards logiques, laissez arriver les derniers changements, mettez à jour la carte des shards et reprenez.
4. Vérifiez, puis supprimez les données déplacées de l'ancien hôte.

Vitess et Citus automatisent des variantes de ce processus. Répétez-le avant d'en avoir besoin : resharder sous charge pour la première fois, c'est une mauvaise journée.

Des ID qui fonctionnent entre shards

Une séquence par base distribue les mêmes ID sur chaque shard. Utilisez des ID uniques sans coordination : des UUID (la version 7 les garde à peu près ordonnés dans le temps, ce qui ménage les index), ou des ID 64 bits façon Snowflake qui combinent un horodatage, un numéro de shard ou de machine et un compteur. Intégrer le numéro de shard logique dans l'ID offre un bonus : avec un simple ID de commande, le routeur sait où chercher sans demander à personne.

Le diagramme d'architecture

Comment le lire :

• À gauche : le service de commandes envoie chaque requête avec un ID client au routeur de shards.
• Au milieu : le routeur hache l'ID client vers l'un des 1 024 shards logiques et trouve l'hôte dans la carte des shards en cache (en tirets).
• À droite : quatre hôtes Postgres détiennent chacun 256 shards logiques. L'hôte 4 déplace sa moitié haute vers un nouvel hôte 5 : c'est l'étape de resharding en cours.
• En haut à droite : les rapports qui couvrent plusieurs clients lisent un entrepôt analytique alimenté par change data capture, pour ne jamais se répartir entre les shards.
• Le bloc Markdown liste les règles que doit suivre quiconque écrit des requêtes.

Les coûts que vous acceptez

Le diagramme d'architecture SaaS multi-tenant montre la variante avec un shard par tenant, où les compromis ci-dessous s'appliquent par tenant.

• Les transactions entre shards deviennent des transactions distribuées ou des sagas. Concevez pour qu'elles soient rares.
• Les contraintes d'unicité entre shards demandent un schéma d'ID global plutôt qu'une séquence par base.
• Les changements de schéma s'exécutent sur chaque shard : les migrations ont besoin d'outillage et doivent tolérer une exécution partielle.
• L'exploitation se multiplie : sauvegardes, mises à jour et supervision pour chaque shard.

Ce qu'il faut mettre sur un diagramme de sharding

• La clé de sharding et le schéma (hash, range, annuaire).
• Les shards logiques et physiques, si vous les séparez.
• L'endroit où se fait le routage : bibliothèque, proxy ou coordinateur.
• Le chemin des requêtes sans clé, comme un entrepôt ou un index de recherche.
• L'état du resharding, quand un déplacement est en cours.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez des nœuds Conteneur du pack Modèle C4 pour le service et le routeur de shards, et une Base de données pour la carte des shards.
3. Ajoutez des nœuds Postgres du pack Données pour les hôtes, étiquetés avec leurs plages de shards logiques, plus un pour le nouvel hôte.
4. Ajoutez un Entrepôt de données du pack Données pour les rapports, alimenté par une arête CDC en pointillés.
5. Dessinez le déplacement de resharding en arête en tirets et ajoutez un bloc Markdown du pack Base avec les règles de sharding.

L'exemple utilise 10 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre sharding et partitionnement ? Le partitionnement désigne en général le découpage d'une table à l'intérieur d'un seul serveur de base de données. Le sharding répartit les données sur plusieurs serveurs, chacun n'en détenant qu'une partie.

Comment choisir une clé de sharding ? Prenez l'attribut sur lequel filtrent toutes les requêtes fréquentes et qui garde ensemble les données liées, avec beaucoup de valeurs distinctes et une charge uniforme, comme un ID de tenant ou de client.

Que sont les shards logiques ? Un nombre fixe et élevé de compartiments de hachage, associés à moins de serveurs physiques. Déplacer des shards logiques entiers entre serveurs évite de rehacher chaque clé quand on ajoute de la capacité.

Comment exécuter des requêtes sur tous les shards ? Évitez-les sur les chemins critiques. Pour les rapports, répliquez les données dans un entrepôt ; pour des tâches d'administration rares, une requête répartie via le routeur est acceptable.

Quand faut-il sharder ? Quand le volume d'écriture ou la taille des données dépassent ce qu'un primaire unique bien réglé peut gérer et que la tendance continue, après l'indexation, la montée en gamme, les réplicas, le cache et le découpage fonctionnel.

Commencez gratuitement — un siège, sans carte bancaire.