MongoDB MMAPv1 vs moteurs de stockage WiredTiger
Dans mongoDB3 est apparu un nouveau moteur de stockage: WiredTiger . Pourtant, MMAPv1 est toujours le choix par défaut dans Mongo.
L'un n'est peut-être pas meilleur que l'autre, c'est souvent une question de cas d'utilisation et de choix du bon outil pour le travail. Mais quel moteur convient à quel travail?
En réalité, alors que MMAPv1 est le moteur par défaut, WiredTiger semble meilleur dans presque tous les domaines. Il a les mêmes fonctionnalités que MMAPv1 plus:
- de meilleures performances d'écriture,
- simultanéité au niveau du document,
- compression,
- système d'instantanés et de points de contrôle.
J'ai trouvé un tableau comparatif sur le blog de MongoDB :
Donc, sauf si vous êtes sur Solaris, y a-t-il une raison pour ne pas choisir WiredTiger?
ÉDITER
Voici deux vidéos qui expliquent en détail les composants internes de WiredTiger et MMAPv1 .
Personnellement, je préfère le moteur de stockage mmapv1 dès maintenant pour trois raisons.
Raison 1: Maturité
Ce n'est pas que WiredTiger est immature. Mais mmapv1 est bien compris et testé au combat de haut en bas, d'avant en arrière et au-dessus et au-delà. WiredTiger a eu quelques problèmes graves (voir http://jira.mongodb.com pour plus de détails) assez récemment, et je ne suis pas disposé à ce que mes clients trouvent le prochain à la dure.
Raison 2: Caractéristiques
Étant donné, WT a des fonctionnalités f ... incroyablement impressionnantes. Le truc est que: je n'ai vu personne en bénéficier. Compression? De toute façon, vous vous sacrifiez plutôt dur pour obtenir des performances plutôt bon marché espace disque. Manque de problème de migration des documents pour l'expansion des documents? Eh bien, nous avons toujours la limite de taille de 16 Mo et une complexité supplémentaire pour les documents incorporés, en particulier lorsque l'incorporation est exagérée.
Il existe d'autres fonctionnalités, mais en général: je ne vois pas grand-chose à en tirer pour l'instant.
Raison 3: coût total de possession
Pour les nouveaux projets, WT peut convenir, surtout depuis la version 3.2, car ce qui suit ne s'applique pas.
Faire des migrations de données est cher. Il doit être planifié, le plan doit être approuvé par toutes les parties prenantes, des plans d'urgence doivent être créés et approuvés, la migration doit être préparée, exécutée et revue. Multipliez maintenant le temps nécessaire avec les parties prenantes qui font partie de ce processus, et les coûts de la migration des données montent en flèche. Le retour sur investissement semble en revanche assez faible. Vous pouvez évoluer un peu au lieu de faire une migration si vous tenez compte de ces facteurs. Pour vous donner une impression: j'évaluerais environ une "semaine-homme" par intervenant si une migration est planifiée, exécutée et examinée correctement. Avec des coûts de 100 $ par heure et par personne, et seulement trois personnes impliquées (gestionnaire, DBA et développeur), cela représente 12 000 $. Notez qu'il s'agit d'une estimation prudente.
Conclusion
Tous ces facteurs ci-dessus m'ont amené à la conclusion de ne pas utiliser WT que ce soit. Pour le moment.
Mise à jour
Ce message a maintenant quelques mois, il mérite donc une mise à jour
À maturité
Mes commentaires originaux sur la maturité sont en quelque sorte obsolètes. WiredTiger n'a plus eu de problèmes majeurs depuis un moment et est devenu le moteur de stockage par défaut à partir de MongoDB 3.2
Sur les fonctionnalités
Mes commentaires originaux sont toujours valables, à mon humble avis.
Compression
Cependant, lorsque le budget est serré ou, plus généralement, les performances ne sont pas la principale préoccupation, le compromis entre les performances est plutôt faible et vous échangez essentiellement de légers impacts sur les performances (par rapport au WT non compressé) pour l'espace disque, en utilisant ce qui autrement serait inactif autour: le CPU.
Chiffrement
MongoDB 3.2 Enterprise a introduit la possibilité de chiffrer les stockages WiredTiger. Pour les données avec des besoins de sécurité améliorés, il s'agit d'une fonctionnalité de tueur et fait de WT le seul moteur de stockage de choix, à la fois techniquement (MMAPv1 ne prend pas en charge le cryptage) et conceptuellement. Mettre de côté la possibilité de disque crypté des partitions, bien sûr, bien que vous ne puissiez pas avoir cette option dans certains environnements.
Verrouillage au niveau du document
Je dois admettre que j'ai essentiellement omis cette fonctionnalité de WT dans mon analyse ci-dessus, principalement parce qu'elle ne s'appliquait pas à moi ou à mes clients lorsque j'ai écrit la réponse d'origine.
En fonction de votre configuration, principalement lorsque vous avez de nombreux clients d'écriture simultanés, cette fonctionnalité peut améliorer considérablement les performances.
Sur le coût total de possession
Faire des migrations coûte toujours cher. Cependant, compte tenu des changements de maturité et du changement de vue sur les fonctionnalités, une migration peut valoir la peine d'être investie si:
- Vous avez besoin d'un chiffrement (Enterprise Edition uniquement!)
- La performance n'est pas votre principale préoccupation absolue et vous pouvez économiser de l'argent à long terme (calculer de manière prudente) en utilisant la compression
- De nombreux processus écrivent simultanément, car l'augmentation des performances peut vous faire économiser une mise à l'échelle verticale ou horizontale.
Conclusion mise à jour
Pour les nouveaux projets, j'utilise WiredTiger maintenant. Étant donné qu'une migration d'un stockage WiredTiger compressé vers un stockage WiredTiger non compressé est plutôt facile, j'ai tendance à commencer par la compression pour améliorer l'utilisation du processeur ("en avoir plus pour son argent"). Si la compression a un impact notable sur les performances ou l'UX, je migre vers WiredTiger non compressé.
Pour les projets avec beaucoup d'écrivains simultanés, la réponse à la question de savoir si migrer ou non est presque toujours "Oui" aussi - à moins que le budget du projet n'interdise l'investissement. À long terme, l'augmentation des performances devrait s'autofinancer si le déploiement était autrement raisonnablement planifié. Cependant, vous devez ajouter un certain temps de développement au calcul, car dans certains cas, le pilote doit être mis à jour et il peut y avoir des problèmes qui doivent être traités.
Pour les projets qui ont un budget serré et ne peuvent pas se permettre plus d'espace disque pour le moment, la migration vers un WiredTiger compressé peut être une option, mais la compression met un peu de charge sur le CPU, ce qui est du jamais vu avec MMAPv1. De plus, les coûts de migration pourraient être prohibitifs pour un tel projet.
Mes deux centimes:
La journalisation dans WiredTiger peut perdre des mises à jour dans les arrêts durs car elle utilise la mise en mémoire tampon en mémoire pour stocker les enregistrements de journal.
Entre les opérations d'écriture, alors que les enregistrements de journal restent dans les tampons WiredTiger, les mises à jour peuvent être perdues suite à un arrêt brutal de mongod.
La journalisation dans MMAPv1 écrit les modifications dans les fichiers journaux sur disque.
Si l'instance de mongod venait à planter sans avoir appliqué les écritures aux fichiers de données, le journal pourrait relire les écritures dans la vue partagée pour une éventuelle écriture dans les fichiers de données.
Nous sommes passés à WiredTiger de MMAPv1 avec l'attrait d'un gain de performances de 7x à 10x. Nous avons dû revenir à MMAPv1 car MongoDB se bloquerait lorsque le cache WiredTiger atteindrait 100%. Nous avons documenté notre expérience ici - https://blog.clevertap.com/sleepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmapv1/