Retour sur le MongoDB Day Paris

Le 14 Juin dernier avait lieu le MongoDB day, une journée consacrée à la populaire base de données NoSQL et organisée par 10gen dont nous sommes partenaires en France, Suisse, Belgique et au Luxembourg.
Pas moins de 17 sessions de 40 minutes ont animé cette journée chargée, que l’on peut séparer en deux types:

• Dans l’auditorium différents représentants de 10gen se sont succédés pour présenter toutes les possibilités offertes par MongoDB.
• Dans une seconde salle, diverses sociétés ont pu présenter des retours d’expérience sur l’utilisation de cette base.

En ce qui me concerne, je me suis rendu à cette journée dans le but de découvrir MongoDB, les cours donnés dans l’auditorium semblaient donc répondre à mes attentes. Je vous propose donc de partager mon expérience sur ces présentations.

Introduction

10Gen a dans un premier temps donné quelques détails sur la place de MongoDB et les besoins auxquels cette base répond. De cette courte présentation, j’ai retenu cette phrase qui justifie son intérêt: “Success brings rising costs… and shrinking productivity”.
Il a également été souligné que MongoDB est une base NoSQL différente en cela qu’elle ne renie pas les bases traditionnelles mais incite plutôt à une utilisation complémentaire et intelligente.

Schema Design (Chris Harris, 10gen)

J’ai trouvé cette présentation très intéressante car elle illustre très bien les différences de raisonnement que l’on peut rencontrer entre l’utilisation d’une base relationnelle et d’une base NoSQL. Une différence change radicalement notre raisonnement: avec MongoDB, il faut réfléchir en terme d’objets. Il est possible d’utiliser la notion d’héritage ou de dépendance entre nos objets. Les relations one-to-many et many-to-many sont facilement implémentables et efficaces. En réfléchissant un minimum au modèle que l’on souhaite adopter, il est également possible de faire des arbres ou des queues.
En revanche il faut tout de même faire attention à ne pas choisir un modèle susceptible d’alourdir nos documents, ou de faire de l’over-indexing. Un exemple de mauvaise utilisation de MongoDB est d’utiliser une collection différente pour chaque utilisateur.

Deployement Prepardness (Dan pasette, 10gen)

Dan Pasette a proposé avec cette session tout un scénario de déploiement en cinq étapes: Prototypage(Design), test, monitoring, capacity planning(Sharding, Replica Sets,…) , et ops playbook (Devops, backups,…). Ce scénario est itérable et représente un exemple idéal qui ne doit pas nécessairement être reproduit intégralement: “Time is limited… Do what you can!”

Replication and Replica Sets (Ross Lawley, 10gen)

Des mécanismes de réplication existent au sein de MongoDB et en font un de ses points forts. Le but est d’avoir une haute disponibilité, plusieurs copies de travail et surtout d’assurer la persistance des données. Pour cela, il est intéressant d’utiliser un cluster constitué de plusieurs serveurs. Il est possible d’écrire les données sur noeud primaire qui se chargera de les répliquer sur les noeuds secondaires.
MongoDB propose un mécanisme de fail-over et de recovery. Ainsi, si un noeud primaire devient inaccessible, un noeud secondaire est automatiquement élu pour prendre sa place. Par la suite, si un nouveau noeud est introduit, il recevra une copie de la base.

Indexing and query optimisation (Alvin Richards, 10gen)

Le système de requêtes est particulièrement puissant sur MongoDB, à condition que l’on ait bien défini nos index et notre design. Il est donc primordial de savoir optimiser l’utilisation des index: “Indexes are the biggest tunable performance factor in MongoDB”.
Une collection doit comporter au plus 64 index et chaque index a une taille maximale de 1024 octets. Moins on en a, plus les requêtes seront rapides à s’exécuter.
On peut noter que MongoDB supportera dans le futur des intersections entre les index.

How and When to shard (Daniel Roberts, 10gen)

Avec le système de réplication, le système de sharding est un autre point fort de MongoDB qui permet d’assurer une haute disponibilité. Il donne la possibilité de stocker de très grands volumes de données répartis sur différents noeuds. Cependant, celui ci est à utiliser avec précaution et uniquement si on en a besoin. Le principe est de partitionner les données pour alléger chaque serveur. Un balancer est là pour indiquer où aller chercher ce que l’on veut. Ça peut être un outil efficace, en particulier lorsque l’on est à court de ressources. (RAM, IO…)
Attention, l’utilisation du sharding peut affecter les schémas utilisés et nécessiter des ajustements.

Conclusion

Ce premier passage du MongoDB day en France était très réussi et m’a permis d’avoir une vision très globale de MongoDB. Cet évènement ciblait principalement les personnes qui souhaitaient découvrir la base, bien que 10gen proposait tout au long de la journée de répondre aux questions des personnes ayant des problématiques spécifiques.
Nous avons hâte de participer à la prochaine édition. On espère en tout cas que MongoDB continuera à s’imposer dans le monde du NoSQL, car c’est un outil jeune mais complet et très prometteur.