Après avoir développé votre modèle d'application et de base de données (lorsqu'il est temps de mettre l'environnement en production), il y a quelques choses à faire en premier. Souvent, les développeurs ne prennent pas en compte les étapes MongoDB importantes supplémentaires avant de déployer la base de données en production. Par conséquent, c'est dans le mode de production qu'ils finissent par rencontrer des revers sous-jacents qui ne sont pas présentés dans le mode de développement. Parfois, il peut être trop tard ou plutôt beaucoup de données seraient perdues en cas de catastrophe. En outre, certaines des étapes décrites ici permettront d'évaluer la santé de la base de données et donc de planifier les mesures nécessaires avant qu'une catastrophe ne se produise.
Utiliser la version actuelle et les derniers pilotes
Généralement, les dernières versions de n'importe quelle technologie offrent des fonctionnalités améliorées en ce qui concerne les fonctionnalités sous-jacentes par rapport à leurs prédécesseurs. Les dernières versions de MongoDB sont plus robustes et améliorées que leurs prédécesseurs en termes de performances, d'évolutivité et de capacité mémoire. Il en va de même pour les pilotes associés, car ils sont développés par les principaux ingénieurs de la base de données et sont mis à jour plus fréquemment que la base de données elle-même.
Les extensions natives installées pour votre langue peuvent facilement constituer une plate-forme pour des procédures rapides et standard de test, d'approbation et de mise à niveau des nouveaux pilotes. Il existe également des logiciels automobiles tels que Ansible, Puppet, SaltStack et Chef qui peuvent être utilisés pour une mise à niveau facile de MongoDB dans tous vos nœuds sans engager de dépenses professionnelles ni de temps.
Envisagez également d'utiliser le moteur de stockage WiredTiger car il est le plus développé avec des fonctionnalités modernes qui répondent aux attentes des bases de données modernes
Abonnez-vous à une liste de diffusion MongoDB pour obtenir les dernières informations concernant les modifications apportées aux nouvelles versions et pilotes et les corrections de bogues, afin de rester à jour.
Utiliser un système 64 bits pour exécuter MongoDB
Dans les systèmes 32 bits, les processus MongoDB sont limités à environ 2,5 Go de données, car la base de données utilise des fichiers mappés en mémoire pour les performances. Cela devient une limitation pour les processus susceptibles de dépasser la limite menant à un béguin. L'impact principal sera le suivant :en cas d'erreur, vous ne pourrez pas redémarrer le serveur tant que vous n'aurez pas supprimé vos données ou migré votre base de données vers un système supérieur tel que le 64 bits, d'où un temps d'arrêt plus élevé pour votre application.
Si vous devez continuer à utiliser un système 32 bits, votre codage doit être très simple pour réduire le nombre de bogues et la latence des opérations de débit.
Toutefois, pour les complexités du code telles que le pipeline d'agrégation et les géodonnées, il est conseillé d'utiliser le système 64 bits.
Assurez-vous que les documents sont limités à une taille de 16 Mo
Les documents MongoDB sont limités à la taille de 16 Mo, mais vous n'avez pas besoin de vous approcher de cette limite car cela impliquera une certaine dégradation des performances. En pratique, les documents sont pour la plupart de taille Ko ou moins. La taille du document dépend de la stratégie de modélisation des données entre l'incorporation et le référencement. L'incorporation est préférée lorsque la taille du document ne devrait pas augmenter beaucoup. Par exemple, si vous avez une application de médias sociaux où les utilisateurs publient et qu'elle contient des commentaires, la meilleure pratique consistera à avoir deux collections, une pour conserver les informations de publication.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}et l'autre pour conserver les commentaires de ce message.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}En ayant de tels modèles de données, les commentaires seront stockés dans une collection différente de la publication. Cela empêche le document de la collection de publications de dépasser les limites au cas où il y aurait autant de commentaires. Assurez-vous d'éviter les modèles d'application qui permettraient aux documents de se développer sans limite.
Assurez-vous que l'ensemble de travail tient dans la mémoire
La base de données peut ne pas réussir à lire les données de la mémoire virtuelle (RAM), ce qui entraîne des défauts de page. Les défauts de page obligent la base de données à lire les données d'un disque physique, ce qui entraîne une latence accrue et, par conséquent, un décalage des performances globales de l'application. Les défauts de page se produisent en raison du travail avec un grand ensemble qui ne tient pas dans la mémoire. Cela peut être dû au fait que certains documents ont une taille illimitée ou une mauvaise stratégie de partitionnement. Les solutions aux défauts de page seront :
- S'assurer que les documents sont limités à la taille de 16 Mo.
- Assurer une bonne stratégie de partitionnement en sélectionnant une clé de partitionnement optimale qui limitera le nombre de documents auxquels une opération de débit sera soumise.
- Augmentez la taille de l'instance MongoDB pour accueillir plus d'ensembles de travail.
Assurez-vous d'avoir des jeux de répliques en place
Dans le monde des bases de données, il n'est pas idéal de s'appuyer sur une seule base de données, car une catastrophe peut survenir. En outre, vous vous attendez à une augmentation du nombre d'utilisateurs de la base de données, d'où la nécessité d'assurer une haute disponibilité des données. La réplication est une approche cruciale pour garantir une haute disponibilité en cas de basculement. MongoDB a la capacité de servir les données géographiquement :ce qui signifie que les utilisateurs de différents endroits seront servis par l'hôte cloud le plus proche comme un moyen de réduire la latence des demandes.
En cas de défaillance du nœud principal, les nœuds secondaires peuvent en choisir un nouveau pour suivre les opérations d'écriture plutôt que l'application ayant un temps d'arrêt pendant le basculement. En fait, certaines plates-formes d'hébergement cloud qui sont assez attentives à la réplication ne prennent pas en charge MongoDB non répliqué pour les environnements de production.
Activer la journalisation
Même si la journalisation implique une certaine dégradation des performances, elle est également importante. La journalisation améliore les opérations d'écriture anticipée, ce qui signifie qu'en cas d'échec de la base de données lors du processus de mise à jour, la mise à jour aurait été enregistrée quelque part et lorsqu'elle reprendrait vie, le processus pourrait être terminé. La journalisation peut facilement faciliter la récupération après un crash et doit donc être activée par défaut.
Assurez-vous de configurer une stratégie de sauvegarde
De nombreuses entreprises échouent après une perte de données en raison de systèmes de sauvegarde inexistants ou médiocres. Avant de déployer votre base de données en production, assurez-vous d'avoir utilisé l'une de ces stratégies de sauvegarde :
- Mongodump :optimal pour les petits déploiements et lors de la production de sauvegardes filtrées sur des besoins spécifiques.
- Copie sous-jacente :optimal pour les grands déploiements et approche efficace pour effectuer des sauvegardes complètes et les restaurer.
- Service de gestion MongoDB (MMS) :fournit une sauvegarde en ligne continue pour MongoDB en tant que service entièrement géré. Optimal pour un cluster partitionné et des jeux de réplicas.
Les fichiers de sauvegarde ne doivent pas non plus être stockés chez le même fournisseur d'hébergement de la base de données. Backup Ninja est un service qui peut être utilisé pour cela.
Soyez prêt pour les requêtes lentes
On peut difficilement réaliser des requêtes lentes dans l'environnement de développement en raison du peu de données impliquées. Cependant, cela peut ne pas être le cas en production étant donné que vous aurez de nombreux utilisateurs ou que beaucoup de données seront impliquées. Des requêtes lentes peuvent survenir si vous n'avez pas utilisé d'index ou si vous avez utilisé une clé d'indexation qui n'est pas optimale. Néanmoins, nous devrions trouver un moyen qui vous montrera la raison des requêtes lentes.
Nous décidons donc d'activer MongoDB Query Profiler. Dans la mesure où cela peut entraîner une dégradation des performances, le profileur aidera à exposer les problèmes de performances. Avant de déployer votre base de données, vous devez activer le profileur pour les collections dont vous pensez que les requêtes sont lentes, en particulier celles qui impliquent des documents comportant de nombreuses incorporations.
Se connecter à un outil de surveillance
La planification des capacités est une entreprise essentielle dans MongoDB. Vous aurez également besoin de connaître la santé de votre base de données à tout moment. Pour plus de commodité, connecter votre base de données à un outil de surveillance vous fera gagner du temps pour réaliser ce dont vous avez besoin pour améliorer votre base de données avec le temps. Par exemple, une représentation graphique qui indique des performances lentes du processeur en raison de l'augmentation des requêtes vous demandera d'ajouter plus de ressources matérielles à votre système.
Les outils de surveillance disposent également d'un système d'alerte par courrier ou messages courts qui vous informent de manière pratique sur certains problèmes avant qu'ils ne dégénèrent en catastrophe. Par conséquent, en production, assurez-vous que votre base de données est connectée à un outil de surveillance.
ClusterControl fournit une surveillance gratuite de MongoDB dans l'édition communautaire.
Mettre en œuvre des mesures de sécurité
La sécurité de la base de données est une autre caractéristique importante qui doit être strictement prise en compte. Vous devez protéger l'installation de MongoDB en production en vous assurant que certaines listes de contrôle de sécurité de pré-production sont respectées. Certaines des considérations sont :
- Configuration du contrôle d'accès basé sur les rôles
- Activer le contrôle d'accès et appliquer l'authentification
- Chiffrement des connexions entrantes et sortantes (TLS/SSL)
- Limiter l'exposition du réseau
- Chiffrer et protéger les données
- Avoir un plan de suivi sur l'accès et les modifications apportées aux configurations de la base de données
Évitez les injections externes en exécutant MongoDB avec des options de configuration sécurisées. Par exemple, désactiver les scripts côté serveur si vous n'utilisez pas les opérations côté serveur JavaScript telles que mapReduce et $where. Utilisez le validateur JSON pour vos données de collecte via certains modules comme la mangouste pour vous assurer que tous les documents stockés sont au format BSON valide.
Considérations matérielles et logicielles
MongoDB a peu de prérequis matériels, car il est explicitement conçu avec une grande considération pour le matériel de base nécessaire. Voici les principales délibérations sur le matériel pour MongoDB que vous devez prendre en compte avant le déploiement en production.
- Attribuer une RAM et un processeur adéquats
- Utilisez le moteur de stockage WiredTiger. Conçu pour utiliser le cache du système de fichiers et le cache interne WiredTiger, d'où des performances accrues. Par exemple, lorsqu'il fonctionne avec un système de 4 Go de RAM, le cache WiredTiger utilise 1,5 Go de RAM ( 0,5 * (4 Go -1 Go) =1,5 Go) tandis qu'un système avec 1,2 Go de RAM WiredTiger n'utilise que 256 Mo.
- Matériel NUMA. Il existe de nombreux problèmes opérationnels, notamment des performances lentes et une utilisation élevée des processus système. Par conséquent, il convient d'envisager de configurer une règle d'entrelacement de la mémoire.
- Système de disque et de stockage :utilisez des disques SSD :MongoDB affiche un meilleur rapport qualité-prix avec les disques SSD SATA
Conclusion
Les bases de données en production sont très importantes pour assurer le bon fonctionnement d'une entreprise et doivent donc être traitées avec beaucoup de considérations. Il convient de définir certaines procédures qui peuvent aider à réduire les erreurs ou plutôt fournir un moyen facile de trouver ces erreurs. En outre, il est conseillé de mettre en place un système d'alerte qui indiquera l'état de la base de données avec le temps de planifier la capacité et de détecter les problèmes avant qu'ils ne se transforment en catastrophe.
