Petit déjeuner MongoDB organisé par Zenika Lyon

Ce petit déjeuner à été organisé par l'antenne lyonnaise de la société Zenika. Merci à eux de donner la possibilité  aux personnes de la région lyonnaise, de suivre ce genre d'évènement sans avoir à se rendre à Paris.

Daniel Roberts (société 10gen)
@dmroberts

10gen est la société derrière MongoDB fondée en 2007. Son but est de développer la solution et d'offrir du support, des formations et du consulting. 

Pourquoi utiliser MongoDB?

Les premiers SGBD sont apparus dans les années 70. Si on regarde l'évolution de l'informatique depuis 10 ans nous sommes en pleine mutation. Les ressources machines ont explosé (CPU, mémoire, disque dur...), les coûts du matériel ont baissé.

Auparavant quand on voulait augmenter les performances d'une application, nous faisions de la scalabilité verticale en achetant une machine plus puissante. Aujourd'hui nous avons intérêt à faire de la scalabilité horizontale en multipliant le nombre de serveurs (physiques ou dans le cloud) en dupliquant les données (on en profite ainsi pour améliorer la disponibilité). Les clusters peuvent répondre à ces besoins pour les SGBD mais les architectures derrière ces bases de données sont très compliquées et sont souvent très onéreuses. 

Comme les solutions informatiques sont utilisées à tous les niveaux par toujours plus de personnes, les besoins de stocker de grandes quantités de données sont plus grands. 

Les bases NoSQL (Not only SQL et non pas no SQL) sont plus flexibles et répondent aux évolutions des architectures techniques. Elles sont également plus rapides car elles suppriment certains concepts liés aux bases relationnelles (pas de transaction par exemple). Elles ne vont pas remplacer les SGBD mais offrent une alternative intéressante pour mieux gérer certains uses cases. 

MongoDB est une base NoSQL modélisant les données sous forme de documents. Pour rappel il existe plusieurs manière de modéliser les données dans le monde NoSQL (clé/valeur, colonne, document, graph).  Les bases NoSQL de type documents sont celles qui sont les plus proches des SGBD standards.  

Schema free

Au niveau de la modélisation MongoDB est schema-free c'est-à-dire qu’elle ne respecte aucune structure (nb de colonnes, types…). Il est possible de rajouter des index sur les propriétés pour optimiser les performances.

Replication

Pour assurer la sécurité de vos données MongoDB peut être installé sur plusieurs serveurs. Même si vous avez x noeuds, les écritures seront toujours envoyées à un seul serveur, le serveur maître. Le serveur maître se synchronise ensuite avec une ou plusieurs autres serveurs esclaves. Si le maître tombe un des serveurs esclaves prendre le rôle de maître. 

Lorsqu'un noeud est réparé ou est ajouté ces anciennes données sont perdues et il se resynchronise avec le noeud maître.  Les noeuds esclaves peuvent être utilisés seulement pour dupliquer les données soit également en lecture pour améliorer les performances. La réplication se fait en mode asynchrone et vous pouvez dans ce cas avoir des read consistents. Si ceci n'est pas acceptable, vous pouvez jouer sur la durabilité des opérations si vous avez des contraintes fortes mais au détriment des performances en écriture.

Sharding

Le sharding (partitionnement) permet de répartir les données sur vos différents serveurs. Ceci permet d'encaisser les des gros volumes de données sans avoir des bêtes de course comme serveur. MongoDB découpe les collections en petits morceaux et les répartis sur les différents shards. Nous ne pouvons pas savoir où les données sont stockées. Des process  mongos (les routeurs) se chargent des requêtes entrantes et se chargent de récupérer les données sur les différents shards. 

Le sharding sera mis en place quand

• l'espace disque est limité sur votre serveur
• vous souhaitez écrire vos données plus rapidement que peut le faire un seul démon mongod
• vous voulez garder plus de données en mémoire pour améliorer les performances  

Arnaud Cogoluègnes (société Zenika)

Après la théorie Arnaud nous a offert une présentation sur comment utiliser MongoDB en tant que développeur. C'est toujours bien d'avoir des retours d'expérience sur des éléments théoriques. En tant que développeur Java Arnaud, a axé sa présentation sur ce langage même si les autres possèdent également des solutions pour se connecter à MongoDB (.Net, C, php...)

Pour illustrer les différents cas d'utilisation, il a confronté à chaque fois trois solutions techniques  

• shell MongoDB avec la syntaxe Javascript
• driver Mongo qui permet de s'interfacer avec la base de données, de l'administrer et d'exécuter des requêtes
• Spring MongoDB (il existe d'autres API de haut niveau tel que Morphia ou Jongo)

Je ne vais pas reprendre en détail la présentation d'Arnaud car il y a quelques points que j'aimerai tester avant de faire un retour dans un prochain article. Les API de haut niveau sont d'une grande utilité pour simplifier la syntaxe pour s'interfacer avec MongoDB (plus lisible pour un développeur Java que la syntaxe Json)

Spring MongoDB apporte des facilités pour

• modéliser les objets liés aux collections (@Entry)
• générer par défaut les repository à partir des interfaces héritant de Mongorepository . Vous n'avez pas besoin de créer les implémentations. Les implémentations des méthodes sont générées à partir des noms  déclarés au niveau de l'interface (convention de nommage)

Un autre projet EmbeddedMongo permet de simuler les interactions avec une base MongoDB, ce qui peut être pratique dans l'écriture de tests unitaires ou d'intégration.

Arnaud nous a présenté différents uses cases pour combler les libertés prises par les bases NoSQL pour améliorer les performances lors de la manipulation des données en masse (lock optimistic, aspect transactionnel...)

Conclusion 

MongoDB a l'air vraiment simple à mettre en place sur un projet et je pense que je vais faire plusieurs essais. Les différentes API de haut niveau apportent chacune des points forts et des points faibles en fonction des use cases.