MongoDB MMAPv1 vs moteurs de stockage WiredTiger

25

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 :

Comparaison WiredTiger et MMAPv1

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 .

Buzut
la source
Toutes les personnes ici ... vous pouvez visiter blog.clevertap.com/… pour une très bonne explication sur le sujet
therealprashant

Réponses:

26

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.

Markus W Mahlberg
la source
Merci Markus pour votre réponse. Je comprends vos arguments. Recommanderiez-vous même de revenir par défaut à MMAPv1 pour les nouveaux projets? Je veux dire, si les performances sont un problème, la compression peut également être totalement désactivée. L'espace disque est bon marché, mais la compression peut aider l'ajustement de l'ensemble de travail dans la RAM… et donc gagner en performances. Ou ai-je tort?
Buzut
1
Pour autant que je sache, la compression n'est appliquée qu'aux fichiers de données. En ce qui concerne les nouveaux projets, permettez-moi de le dire ainsi: j'appellerais une décision de gestion, affichant les avantages et les inconvénients. Personnellement, j'utilise WT dans l'un de mes projets et je n'ai pas encore rencontré de problèmes, mais il peut y avoir d'autres facteurs tels que les SLA (que je peux calculer assez bien en fonction de l'expérience avec mmapv1), des budgets serrés (qui nécessiteraient du WT compressé pour économiser de l'espace disque) et de nombreux autres facteurs. La pondération des risques et des opportunités n'est pas une décision des DBA. Un DBA doit fournir les informations nécessaires pour passer un appel.
Markus W Mahlberg
1
Cet article semble indiquer que la façon dont les index sont stockés est un énorme avantage car il peut réduire l'espace de 10 fois vos index: ilearnasigoalong.blogspot.com/2015/03/… . L'espace disque est bon marché, mais pas le ram.
BT
Je suis un peu confus au sujet de votre point sur les fonctionnalités, êtes-vous en train de dire qu'il y a des fonctionnalités que MMAPv1 a que WiredTiger n'a pas? Ce serait bien si cette section était un peu plus claire.
BT
@BT Pas du tout. Ce que j'essayais de dire, c'est que WT a des fonctionnalités assez intéressantes qui, dans certains cas d'utilisation, peuvent être utiles, mais ne sont pas en général. Je préfère un moteur de stockage éprouvé au combat à la pointe en matière de stockage de données. Selon l'article: Oui, il est possible avec la compression de préfixe d'économiser de la RAM, et cela pourrait bien être une bonne idée s'il n'y avait pas d'autre problème. Imaginez que vous puissiez être considéré comme fiable en cas de perte de données ou de problèmes de performances.
Markus W Mahlberg,
5

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.

gabrielgiussi
la source
4

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/

Anand
la source
2
Beau résumé. Cela me rappelle un peu qu'Uber est passé de MySQL à PostgreSQL en 2013 puis à MySQL en juin 2016.
RolandoMySQLDBA
bien expliqué, nous avons également la même expérience avec le tigre filaire, nous l'avons donc fait passer à MMAPV1
viren