Le premier IppEvent Bordelais, ayant MongoDB pour thématique, s’est tenu le 23 septembre dernier (Ippevent MongoDB à Bordeaux le 23 septembre avec Tugdual Grall). Merci à la cinquantaine de participants qui est venue y assister, à l’EPSI Bordeaux pour l’accueil, et merci à Tugdual Grall pour cette présentation.
Voici en quelques mots un retour de cette soirée.
Bases relationnelles vs bases NoSQL
L’une des raisons d’être du NoSQL est l’idée que, dans certains cas, l’ordre et la discipline censés être imposés par les bases de données relationnelles s’estompent au fil du temps :
- de nouvelles colonnes sont ajoutées en fonction des besoins, mais les anciennes entrées ne sont pas forcément mises à jour
- les colonnes inutiles ne sont pas tout le temps supprimées
- le MCD grossit jusqu’à ne plus vraiment être lisible (beaucoup de tables, et beaucoup de relations entre ces tables)
- les contraintes d’intégrité sont souvent désactivées pour des raisons pratiques (ou ne sont jamais ré-activées par oubli)
- plein de valeurs sont vides à cause de l’héritage des données
- des colonnes sont prévues dès le départ (temp_1, … temp_10) au cas où on en aurait besoin dans le futur (voir SAP par exemple)
- etc.
Petit à petit, la base relationnelle devient un amoncellement de données, qui ne sont plus aussi organisées, plus aussi fiables, plus aussi rapides qu’escompté initialement. Bien entendu, ce n’est pas vrai pour toutes les bases relationnelles utilisées, mais c’est clairement une tendance qui se dégage au fil du temps (et je suis sûr que vous pouvez trouver des exemples dans vos projets).
Si vous êtes dans ce cas (ou que vous ne voulez pas l’être), alors vous pouvez jeter un oeil aux bases NoSQL. Leurs avantages sont les suivants :
- pas de schéma : on peut avoir 2 objets d’un même type avec des champs différents
- pas de contraintes d’intégrité : tout doit être géré au niveau du code métier
- pas de problème pour dupliquer les données : plutôt que d’avoir des relations et des jointures, il vaut mieux dupliquer certaines données pour les avoir aux endroits qui sont importants et améliorer les recherches
Intérêt de MongoDB
Rappelons-le, l’IppEvent portait sur MongoDB (et non le NoSQL en général). MongoDB est le leader actuel des bases NoSQL (il existe plus de 150 solutions concurrentes), grâce à certaines particularités :
- client très évolué avec des requêtes simples
- données stockées au format JSON (facile à lire et à modifier)
- excellente scalabilité (si vous ajoutez des noeuds au cluster, MongoDB s’occupe de tout, avec la stratégie que vous avez définie)
- mise en place facile de fail-over (Master / Slaves)
- etc.
Les pièges à éviter en NoSQL
Dans ce domaine, ce qui s’applique à MongoDB s’applique en général aux autres solutions. Si vous faites du NoSQL, attention aux points suivants :
- oubliez tout ce que vous savez sur les bases relationnelles
- créez vos objets (documents) en fonction de l’affichage de vos écrans : ce n’est pas grave de dupliquer des données, tant que c’est justifié
- oubliez les relations (clés étrangères) : voir point ci-dessus
- des objets du même type peuvent avoir des champs similaires, mais aussi des champs qui leurs sont propres
Mongo, CAP ou pas CAP
Cet acronyme désigne 3 caractèristiques primordiales des bases de données :
- C pour “Consistency” : C’est l’habilité du système à garantir que les données écrites seront bien celles lues plus tard. En d’autres mots, à un instant T, toutes les applications qui interrogent la base auront les mêmes données
- A pour “availability” : C’est l’habilité du système à répondre à toutes les requêtes (de lecture comme d’écriture)
- P pour “Partitioning” : C’est l’habilité du système à gérer les défaillances (problème hardware, problème de réseau, etc)
Il n’est pas possible de concilier les 3 caractéristiques en même temps. MongoDB a fait le choix de C et P :
- Toutes les données sont lues et écrites sur le même noeud (master), afin de garantir la consistence. De plus, il est possible de définir un niveau de write concern permettant de spécifier le degré d’assurance que les données sont bien écrites (voir plus bas).
- Il est possible de définir des noeuds esclaves (slaves) pour chaque master, afin que les données y soient répliquées automatiquement. En cas de panne d’un master, c’est un slave qui devient le master
La notion de write concern, très liée à la consistance des données, permet de définir plusieurs niveaux de garanties :
- niveau 0 : on envoie une requête à la base sans attendre son retour. C’est le mode d’écriture le plus rapide, mais aussi le moins sécurisé. On ne sait pas si la donnée a bien été écrite. C’était le mode de fonctionnement de Mongo dans les anciennes versions
- niveau 1 : on envoie la requête, et l’on attend le retour du master indiquant que la donnée a bien été écrite. C’est le mode par défaut de Mongo.
- niveau >= 2 : on envoie la requête, et l’on attend d’avoir la confirmation que la donnée a été écrite sur le master, mais aussi répliquée sur le nombre de noeuds indiqués (si n=4, alors il faut que la donnée ait été écrite sur le master, ainsi que sur 3 autres slaves).
- “majority” : idem que précédent, mais jusqu’à ce que la donnée ait été écrite sur la majorité absolue des noeuds du cluster
Conclusion
Comme pour faire un clin d’oeil à une propriété du NoSQL (pas de contraintes), Tugdual a animé cet IppEvent sans suivre un plan précis, mais en utilisant un jeu de questions/réponses. Non seulement ce format a été très apprécié, mais il a permis à chacun d’avoir des réponses à ses interrogations (les débutants, comme les confirmés), tout en conservant une ambiance “casual”.
Au delà de la qualité des informations techniques apportées, cet IppEvent a été un très bon moyen de juger l’intérêt des bordelais pour ce genre d’événements. Nous pouvons dire que ce premier événement a été une réussite, et soyez sûrs que nous vous en proposerons d’autres très bientôt.
