Le déploiement d'une base de données en cluster est une chose, mais la façon dont vous maintenez votre DBM en cluster peut être une entreprise importante pour un service cohérent de vos applications. Il faut avoir une mise à jour régulière sur l'état de la base de données, en particulier les mesures les plus cruciales, afin d'avoir une idée de ce qu'il faut mettre à niveau ou plutôt modifier pour éviter tout goulot d'étranglement qui pourrait survenir.
Il y a beaucoup de considérations concernant MongoDB à prendre en compte, en particulier le fait que son installation et son exécution sont assez faciles, les chances de négliger les pratiques de gestion de base de données de base sont élevées.
Souvent, les développeurs ne tiennent pas compte de la croissance future et de l'utilisation accrue de la base de données, ce qui entraîne par conséquent un plantage de l'application ou des données avec des problèmes d'intégrité en plus d'être incohérent.
Dans cet article, nous allons discuter de certaines des meilleures pratiques à utiliser pour le cluster MongoDB pour une performance efficace de vos applications. Certains des facteurs à prendre en compte incluent...
- Mise à niveau vers la dernière version
- Moteur de stockage approprié
- Allocation des ressources matérielles
- Réplication et partitionnement
- Ne modifiez jamais le fichier de configuration du serveur
- Bonne stratégie de sécurité
Mise à niveau vers la dernière version
J'ai travaillé avec MongoDB à partir de versions antérieures à la 3.2 et pour être honnête, les choses n'étaient pas faciles à cette époque. Avec de grands développements, des bugs corrigés et des fonctionnalités nouvellement introduites, je vous conseillerai de toujours mettre à jour votre base de données vers la dernière version. Par exemple, l'introduction du cadre d'agrégation a eu un meilleur impact sur les performances plutôt que de s'appuyer sur le concept Map-Reduce qui existait déjà. Avec la dernière version 4.0, on a maintenant la possibilité d'utiliser la fonctionnalité de transactions multi-documents qui améliore généralement les opérations de débit. La dernière version contient également de nouveaux opérateurs de conversion de type supplémentaires tels que $toInt, $toString, $trim et $toBool. Ces opérateurs aideront grandement à la validation des données, créant ainsi un certain sens de la cohérence des données. Lors de la mise à niveau, veuillez vous référer à la documentation afin d'éviter de faire de légères erreurs qui pourraient devenir erronées.
Choisir un moteur de stockage approprié
MongoDB prend actuellement en charge 3 moteurs de stockage, à savoir :les moteurs de stockage WiredTiger, In-Memory et MMAPv1. Chacun de ces moteurs de stockage a des mérites et des limites par rapport à l'autre, mais votre choix dépendra des spécifications de votre application et des fonctionnalités de base du moteur. Cependant, je préfère personnellement le moteur de stockage WiredTiger et je le recommanderais à ceux qui ne savent pas lequel utiliser. Le moteur de stockage WiredTiger est bien adapté à la plupart des charges de travail, fournit un modèle de concurrence au niveau du document, des points de contrôle et une compression.
Certaines des considérations concernant les sélections de moteur de stockage dépendent de ces aspects :
- Transactions et atomicité : fourniture de données lors d'une insertion ou d'une mise à jour qui n'est validée que lorsque toutes les conditions et étapes d'application ont été exécutées avec succès. Les opérations sont donc regroupées dans une unité immuable. Avec cela en place, la transaction multi-documents peut être prise en charge, comme le montre la dernière version de MongoDB pour le moteur de stockage WiredTiger.
- Type de verrouillage : c'est une stratégie de contrôle sur l'accès ou la mise à jour des informations. Pendant la durée du verrouillage, aucune autre opération ne peut modifier les données de l'objet sélectionné tant que l'opération en cours n'a pas été exécutée. Par conséquent, les requêtes sont affectées à ce stade, il est donc important de les surveiller et de réduire le volume du mécanisme de verrouillage en vous assurant de sélectionner le moteur de stockage le plus approprié pour vos données.
- Indexation : Les moteurs de stockage dans MongoDB fournissent différentes stratégies d'indexation en fonction des types de données que vous stockez. L'efficacité de cette structure de données devrait être assez compatible avec votre charge de travail et vous pouvez le déterminer en considérant chaque index supplémentaire comme ayant une surcharge de performances. Les structures de données optimisées en écriture ont une surcharge inférieure pour chaque index dans un environnement d'application à insertion élevée que les structures de données optimisées en écriture. Ce sera un revers majeur, en particulier lorsqu'un grand nombre d'index est impliqué et la sélection d'un moteur de stockage inapproprié. Par conséquent, le choix d'un moteur de stockage approprié peut avoir un impact considérable.
Allocation des ressources matérielles
Au fur et à mesure que de nouveaux utilisateurs se connectent à votre application, la base de données s'agrandit avec le temps et de nouvelles partitions seront introduites. Cependant, vous ne pouvez pas compter sur les ressources matérielles que vous avez établies lors de la phase de déploiement. Il y aura une augmentation correspondante de la charge de travail et nécessitera donc plus de ressources de traitement telles que le processeur et la RAM pour prendre en charge vos grands clusters de données. Cela fait souvent référence à la planification des capacités dans MongoDB. Les meilleures pratiques en matière de planification des capacités incluent :
- Surveillez votre base de données en permanence et ajustez-la en fonction des attentes. Comme mentionné précédemment, une augmentation du nombre d'utilisateurs déclenchera désormais davantage de requêtes avec une charge de travail accrue, en particulier si vous utilisez des index. Vous pouvez commencer à ressentir ces impacts sur la fin de l'application lorsqu'elle commence à enregistrer une modification du pourcentage d'écritures par rapport aux lectures avec le temps. Vous devrez donc reconfigurer vos configurations matérielles afin de résoudre ce problème. Utilisez mongoperf et l'outil MMS pour détecter les modifications des paramètres de performances du système.
- Documentez toutes vos exigences de performance dès le départ. Lorsque vous rencontrez le même problème vous aurez au moins un point de référence qui vous fera gagner du temps. Votre enregistrement doit impliquer la taille des données que vous souhaitez stocker, l'analyse des requêtes en termes de latence et la quantité de données auxquelles vous souhaitez accéder à un moment donné. Dans un environnement de production, vous devez déterminer le nombre de requêtes que vous allez traiter par seconde et enfin la latence que vous allez tolérer.
- Effectuer une preuve de concept. Effectuez une conception de schéma/index et comprenez les modèles de requête, puis affinez votre estimation de la taille de l'ensemble de travail. Enregistrez cette configuration comme point de référence pour les tests avec les révisions successives de l'application.
- Faites vos tests avec une charge de travail réelle. Après avoir réalisé l'étape du concept de preuve, ne déployez qu'après avoir effectué des tests substantiels avec des données réelles et des exigences de performances.
Réplication et partage
Ce sont les deux concepts majeurs pour assurer respectivement la haute disponibilité des données et une évolutivité horizontale accrue dans le cluster MongoDB.
Le partitionnement partitionne essentiellement les données sur les serveurs en petites portions appelées fragments. L'équilibrage des données entre les partitions est automatique, des partitions peuvent être ajoutées ou supprimées sans nécessairement mettre la base de données hors ligne.
La réplication à l'autre extrémité conserve plusieurs copies redondantes des données pour une haute disponibilité. Il s'agit d'une fonctionnalité intégrée à MongoDB et fonctionne sur des réseaux étendus sans avoir besoin de réseaux spécialisés. Pour une configuration en cluster, je vous recommande d'avoir au moins 2+ mongos, 3 serveurs de configuration, 1 partition et assurer la connectivité entre les machines impliquées dans le cluster partitionné. Utilisez un nom DNS plutôt que des adresses IP dans la configuration.
Pour les environnements de production, utilisez un jeu de réplicas avec au moins 3 membres et n'oubliez pas de remplir plus de variables de configuration comme la taille de l'oplog.
Lors du démarrage de vos instances mongod pour vos membres, utilisez le même fichier clé.
Certaines des considérations de votre shardkey devraient inclure :
- La clé et la valeur sont immuables
- Envisagez toujours d'utiliser des index dans une collection partitionnée
- La commande de mise à jour du pilote doit contenir une clé de partition
- Contraintes uniques à maintenir par la clé de partition.
- Une clé de partition ne peut pas contenir de types d'index spéciaux et ne doit pas dépasser 512 octets.
Ne jamais modifier le fichier de configuration du serveur
Après avoir effectué votre premier déploiement, il est conseillé de ne pas modifier beaucoup de paramètres dans le fichier de configuration, sinon vous risquez d'avoir des problèmes, en particulier avec les fragments. Le maillon le plus faible avec le sharding est les serveurs de configuration. C'est-à-dire que toutes les instances mongod doivent être en cours d'exécution pour que le partitionnement fonctionne.
Bonne stratégie de sécurité
MongoDB a été vulnérable aux attaques externes au cours des dernières années, d'où une entreprise importante pour votre base de données d'avoir des protocoles de sécurité. En plus d'exécuter les processus dans différents ports, il faut au moins utiliser l'une des 5 méthodes différentes de sécurisation des bases de données MongoDB. Vous pouvez envisager des plates-formes telles que MongoDB Atlas qui sécurisent les bases de données par défaut grâce au chiffrement des données en transit et au repos. Vous pouvez utiliser des stratégies telles que TLS/SSL pour toutes les connexions entrantes et sortantes.
Conclusion
Le contrôle du cluster MongoDB n'est pas une tâche facile et implique de nombreuses solutions de contournement. Les bases de données se développent en raison du nombre accru d'utilisateurs, d'où une charge de travail accrue. On a donc pour mandat de s'assurer que la performance du DBM est en adéquation avec ce nombre accru d'utilisateurs. Les meilleures pratiques vont au-delà de l'augmentation des ressources matérielles et de l'application de certains concepts MongoDB tels que le partitionnement, la réplication et l'indexation. Cependant, bon nombre des inconvénients qui peuvent survenir sont bien résolus en mettant à niveau votre version de MongoDB. Le plus souvent, les dernières versions ont des bogues corrigés, de nouvelles demandes de fonctionnalités intégrées et presque aucun impact négatif sur la mise à niveau, même avec des numéros de révision majeurs.
