Meilleures pratiques pour un sharding et un scaling efficaces des clusters MongoDB

Le sharding MongoDB distribue une collection sur plusieurs shards afin qu'un seul jeu de réplicas n'ait pas à supporter toutes vos données ou tout votre trafic. Il peut résoudre de véritables problèmes de scaling, mais une mauvaise clé de shard peut créer des shards chauds, des requêtes scatter-gather lentes et un travail opérationnel difficile à annuler.

Utilisez le sharding lorsqu'un seul jeu de réplicas ne peut plus gérer la taille de vos données, le débit d'écriture ou la charge de lecture après avoir déjà traité les bases : index, conception de schéma, dimensionnement matériel et réglage des requêtes.

Comprendre les composants principaux d'un cluster shardé

Un cluster shardé fonctionnel repose sur plusieurs composants interconnectés qui travaillent de concert :

Shards (Jeux de réplicas shardés) : Chaque shard est généralement un jeu de réplicas qui contient un sous-ensemble de l'ensemble total des données. Les données sont partitionnées entre ces shards.
Routeurs de requêtes (Processus Mongos) : Ces processus reçoivent les requêtes des clients, déterminent quel shard contient les données requises (sur la base des métadonnées), acheminent la requête, agrègent les résultats et les renvoient au client. Ils sont sans état et hautement évolutifs.
Serveurs de configuration (Config Servers) : Ces jeux de réplicas dédiés stockent les métadonnées (la carte du cluster) qui indiquent aux processus mongos où résident des morceaux spécifiques de données. Ils sont essentiels au fonctionnement du cluster et doivent rester hautement disponibles.

Stratégie clé 1 : Sélectionner la clé de shard optimale

La clé de shard est la décision la plus critique dans le sharding. Elle dicte la manière dont les données sont partitionnées entre vos shards. Une clé de shard bien choisie conduit à une distribution uniforme des données et à un routage efficace des requêtes ; une mauvaise clé entraîne des points chauds et des clusters déséquilibrés.

Caractéristiques d'une clé de shard efficace

Une clé de shard idéale doit posséder trois caractéristiques principales :

Haute cardinalité : La clé doit avoir de nombreuses valeurs uniques pour permettre un partitionnement fin. Une faible cardinalité conduit à moins de morceaux dans l'ensemble.
Fréquence d'écriture élevée / Distribution uniforme : Les écritures doivent être réparties uniformément sur toutes les valeurs de la clé de shard pour éviter qu'un seul shard ne soit surchargé (un point chaud).
Modèles de requêtes : Les requêtes doivent idéalement cibler la clé de shard pour permettre des requêtes ciblées (routage vers des shards spécifiques). Les requêtes qui nécessitent l'analyse de tous les shards (requêtes scatter-gather) sont nettement plus lentes.

Méthodes de sharding et leurs implications

MongoDB prend en charge deux méthodes principales de sharding :

Sharding haché : Utilise une fonction de hachage sur la valeur de la clé de shard. Cela garantit une excellente distribution des données, même pour les clés séquentielles, en répartissant les écritures sur tous les shards disponibles. Idéal pour un débit d'écriture élevé où la localité des requêtes est moins importante.
Sharding par plage : Partitionne les données en fonction de plages de la clé de shard (par exemple, tous les utilisateurs avec des ID 1-1000 vont sur le Shard A). Idéal lorsque les modèles de requêtes s'alignent sur les recherches par plage (par exemple, l'interrogation par plage de dates ou plages d'ID alphabétiques).

⚠️ Avertissement sur le sharding par plage : Si votre modèle d'insertion de données suit une séquence strictement croissante (comme des horodatages ou des ID auto-incrémentés), le sharding par plage fera que toutes les écritures atterriront sur le morceau le plus récent, entraînant un point chaud important sur le dernier shard.

Exemple : Application du sharding haché

Si vous choisissez un champ comme userId et que vos requêtes le filtrent fréquemment, le hacher répartit uniformément les écritures :

// Sélectionner la base de données et la collection
use myAppDB

// Hacher le champ userId pour le sharding
sh.shardCollection("myAppDB.users", { "userId": "hashed" })

Stratégie clé 2 : Gérer la distribution des données et l'équilibrage

Même avec une clé de shard parfaite, les morceaux de données (les unités physiques de données stockées sur les shards) peuvent devenir de taille ou de distribution inégale en raison de l'évolution des modèles de requêtes ou des déséquilibres de charge initiaux. Le processus d'équilibreur gère la migration de ces morceaux.

Surveiller l'équilibreur

Il est crucial de surveiller les métriques d'équilibre du cluster. Des morceaux déséquilibrés entraînent des ressources sous-utilisées sur certains shards tandis que d'autres deviennent surchargés.

Utilisez la commande sh.status() dans le shell pour afficher l'état général, y compris les morceaux en cours de migration.

Contrôler l'équilibreur

Bien que l'équilibreur s'exécute automatiquement, vous pouvez le désactiver temporairement pendant les fenêtres de maintenance à forte charge ou les importations par lots importantes pour contrôler la consommation des ressources :

