Et voilà, la version 3 de MongoDB est disponible depuis le 3 Février 2015 et nous arrive avec beaucoup de changements, en particulier en ce qui concerne les performances.


FINAL - 3.0Launch-Infographic-v7-1

Ces chiffres font rêver mais sont quand même à relativiser car vous ne verrez pas vos performances s’améliorer de 80%. Tout dépend du cas d’usage, mais toujours est-il que le système d’allocation des données ainsi que l’accès à ces dernières a été entièrement revu.

I. Nouveautés

  • Gestion des locks au niveau des collections et documents, selon le moteur utilisé (MMAPv1, WiredTiger)
  • Un nouveau moteur de stockage: WiredTiger
  • Compression des données stockées (WiredTiger).
  • Le nombre de Replica Set augmenté à 50, contre 12 avant
  • Performances accrues pour les indexes
  • Une nouvelle version de MMS à déployer en local (nommée Ops Manager).
  • Amélioration de la sécurité
  • Les tools mongodump, mongorestore… ont été réécrits en Go et sont du coup plus rapides

II. Locks

Dans MongoDB, que ce soit pour de la lecture ou de l’écriture, un lock va être créé avant de commencer à accéder aux données.

  • Un lock en lecture peut être partagé entre plusieurs opérations de lecture.
  • Un lock d’écriture ne peut pas être partagé, donc aucune autre opération ne peut avoir lieu en même temps

Les locks peuvent donc être très pénalisants (surtout en écriture) puisque l’accès à la base est interdit pendant la mise à jour d’une donnée. Les temps d’écriture sont très importants pour les performances globales.

Avant la version 3, les locks se situaient au niveau de la base, ce qui signifiait qu’un accès à un document dans une collection bloquait toutes autres opérations sur l’ensemble de la base.

A partir de la version 3, les locks sont gérés de manières plus fines:

  • au niveau collection pour le moteur MMAPv1
  • voir au niveau document pour WiredTiger

Les performances sont donc grandement améliorées, surtout sur une base qui reçoit un grand nombre d’opérations d’écriture.

II. Moteurs de base de données: MMAPv1 vs WiredTiger

La première révolution de la version 3 est qu’un nouveau moteur de base de données est disponible, WiredTiger.

Mais attention, l’instance mongod se lancera par défaut avec MMAPv1. L’utilisation de WiredTiger se fera via une nouvelle option –storageEngine disponible au moment de l’initialisation de votre process “mongod”.

Ceci afin de ne pas casser la compatibilité avec les anciennes versions.

En effet, la structure des fichiers (définie avec l’option –dbpath) crée par un mécanisme MMAP, est complètement différente de celle qui sera crée par le moteur WiredTiger. Il vous faudra donc passer par quelques manipulations pour migrer de l’un vers l’autre mais rassurez vous, rien d’insurmontable, en particulier dans le cas de Replica.

Par contre rien ne vous empêche d’utiliser les deux systèmes dans un replica set.

A - MMAPv1

Comme dit précédemment, MMAPv1 reste le moteur de stockage par défaut.

Les principales évolutions se résument à sa nouvelle gestion des locks et au système de journalisation, qui a aussi été amélioré.

B - WiredTiger

WiredTiger présente deux avantages par rapport au MMAP:

  • la manière d’allouer les données sur le disque:

écriture asynchrone déclenchée par défaut toutes les 60 secondes ou les 2Go de données

  • la compression des données et des indexes :

deux algorithmes de compression sont disponibles, snappy et zlib. La différence vient du fait que snappy (utilisé par défaut) a un taux de compression plus faible que zlib, mais est du coup plus rapide.

  • les locks au niveau document, ce qui permet plusieurs écritures simultanées dans la même collection

Vous trouverez ici un benchmark sur les différentes versions de MongoDB (v2.6.7, v3:MMAPv1 et v3:WiredTiger).

III. Ops Manager

Ops Manager est le nouvel outil d’administration de MongoDB et qui n’est ni plus ni moins qu’une version MMS en local, destinée aux entreprises.

L’administration des bases est plutôt bluffante. Pour avoir vu une démo en live, l’initialisation et le déploiement sur des VMs chez Amazon (EC2), sur lesquelles ont été déployées des shards répliqués, s’est fait en un clin d’œil.

Vous avez la main sur les versions à déployer et les migrations se font via un bouton, tout est transparent.

L’administration de bases MongoDB n’a jamais été aussi simple et facilitera la vie de vos DBA.

IV. Autres

On trouvera également des améliorations au niveau des shards, de la sécurité et des outils que sont mongodump/mongorestore/mongostat…

La commande explain() a aussi été revue et va analyser de manière plus détaillée vos requêtes.

Vous trouverez plus de détails sur l’ensemble des changements sur la release notes de MongoDB.

Conclusion

Cette version 3 arrive avec beaucoup de changements, très alléchants, en particulier au niveau des performances. On peut résumer les principales révolutions dans le nouveau moteur WiredTiger et la gestion des locks.

À vous de vous faire votre propre avis, car la mise en place et l’administration d’une base MongoDB est devenu relativement simple.