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 fait, 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?

MODIFIER

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 les 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 incroyablement impressionnantes. Le fait est que je n'ai vu personne en bénéficier. Compression? Quoi qu'il en soit, vous sacrifiez assez fort pour obtenir des performances pour un espace disque plutôt bon marché. Manque de problème de migration de documents pour développer des documents? Eh bien, nous avons toujours la limite de taille de 16 Mo et une complexité supplémentaire pour les documents intégrés, en particulier lorsque l'intégration est exagérée.

Il y a d'autres fonctionnalités, mais en général: je ne vois pas grand-chose en bénéficier pour l'instant .

Raison 3: coût total de possession

Pour les nouveaux projets, WT peut convenir, en particulier depuis la version 3.2, car les éléments suivants ne s'appliquent pas.

Faire des migrations de données coûte 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 participent à ce processus, et les coûts de la montée en flèche de la migration des données. 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 (directeur, 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. En ce 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 pas eu de problèmes majeurs depuis un moment maintenant 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.

Cryptage

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. Éviter la possibilité de partitions de disque chiffrées, bien sûr, bien que vous n'ayez peut-être pas 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. Puisqu'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 peu de 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, chose inouïe 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 lors d'arrêts brusques 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 après 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 rejouer les écritures dans la vue partagée pour une éventuelle écriture dans les fichiers de données.

Nous sommes passés à WiredTiger de MMAPv1 sur 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/