Guide du développeur pour le partage MongoDB

Une croissance massive des données s'accompagne d'un coût d'opérations à débit réduit, en particulier lorsqu'elles sont servies par un seul serveur. Cependant, vous pouvez améliorer ces performances en augmentant le nombre de serveurs et en répartissant également vos données sur plusieurs numéros de ces serveurs. Dans cet article, Ensembles de répliques dans MongoDB, nous avons expliqué en détail comment les opérations de débit peuvent être améliorées en plus d'assurer une haute disponibilité des données. Ce processus ne peut pas être réalisé complètement sans mentionner Sharding dans MongoDB.

Qu'est-ce que le partage dans MongoDB

MongoDB est conçu de manière flexible, de sorte qu'il est évolutif pour que vous puissiez l'exécuter dans un cluster sur une plate-forme distribuée. Dans cette plate-forme, les données sont réparties sur un certain nombre de serveurs pour le stockage. Ce processus est ce qu'on appelle le sharding. Si un seul serveur est soumis à une grande quantité de données pour le stockage, vous risquez de manquer d'espace de stockage. De plus, les opérations de débit très critiques telles que la lecture et l'écriture peuvent être affectées dans une large mesure. La fonction de mise à l'échelle horizontale de MongoDB nous permet de répartir les données sur plusieurs machines avec pour résultat final d'améliorer l'équilibrage de charge.

Fragments MongoDB

Un fragment peut être considéré comme un jeu de répliques qui héberge un sous-ensemble de données utilisé dans un cluster fragmenté. Pour une instance mongod donnée avec un ensemble de données, les données sont divisées et réparties sur un certain nombre de bases de données, dans ce cas des fragments. Fondamentalement, un certain nombre de fragments différents servent de bases de données indépendantes, mais collectivement, ils constituent une base de données logique. Les fragments réduisent la charge de travail qui doit être exécutée par l'ensemble de la base de données en réduisant le nombre d'opérations qu'un fragment doit gérer en plus de la quantité moindre de données que ce fragment hébergera. Cette métrique donne de la place pour l'expansion d'un cluster horizontalement. Une architecture simple de partitionnement est illustrée ci-dessous.

Les données envoyées à partir d'une application cliente sont interceptées par les pilotes du serveur, puis transmises au routeur. Le routeur consultera ensuite les configurations du serveur pour déterminer où appliquer l'opération de lecture ou d'écriture sur les serveurs de fragments. En un mot, pour une opération telle que l'écriture, il a un index qui dictera à quel fragment l'enregistrement doit être l'hôte. Disons qu'une base de données a une capacité de données de 1 To répartie sur 4 partitions, chaque partition contiendra 256 Go de ces données. Avec une quantité réduite de données qu'un fragment peut gérer, les opérations peuvent être effectuées assez rapidement. Vous devriez envisager d'utiliser le cluster partitionné dans votre base de données lorsque :

Vous vous attendez à ce que la quantité de données dépasse la capacité de stockage de votre instance unique à l'avenir.
Si les opérations d'écriture ne sont pas effectuées par l'instance MongodB unique
Vous manquez de mémoire RAM à accès aléatoire au détriment de la taille accrue de l'ensemble de travail actif.

Le partage s'accompagne d'une complexité accrue dans l'architecture en plus des ressources supplémentaires. Cependant, il est conseillé d'effectuer le sharding à un stade précoce avant que vos données ne deviennent trop nombreuses, car il est assez fastidieux de le faire lorsque vos données dépassent la capacité.

Clé de partition MongoDB

Comme nous le savons tous, un document dans MongoDB a des champs pour contenir des valeurs. Lorsque vous déployez un partitionnement, vous devrez sélectionner un champ dans une collection que vous utiliserez pour fractionner les données. Ce champ que vous avez sélectionné est la clé de partition qui détermine comment vous allez diviser les documents de la collection sur un certain nombre de partitions. Dans un exemple simple, vos données peuvent avoir des noms de champ étudiants, professeurs de classe et notes. Vous pouvez décider qu'un ensemble de partitions contiendra les documents avec l'élève index, un autre enseignant et les notes. Cependant, vous pouvez exiger que vos données soient distribuées de manière aléatoire, utilisez donc une clé de fragment hachée. Il existe une gamme de clés de partition utilisées pour diviser les données en plus de la clé de partition hachée, mais les deux principales catégories sont les champs indexés et les champs composés indexés.

Choisir une clé de partage

Pour une meilleure fonctionnalité, capacité et performance de la stratégie de partitionnement, vous devrez sélectionner la clé partitionnée appropriée. Les critères de sélection dépendent de 2 facteurs :

Schéma de structure de vos données. On peut par exemple considérer un champ dont la valeur pourrait être croissante ou décroissante (évoluant de façon monotone). Cela influencera très probablement la distribution des insertions sur une seule partition au sein d'un cluster.
Comment vos configurations d'interrogation sont-elles utilisées pour effectuer des opérations d'écriture ?

Qu'est-ce qu'une clé fragmentée hachée

Cela utilise un index haché d'un seul champ comme clé de partition. Un index haché est un index qui maintient les entrées avec des hachages des valeurs d'un champ indexé.c'est-à-dire

{
    "_id" :"5b85117af532da651cc912cd"
}

Pour créer un index haché, vous pouvez utiliser cette commande dans le shell mongo.

db.collection.createIndex( { _id: hashedValue } )