// Vérifier l'état actuel
sh.getBalancerState()

// Désactiver temporairement l'équilibrage
sh.stopBalancer()

// ... Effectuer la maintenance ou l'importation importante ...

// Redémarrer l'équilibrage une fois terminé
sh.startBalancer()

Meilleure pratique : Ne désactivez jamais l'équilibreur de manière permanente. Si vous le désactivez, planifiez des examens réguliers pour vous assurer que les données restent uniformément réparties à mesure que l'application se développe.

Considérations sur la taille des morceaux

Les morceaux ne doivent pas être trop petits, car cela crée une surcharge excessive de métadonnées et ralentit l'équilibreur. À l'inverse, des morceaux trop volumineux entraînent des migrations lentes et de mauvaises opportunités d'équilibrage de charge.

Taille de morceau par défaut : La taille de morceau par défaut de MongoDB est généralement adaptée à de nombreux clusters. Consultez la documentation de votre version de MongoDB avant de la modifier.
Ajustement de la taille des morceaux : Modifiez la taille des morceaux uniquement lorsque vous avez une raison opérationnelle claire, comme des migrations trop longues ou une surcharge de métadonnées excessive. La méthode prise en charge a changé selon les versions de MongoDB, alors vérifiez la commande actuelle pour votre version avant de l'appliquer.

Stratégie clé 3 : Optimiser les performances de lecture et d'écriture

Le sharding modifie la façon dont les lectures et les écritures sont acheminées, ce qui nécessite un réglage spécifique des performances.

Requêtes ciblées vs. scatter-gather

Requêtes ciblées : Les requêtes qui incluent la clé de shard (ou un préfixe de la clé de shard si vous utilisez le sharding par plage) permettent au routeur mongos d'envoyer la demande directement à un ou quelques shards. Elles sont rapides.
Requêtes scatter-gather : Les requêtes qui n'utilisent pas la clé de shard doivent être envoyées à tous les shards, ce qui augmente la latence réseau et la surcharge de traitement.

Conseil actionnable : Concevez les requêtes de l'application pour utiliser la clé de shard autant que possible. Pour les requêtes qui doivent analyser largement, envisagez d'utiliser des préférences de lecture qui favorisent les membres secondaires des jeux de réplicas pour isoler la charge des membres principaux.

Préférence de lecture dans les clusters shardés

Les clusters shardés gèrent les préférences de lecture au niveau du client. Assurez-vous que le code de votre application définit correctement les préférences de lecture en fonction de la criticité de l'opération :

primary (Par défaut) : Les lectures vont au primaire du jeu de réplicas de chaque shard.
nearest : Les lectures vont au membre du jeu de réplicas géographiquement ou réseau le plus proche de l'application.
secondaryPreferred : Les lectures sont envoyées aux secondaires sauf si aucun secondaire n'est disponible, ce qui est utile pour décharger les requêtes de reporting ou d'analyse des primaires.

Éviter les pièges d'indexation

Assurez-vous que des index existent sur les champs fréquemment utilisés dans les filtres de requête ou les opérations de tri, en particulier la clé de shard et tous les champs de préfixe de la clé de shard. Une indexation incohérente entre les shards peut également entraîner des requêtes scatter-gather inattendues si un shard ne peut pas utiliser un index.

Meilleures pratiques opérationnelles pour la stabilité

Le maintien d'un cluster shardé stable et performant nécessite une vigilance opérationnelle continue.

1. Modifications de la clé de shard

Choisissez la clé de shard comme si elle allait être coûteuse à modifier, car c'est généralement le cas. Les versions récentes de MongoDB prennent en charge plus d'affinage de la clé de shard et certaines mises à jour de la valeur de la clé de shard que les versions plus anciennes, mais les règles dépendent de votre version, du modèle de clé et des exigences de transaction. Ne comptez pas sur une réécriture facile après le début du trafic de production.

2. Résilience du serveur de configuration

Les serveurs de configuration sont le cerveau du cluster. S'ils deviennent indisponibles, les clients ne peuvent pas déterminer où résident les données, ce qui arrête effectivement les opérations.

Déployez toujours les serveurs de configuration en tant que jeu de réplicas (minimum de trois membres).
Assurez-vous que les serveurs de configuration disposent d'un stockage rapide et ne sont pas alourdis par la charge de travail de l'application.

3. Planification de la capacité

Planifiez la croissance en surveillant le CPU, la mémoire, les E/S disque, la croissance du stockage, le retard de réplication et la distribution des morceaux sur les membres individuels du shard. Ajoutez de la capacité avant qu'un shard ne devienne le goulot d'étranglement plutôt que de vous fier à un pourcentage d'utilisation fixe.

À retenir

Le sharding dans MongoDB est un outil de scaling, pas un raccourci pour contourner la modélisation des données. Choisissez une clé de shard qui répartit les écritures et correspond à vos requêtes les plus importantes, surveillez l'équilibrage après le lancement et gardez les requêtes de l'application ciblées autant que possible.