Breizhcamp 2016 – Compte-rendu de la journée du mercredi

Vous n’étiez pas au Breizhcamp…

… mais vous aimeriez en savoir plus !

Comme vous auriez aimé être en Bretagne la semaine dernière et que nous sommes compatissants, nous vous avons préparé un petit résumé.

Le contenu de la conférence Breizhcamp a été dense. Nous préférons découper ce résumé en 3 articles !

Voici donc un résumé de la première journée.

BreizhCamp – Premier jour

Nous sommes mercredi. Nous attaquons avec la première journée, la plus calme, mais intéressante malgré tout.

Xtreme Refactoring Deathmatch – par Marie-Laure Thuret et Antoine Michaud

La journée a commencé sous les chapeaux de roue, car Marie-Laure (@mlthuret) et moi même (@AMichaud34) avons animé notre atelier Xtreme Refactoring Deathmatch. Dans cet atelier, nous jouons les rôles de product owners capricieux demandant la modification d’un code existant pour implémenter de nouvelles features. 2h d’efforts intenses pour nos participants. Et bien sûr, pour corser le tout, un leader board sur lequel le premier à implémenter une feature gagne plus de points que les autres.

Bref, pas forcément les mieux placés pour faire un compte-rendu objectif, mais nous avons apprécié cette session et nous la reproposerons à plusieurs occasions sur Paris.

Ce que le kickstarter Mongo ne vous dira pas – par Pierre-Alban Dewitte et Bruno Bonnin

Partant du constat que la documentation de son éditeur présente MongoDB sous son meilleur jour, mais que la réalité après quelques années d’expériences est toute autre, notre orateur veut nous partager son expérience et les déboires qu’il a pu rencontrer par manque de mise en garde sur certains points.

Première idée reçue : Mongo, c’est schemaless, on peut donc modéliser comme on veut. Sauf qu’il y a plusieurs contraintes. D’une part, si l’on compte dénormaliser à l’extrême, il faut savoir qu’il y a une limite haute de 16 MO par document. Et de toute façon, avant même d’atteindre cette limite, c’est généralement une mauvaise idée d’avoir des documents de taille si importante car ils rempliront très vite la mémoire vive, indispensable pour la performance de Mongo.

Alors quoi, il suffit de placer quelques bonnes jointures pour alléger tout ça ? Dans une certaine mesure, c’est l’idée, sauf qu’il faut tout de même faire attention : Mongo n’est pas une base ACID (https://en.wikipedia.org/wiki/ACID), c’est à dire qu’il n’existe pas de système transactionnel assurant l’écriture d’un ou plusieurs documents modifiés. Sans parler de l’aspect performance si l’on abuse de normalisation qui nous ferait revenir aux mêmes biais que dans les bases relationnelles.

Il faut donc trouver un compromis entre normalisation et dénormalisation, et là, il n’y a pas de règle et je cite : « c’est un art plus qu’une science ». Cela dépend avant tout de l’usage que l’on fait des données. Ceci est un point sur lequel nos présentateurs ont insisté pendant les 2 heures : la conception doit toujours être guidée par l’usage !

Les outils

Il n’y pas grand chose de produit par MongoDB directement. Mais on trouve pas mal d’outils externes :

Les interfaces graphiques :

• Robomongo : codé en C++ plutôt à la traine niveau fonctionnalités
• MongoChef : fonctionne très bien et très complet. Payant (autour de 150€/an)
• MongoDB Compass : permet de faire des requêtes sur les documents et du schema mining. Joli mais incomplet.

La ligne de commande :

• Mongo Hacker : colorise, fait du « pretty print », fournit des alias pour agrégations (gcount, gavg, gsum, …)
• m : Permet de gérer plusieurs versions de mongodb sur son poste

Frameworks et APIs

Du côté des clients, nous retenons les outils suivants :

• Driver Java de base : Les codecs sont lourds à implémenter et l’outil est un peu compliqué. L’API asynchrone est cependant très efficace et agréable à utiliser pour qui veut faire du non-bloquant.
• Morphia : API fluent, riche, utilisation simple. Pour notre speaker, cet outil est tout simplement « nécessaire et suffisant ».
• Spring Data : c’est du Spring
• Hibernate OGM : je ne sais plus comment notre présentateur a dit ça, mais je crois que c’était assez négatif :-)
• Jongo : Vraiment cool !

Estimer la volumétrie

Le dimensionnement est une étape importante à effectuer avant mise en place de la base de données. Il faut prototyper puis extraire des statistiques des données et des indexes, estimer le nombre de documents en production, ajouter un coefficient multiplicateur pour être tranquille et connaître la proportion des données réellement utilisées en lecture à un moment T (ce que l’on appelle aussi un « working set »).

Brancher Mongo à un système externe

Mongo connector permet d’exporter les données vers du ELS, SolR, Postgre, un autre Mongo, …

Pour les migrations, un de nos deux speakers a un coup de coeur pour Apache Camel.

La vie de la prod

Pour mettre ses données en sûreté, mieux vaut utiliser un replica set. C’est très facile à mettre un place. Attention cependant au chaînage automatique des secondaires.

Stockage des données

Dans MongoDB, la cohérence des données était traditionnellement assurée par le Write Concern qui acquitte une fois l’écriture prise en compte par le master. Il existe également un Read Concern à partir de la version 3.2 qui permet de pousser un peu plus loin le niveau de cohérence au besoin.

Le moteur de stockage était mmapv1 depuis le début et devient Wiredtiger par défaut à partir de la 3.2. Il y a également un stockage en mémoire qui est en beta mais qui, en réalité, est lent et pas du tout mature. Pour finir, un futur moteur que l’on pourrait bientôt trouver, c’est RocksDB.

Pour un même replica set, il est possible d’avoir plusieurs moteurs. Cela permettant de tirer parti du meilleur de chacun des mondes. Wiredtiger est plus performant en écriture car il n’y pas de lock au niveau de la collection mais au niveau du document alors que MMap permet une lecture plus performante.

Sharding

C’est probablement la partie la plus compliquée dans Mongo. Cela consiste à répartir les données sur différentes machines. On peut le faire de différentes manières : range based sharding, hash based sharding, tag aware sharding. Le hash based sharding est dans la plupart des cas la solution à privilégier.

Lorsque l’on fait du sharding sur Mongo, il faut savoir que pour chaque shard, on doit avoir un replica set entier. Comme le sharding commence à être réellement intéressant à partir de 3 shards, cela n’est pas négligeable en terme d’infrastructure.

On peut aussi rencontrer le cas de lecture sur un noeud orphelin, c’est à dire une donnée qui n’est plus d’actualité, lors d’un rebalancing ou lors d’une sauvegarde. On préfèrera ne jamais lire sur un noeud secondaire pour des données critiques.

Quand on décide d’utiliser la technique de sharding, il vaut donc mieux être sûr que cela en vaut la peine, en monitorant le working set notamment.

Monitoring

Petite liste d’outils intéressant pour l’analyse :
Mongotop, Explain, Mongostat, mtools

Conclusion de la première journée

Cette journée a très bien commencé et ce résumé ne fait pas assez honneur à la qualité du programme de la première journée car même si l’on parle ici uniquement de 2 sujets, il y en avait en réalité 17 que vous pourrez retrouver sur le programme du Breizhcamp. Rendez-vous ces prochains jours pour les résumés des journées de jeudi et vendredi !