Où la variable hashedValue représente une chaîne de votre valeur de hachage spécifiée. Le partage haché favorise une distribution uniforme des données sur un cluster partitionné, réduisant ainsi les opérations ciblées. Cependant, il est peu probable que des documents avec presque les mêmes clés de partition se trouvent sur la même partition, ce qui nécessite qu'une instance mongo effectue une opération de diffusion pour satisfaire un critère de requête donné.

Clé de partition basée sur la plage

Dans cette catégorie, l'ensemble de données est partitionné en fonction des plages de valeurs d'une clé de champ choisie, d'où une plage élevée de partitions. C'est à dire. si vous avez une clé numérique dont les valeurs vont de l'infini négatif à l'infini positif, chaque clé de fragment tombera sur un certain point de cette ligne. Cette ligne est divisée en morceaux, chaque morceau ayant une certaine plage de valeurs. Précisément, ces documents avec une clé de partition presque similaire sont hébergés dans le même bloc. L'avantage de cette technique est qu'elle prend en charge une gamme de requêtes puisque le routeur sélectionnera le fragment avec le morceau spécifique.

Caractéristiques d'une clé de partition optimale

Une clé de partition idéale devrait pouvoir cibler une seule partition afin d'améliorer un programme mongos pour renvoyer des opérations de requête à partir d'une seule instance mongod. La clé étant le champ primaire caractérise cela. C'est à dire. pas dans un document intégré.
Avoir un degré élevé d'aléatoire. C'est-à-dire que le champ doit être disponible dans la plupart des documents. Cela garantira que les opérations d'écriture sont distribuées au sein d'une partition.
Être facilement divisible. Avec une clé de partition facilement divisible, la distribution des données est accrue, donc plus de partitions.

Plusieursnines Devenez un administrateur de base de données MongoDB – Amener MongoDB en productionDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer MongoDBDélécharger gratuitement

Composants d'un déploiement de cluster de production

En ce qui concerne l'architecture présentée ci-dessus, le cluster de fragments de production doit avoir :

Mongos/ Interroger les routeurs. Ce sont des instances mongo qui agissent comme un serveur entre les pilotes d'application et la base de données elle-même. Lors du déploiement, l'équilibreur de charge est configuré de manière à permettre la connexion d'un seul client pour atteindre les mêmes mongos.
Fragments. Il s'agit des partitions dans lesquelles les documents partageant la même définition de clé de partition sont hébergés. Vous devez en avoir au moins 2 afin d'augmenter la disponibilité des données.
Serveurs de configuration :vous pouvez soit avoir 3 serveurs de configuration distincts sur différentes machines, soit un groupe d'entre eux si vous avez plusieurs clusters partagés.

Déploiement d'un cluster partagé

Les étapes suivantes vous donneront une orientation claire vers le déploiement de votre cluster partitionné.

Création d'un hôte pour les serveurs de configuration. Par défaut, les fichiers du serveur sont disponibles dans le répertoire /data/configdb mais vous pouvez toujours le définir sur votre répertoire préféré. La commande pour créer le répertoire de données est :
```
$ mkdir /data/configdb
```
Démarrez les serveurs de configuration en définissant le port et le chemin du fichier pour chacun à l'aide de la commande
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Cette commande démarrera le fichier de configuration dans le répertoire de données avec le nom config sur le port 27018. Par défaut, tous les serveurs MongoDB s'exécutent sur le port 27017.
Démarrez une instance mongos en utilisant la syntaxe :
```
$ mongo --host hostAddress --port 27018.
```
La variable hostAddress aura la valeur du nom d'hôte ou de l'adresse IP de votre hôte.
Démarrez mongod sur le serveur de fragments et lancez-le à l'aide de la commande :
```
mongod --shardsvr --replSet
rs.initiate()
```
Démarrez vos mongos sur le routeur avec la commande :
```
mongos --configdb rs/mongoconfig:27018
```
Ajout de partitions à votre cluster. Supposons que le port par défaut soit 27017 comme cluster, nous pouvons ajouter un fragment sur le port 27018 comme ceci :
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Activez le partitionnement pour la base de données en utilisant le nom du fragment avec la commande :

sh.enableSharding(shardname)
{ "ok" : 1 }

Vous pouvez vérifier l'état du fragment avec la commande :

sh.status()

Ces informations vous seront présentées

sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("59f425f12fdbabb0daflfa82")
}
shards:
{ "_id" : "rs", "host" : "rs/mongoshard:27018", "state" : 1 }
active mongoses:
"3.4.10" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
NaN
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ "_id" : shardname, "primary" : "rs", "partitioned" : true }

Équilibrage des partitions

Après avoir ajouté une partition à un cluster, vous pouvez observer que certaines partitions peuvent encore héberger plus de données que d'autres et, pour être plus sécantes, la nouvelle partition ne contiendra aucune donnée. Vous devez donc exécuter des vérifications en arrière-plan afin d'assurer l'équilibre de la charge. L'équilibrage est la base pour laquelle les données sont redistribuées dans un cluster. L'équilibreur détectera une distribution inégale et migrera donc des morceaux d'un fragment à un autre jusqu'à ce qu'un quorum d'équilibre soit atteint.

Le processus d'équilibrage consomme beaucoup de bande passante en plus des charges de travail, ce qui affectera le fonctionnement de votre base de données. Un meilleur processus d'équilibrage implique :

Déplacer un seul bloc à la fois.
Effectuez l'équilibrage lorsque le seuil de migration est atteint, c'est-à-dire lorsque la différence entre le plus petit nombre de blocs pour une collection donnée et le plus grand nombre de blocs dans la collection fragmentée.