Académique Documents
Professionnel Documents
Culture Documents
comprendre le sharding
MongoDB
Dans le monde actuel axé sur les données, où le volume et la complexité des données
continuent de croître à un rythme sans précédent, le besoin de solutions de bases de
données robustes et évolutives est devenu primordial. On estime que 180 zettaoctets de
données seront créés d’ici 2025. Il s’agit là de chiffres importants à prendre en compte.
À mesure que les données et la demande des utilisateurs montent en flèche, il n’est plus
possible de s’appuyer sur une seule base de données. Cela ralentit votre système et
surcharge les développeurs. Vous pouvez adopter diverses solutions pour optimiser votre
base de données, comme le partage de base de données.
Dans ce guide complet, nous nous plongeons dans les profondeurs du sharding MongoDB,
en démystifiant ses avantages, ses composants, ses meilleures pratiques, ses erreurs
courantes et la manière dont vous pouvez commencer.
Lors de la mise en œuvre d’une base de données partagée, il existe deux approches
principales : développer une solution de partage personnalisée ou payer pour une solution
existante. La question se pose alors de savoir s’il est préférable de développer une solution
de sharding ou de payer pour une telle solution.
— Image du mème « Construire ou acheter une solution de sharding » (Source :
LinkedIn)
Pour faire ce choix, vous devez prendre en compte le coût de l’intégration d’une tierce partie,
en gardant à l’esprit les facteurs suivants :
Sur la base de ces facteurs, vous pouvez maintenant décider de construire une solution de
sharding ou de payer pour une solution qui fait le gros du travail à votre place.
Aujourd’hui, la plupart des bases de données disponibles sur le marché prennent en charge
le sharding de base de données. Par exemple, les bases de données relationnelles comme
MariaDB (qui fait partie de la pile de serveurs haute performance de Kinsta) et les bases de
données NoSQL comme MongoDB.
Par exemple, Telefónica Tech gère plus de 30 millions d’appareils IoT dans le monde. Pour
faire face à l’augmentation constante de l’utilisation des appareils, l’entreprise avait besoin
d’une plateforme capable de s’adapter de manière élastique et de gérer un environnement de
données en croissance rapide. La technologie sharding de MongoDB était le bon choix pour
eux, car elle correspondait le mieux à leurs besoins en termes de coûts et de capacité.
Avec le sharding de MongoDB, Telefónica Tech exécute plus de 115.000 requêtes par
seconde. Cela représente 30 000 insertions dans la base de données par seconde, avec
moins d’une milliseconde de latence !
Nous avons déjà vu que le sharding permet de répartir les données entre les différentes
unités du cluster. Grâce à cette répartition, chaque arbre contient un fragment de l’ensemble
des données de la grappe. Des disques supplémentaires augmenteront la capacité de
stockage du cluster au fur et à mesure que la taille de votre ensemble de données
augmentera.
Lecture/écriture
MongoDB répartit la charge de travail de lecture et d’écriture sur les tessons d’un cluster
partagé, ce qui permet à chaque tesson de traiter un sous-ensemble d’opérations du cluster.
Les deux charges de travail peuvent être mises à l’échelle horizontalement dans le cluster en
ajoutant des shards supplémentaires.
Haute disponibilité
De nombreux utilisateurs sont affectés lorsqu’une machine tombe en panne à la suite d’un
arrêt non planifié. Dans un système non partagé, la base de données entière ayant été
interrompue, l’impact est massif. Le rayon d’action d’une mauvaise expérience/impact
utilisateur peut être contenu grâce au sharding MongoDB.
Géodistribution et performances
Les serveurs répliqués peuvent être placés dans différentes régions. Cela signifie que les
clients peuvent bénéficier d’un accès à leurs données avec une faible latence, c’est-à-dire
que les requêtes des consommateurs peuvent être redirigées vers le shard le plus proche. En
fonction de la politique de gouvernance des données d’une région, il est possible de
configurer des serveurs spécifiques pour qu’ils soient placés dans une région donnée.
1. Shard
Chaque base de données dans le cluster partagé a un shard primaire qui contiendra toutes
les collections non partagées pour cette base de données. Le premier dépôt n’est pas lié au
premier dépôt d’un ensemble de répliques.
Pour modifier le shard primaire d’une base de données, vous pouvez utiliser la commande
movePrimary. Le processus de migration du shard primaire peut prendre beaucoup de
temps.
Pendant cette période, vous ne devez pas essayer d’accéder aux collections associées à la
base de données tant que le processus de migration n’est pas terminé. Ce processus peut
avoir un impact sur les opérations globales du cluster en fonction de la quantité de données
en cours de migration.
2. Configurations de serveurs
Pour déployer des serveurs de configuration en tant qu’ensembles de répliques, vous devez
exécuter le moteur de stockage WiredTiger. WiredTiger utilise un contrôle de la concurrence
au niveau des documents pour ses opérations d’écriture. Par conséquent, plusieurs clients
peuvent modifier simultanément différents documents d’une collection.
Les serveurs de configuration stockent les métadonnées d’un cluster partagé dans la base de
données de configuration. Pour accéder à la base de données de configuration, vous pouvez
utiliser la commande suivante dans le shell Mongo :
use config
3. Routeurs de requêtes
Les instances MongoDB mongos peuvent servir de routeurs de requêtes, permettant aux
applications clientes et aux clusters partagés de se connecter facilement.
À partir de la version 4.4 de MongoDB, les instances mongos peuvent prendre en charge les
lectures couvertes afin de réduire les temps de latence. Avec les lectures couvertes, les
instances mongos enverront des opérations de lecture à deux membres de l’ensemble de
répliques pour chaque grappe interrogée. Les résultats sont ensuite renvoyés par le premier
répondant de chaque dépôt.
Voici comment les trois composants interagissent au sein d’un cluster partagé :
— Interaction des composants d’un cluster partagé (Image Source : MongoDB Sharding)
Mongo fusionne ensuite les données de chaque groupe ciblé et renvoie le document de
résultat. Certains modificateurs de requête, comme le tri, sont exécutés sur chaque serveur
avant que les mongos ne récupèrent les résultats.
Dans certains cas, lorsque la clé du dépôt ou un préfixe de clé du dépôt fait partie de la
requête, les mongos exécutent une opération planifiée à l’avance, en orientant les requêtes
vers une sous-classe de dépôts dans le cluster.
Pour un cluster en production, assurez-vous que les données sont redondantes et que vos
systèmes sont hautement disponibles. Vous pouvez choisir la configuration suivante pour le
déploiement d’un cluster de production :
Déployer chaque grappe en tant qu’ensemble de répliques à 3 membres
Déployez les serveurs de configuration en tant qu’ensemble de répliques à trois
membres
Déployez un ou plusieurs routeurs mongos
Pour un cluster de non-production, vous pouvez déployer un cluster sharded avec les
composants suivants :
Pour répartir les données sur plusieurs serveurs, vous utiliserez mongos. Lorsque vous vous
connectez pour envoyer les requêtes à MongoDB, mongos cherche et trouve où résident les
données. Il les récupère ensuite sur le bon serveur et les fusionne si elles ont été réparties
sur plusieurs serveurs.
Étant donné que tout cela est pris en charge par le backend, vous n’aurez rien à faire du côté
de l’application. MongoDB agira comme s’il s’agissait d’une connexion de requête normale.
Votre client se connectera à MongoDB, et le serveur de configuration s’occupera du reste.
Avant de commencer, il est important de noter que pour configurer le sharding dans
MongoDB, vous devez avoir au moins trois serveurs : un pour le serveur de configuration, un
pour l’instance mongos et un ou plusieurs pour les shards.
Pour commencer, nous allons créer un répertoire pour les données du serveur de
configuration. Pour ce faire, exécutez la commande suivante sur le premier serveur :
mkdir /data/configdb
Ensuite, nous allons démarrer MongoDB en mode configuration sur le premier serveur à
l’aide de la commande suivante :
Cette commande démarrera le serveur de configuration sur port 27019 et stockera ses
données dans le répertoire /data/configdb. Notez que nous utilisons le drapeau --
configsvr pour indiquer que ce serveur sera utilisé comme serveur de configuration.
L’étape suivante consiste à démarrer l’instance mongos. Ce processus va router les requêtes
vers les bons shards en se basant sur la clé de sharding. Pour démarrer l’instance mongos,
utilisez la commande suivante :
mongos --configdb <config server>:27019
Remplacez <config server> par l’adresse IP ou le nom d’hôte de la machine sur laquelle
tourne le serveur de configuration.
Une fois que l’instance Mongos est en cours d’exécution, nous pouvons nous y connecter à
l’aide du shell MongoDB. Pour ce faire, exécutez la commande suivante :
Dans cette commande, <mongos-server> doit être remplacé par le nom d’hôte ou l’adresse
IP du serveur exécutant l’instance mongos. Cela ouvrira le shell MongoDB, ce qui nous
permettra d’interagir avec l’instance mongos et d’ajouter des serveurs au cluster.
Maintenant que nous sommes connectés à l’instance mongos, nous pouvons ajouter des
serveurs au cluster en exécutant la commande suivante :
sh.addShard("<shard-server>:27017")
Dans cette commande, <shard-server> doit être remplacé par le nom d’hôte ou l’adresse
IP du serveur qui exécute le shard. Cette commande ajoutera le groupe de serveurs au
cluster et le rendra disponible pour l’utilisation.
Répétez cette étape pour chaque groupe de stockage que vous souhaitez ajouter au cluster.
Enfin, nous allons activer le sharding pour une base de données en exécutant la commande
suivante :
sh.enableSharding("<database>")
Dans cette commande, <database> doit être remplacé par le nom de la base de données
que vous souhaitez partager. Cette commande activera le sharding pour la base de données
spécifiée, ce qui vous permettra de distribuer ses données sur plusieurs shards.
Et c’est tout ! En suivant ces étapes, vous devriez maintenant disposer d’un cluster partagé
MongoDB entièrement fonctionnel, prêt à évoluer horizontalement et à gérer des charges de
trafic élevées.
La clé de partage est un facteur critique dans le partage MongoDB qui détermine la façon
dont les données sont distribuées entre les partages. Il est important de choisir une clé de
stockage qui distribue uniformément les données sur les serveurs et prend en charge les
requêtes les plus courantes. Vous devez éviter de choisir une clé de répartition qui provoque
des points chauds ou une répartition inégale des données, car cela peut entraîner des
problèmes de performance.
Pour choisir la bonne clé de répartition, vous devez analyser vos données et les types de
requêtes que vous effectuerez et sélectionner une clé qui réponde à ces exigences.
Lors de la mise en place de votre cluster, prévoyez une croissance future en commençant par
un nombre de shards suffisant pour gérer votre charge de travail actuelle et en ajoutant
d’autres shards si nécessaire. Assurez-vous que votre infrastructure matérielle et réseau peut
prendre en charge le nombre de grappes et la quantité de données que vous prévoyez
d’avoir à l’avenir.
Pour des performances et une fiabilité optimales, utilisez du matériel dédié pour chaque
groupe de stockage. Chaque groupe doit avoir son propre serveur ou sa propre machine
virtuelle, afin de pouvoir utiliser toutes les ressources sans interférence.
L’utilisation de matériel partagé peut entraîner des conflits de ressources et une dégradation
des performances, ce qui a un impact sur la fiabilité globale du système.
4. Utilisez des jeux de répliques pour les serveurs de shard
Il est essentiel de surveiller les performances de vos grappes pour identifier les problèmes
avant qu’ils ne deviennent majeurs. Vous devez surveiller l’unité centrale, la mémoire, les
entrées/sorties de disque et les entrées/sorties de réseau pour chaque serveur de grappes
afin de vous assurer que la grappe est en mesure de gérer la charge de travail.
Vous pouvez utiliser les outils de surveillance intégrés à MongoDB, tels que mongostat et
mongotop, ou des outils de surveillance tiers, tels que Datadog, Dynatrace et Zabbix, pour
suivre les performances des serveurs partagés.
La planification de la reprise après sinistre est essentielle pour maintenir la fiabilité de votre
cluster MongoDB. Vous devez disposer d’un plan de reprise après sinistre comprenant des
sauvegardes régulières, des tests de validité des sauvegardes et un plan de restauration des
sauvegardes en cas de défaillance.
Lorsque les applications émettent des requêtes basées sur des plages, la mise en rangée est
bénéfique car les opérations peuvent être limitées à un plus petit nombre de disques, le plus
souvent à un seul. Vous devez comprendre vos données et les modèles de requête pour
mettre en œuvre cette solution.
La répartition par hachage garantit une distribution uniforme des lectures et des écritures.
Cependant, il ne permet pas d’effectuer des opérations efficaces basées sur des plages.
L’une des décisions les plus cruciales que vous prendrez lors du sharding de votre base de
données MongoDB est le choix de la clé de sharding. Cette clé détermine la manière dont les
données sont réparties entre les différents serveurs, et le choix d’une mauvaise clé peut
entraîner une répartition inégale des données, des points chauds et des performances
médiocres.
Une erreur fréquente consiste à choisir une valeur de clé de répartition qui n’augmente que
pour les nouveaux documents lorsque vous utilisez une répartition basée sur une plage plutôt
qu’une répartition par hachage. Par exemple, un horodatage (naturellement) ou tout ce qui a
une composante temporelle comme élément le plus important, comme ObjectID (les quatre
premiers octets sont un horodatage).
Si vous sélectionnez une clé de dépôt, toutes les insertions iront dans le bloc ayant la plus
grande plage. Même si vous ajoutez sans cesse de nouvelles unités, votre capacité d’écriture
maximale n’augmentera jamais.
Si vous prévoyez d’augmenter la capacité d’écriture, essayez d’utiliser une clé de dépôt
basée sur le hachage, qui permettra d’utiliser le même champ tout en offrant une bonne
évolutivité en écriture.
2. Tentative de modification de la valeur de la clé de sharding
Les clés de sharding sont immuables pour un document existant, ce qui signifie que vous ne
pouvez pas modifier la clé. Vous pouvez effectuer certaines mises à jour avant le sharding,
mais pas après. Si vous essayez de modifier la clé de dépôt d’un document existant, vous
obtiendrez l’erreur suivante :
Vous pouvez supprimer et réinsérer le document pour réorganiser la clé de sharding au lieu
d’essayer de la modifier.
Pour éviter cette erreur, vous devez mettre en place des outils de surveillance permettant de
suivre des paramètres clés tels que l’utilisation du processeur, de la mémoire, de l’espace
disque et du trafic réseau. Vous devez également mettre en place des alertes lorsque
certains seuils sont dépassés.
L’une des erreurs les plus courantes à éviter lors du sharding de votre base de données
MongoDB est d’attendre trop longtemps avant d’ajouter un nouveau shard. Lorsqu’un shard
est surchargé de données ou de requêtes, cela peut entraîner des problèmes de performance
et ralentir l’ensemble du cluster.
Supposons que vous disposiez d’un cluster imaginaire composé de deux disques durs, avec
20000 blocs (5000 considérés comme « actifs »), et que nous devions ajouter un troisième
disque dur. Ce troisième dépôt stockera finalement un tiers des blocs actifs (et des blocs
totaux).
La difficulté consiste à déterminer à quel moment le groupe de stockage cesse d’ajouter des
frais généraux et devient un atout. Nous devrions calculer la charge que le système produirait
lors de la migration des blocs actifs vers le nouveau bloc et déterminer à quel moment elle
serait négligeable par rapport au gain global du système.
Dans la plupart des scénarios, il est relativement facile d’imaginer que cette série de
migrations prendrait encore plus de temps sur un ensemble de serveurs surchargés, et qu’il
faudrait beaucoup plus de temps pour que notre nouveau serveur franchisse le seuil et
devienne un gain net. Il est donc préférable d’être proactif et d’ajouter de la capacité avant
que cela ne devienne nécessaire.
Si les serveurs de configuration sont sous-provisionnés, cela peut entraîner des problèmes
de performance et d’instabilité. Le sous-provisionnement peut être dû à une allocation
insuffisante de ressources telles que l’unité centrale, la mémoire ou le stockage.
Il peut en résulter une lenteur des requêtes, des dépassements de délai, voire des pannes.
Pour éviter cela, il est essentiel d’allouer suffisamment de ressources aux serveurs de
configuration, en particulier dans les grands clusters. La surveillance régulière de l’utilisation
des ressources des serveurs de configuration peut aider à identifier les problèmes de sous-
provisionnement.
Un autre moyen d’éviter ce problème est d’utiliser du matériel dédié pour les serveurs de
configuration, plutôt que de partager les ressources avec d’autres composants de la grappe.
Cela permet de s’assurer que les serveurs de configuration disposent de suffisamment de
ressources pour gérer leur charge de travail.
Les sauvegardes sont essentielles pour s’assurer que les données ne sont pas perdues en
cas de panne. La perte de données peut survenir pour diverses raisons, notamment une
défaillance matérielle, une erreur humaine ou une attaque malveillante.
Ne pas sauvegarder et restaurer les données peut entraîner des pertes de données et des
temps d’arrêt. Pour éviter cette erreur, vous devez mettre en place une stratégie de
sauvegarde et de restauration comprenant des sauvegardes régulières, des sauvegardes de
test et la restauration des données dans un environnement de test.
Avant de déployer votre cluster partagé en production, vous devez le tester complètement
pour vous assurer qu’il peut gérer la charge et les requêtes attendues. Ne pas tester le
cluster partagé peut entraîner des performances médiocres et des pannes.
Le sharding est une technique de mise à l’échelle horizontale qui distribue les données sur de
nombreux nœuds, ce qui en fait une solution efficace pour gérer les grands ensembles de
données avec des taux d’écriture élevés. Elle est transparente pour les applications, ce qui
leur permet d’interagir avec MongoDB comme s’il s’agissait d’un serveur unique.
D’autre part, les index en grappe améliorent les performances des requêtes qui récupèrent
des données à partir de grands ensembles de données en permettant à MongoDB de
localiser les données plus efficacement lorsqu’une requête correspond au champ indexé.
Alors, lequel des deux est le plus efficace pour les grands ensembles de données ? La
réponse dépend du cas d’utilisation spécifique et des exigences de la charge de travail.
Le sharding et les index en grappe sont tous deux des outils puissants pour la gestion de
grands ensembles de données dans MongoDB. L’essentiel est d’évaluer soigneusement les
exigences de votre application et les caractéristiques de la charge de travail afin de
déterminer la meilleure approche pour votre cas d’utilisation spécifique.
Résumé
Un cluster sharded est une architecture puissante qui peut gérer de grandes quantités de
données et évoluer horizontalement pour répondre aux besoins d’applications en pleine
croissance. Le cluster est constitué de shards, de serveurs de configuration, de processus
mongos et d’applications clientes, et les données sont partitionnées sur la base d’une clé de
shard choisie avec soin pour garantir une distribution et une interrogation efficaces.
En tirant parti de la puissance du sharding, les applications peuvent bénéficier d’une haute
disponibilité, de performances améliorées et d’une utilisation efficace des ressources
matérielles. Le choix de la bonne clé de répartition est crucial pour une distribution homogène
des données.