Le 15 janvier prochain, le Lyon JUG invite Rémy Girodon pour un talk intitulé « NoSQL pour les Nuls ». Quand on a demandé à Rémy de présenter son sujet, voici sa réponse, on ne s’en lasse pas :
« On ne va pas se mentir (pas après 6 ans de Lyon Jug), si tu as 3 projets Cassandra dans les pattes, 5 projets MongoDB, 4 projets Neo4J et que tu es commiter sur Redis, tu ne vas pas apprendre grand chose à ce talk.
Par contre si as toujours stocké tes data dans un bon vieux SGBDR des familles et que tu te demandes si il y aurait pas eu moyen de faire un poil plus pertinent / performant / pratique / économique / simple (rayez ou pas la ou les mentions inutiles), alors ce talk est fait pour toi.
On va te prendre par la main et te faire découvrir les grandes familles du NoSQL, les Use Cases qu’elles adressent, et en bonus chaque famille un focus sur un produit caractéristique.
Allez viens ! «
Pour vous donner tout de suite un avant-goût de la soirée, allons poser quelques questions à Rémy.
Cet interview a été préparé par la team « élargie » du Lyon JUG, Agnès CREPET, Cédric EXBRAYAT, Alexis HASSLER et Cyril LACOTE.
La team du Lyon JUG: Qui es-tu? Quelles sont tes missions chez SQLi ?
Rémy : Je suis ingénieur Java à SQLi depuis 2001.
SQLi réalise des projets principalement web et mobile pour ses clients. Dans ce cadre, j’ai participé à plusieurs projets, en tant que développeur, leader technique, et chef de projet technique.
En parallèle j’anime des formations internes et externes, en entreprise et en école d’ingénieurs, sur le langage Java, la plate-forme JavaEE et sur les frameworks type Hibernate, Spring ou JSF. Je suis d’ailleurs particulièrement fier d’avoir monté la J//Académie, partenariat entre SQLI et 2 écoles d’ingénieurs stéphanoises, l’Ecole des Mines de Saint-Etienne et Telecom Saint-Etienne : 16j de cours de Java, JSF, Spring, Hibernate, Maven… sont dispensés aux élèves de dernière année en option Info.
La team du Lyon JUG: Peux-tu nous rappeler la signification de “NoSQL” ?
Rémy : NoSQL est un terme marketing excellent. On l’entend et on le retient aussitôt, on a presque envie d’essayer directement. Lorsque j’ai débuté en 2001, Versant éditait une base de données objet, concurrente des bases relationnelles, et ils étaient limite effrayants. Pourtant c’était déjà du NoSQL. D’ailleurs aujourd’hui ils disent clairement qu’ils sont le premier produit NoSQL ! Tout cela pour dire que c’est un terme marketing excellent, mais un terme technique sans aucune pertinence ou presque.
On peut dire qu’aujourd’hui ce terme NoSQL regroupe toutes les solutions de persistence qui ne reposent pas sur le modèle relationnel pour représenter les données, et sur le standard SQL pour définir le modèle, et requêter ou mettre à jour les données.
Du coup sous ce terme générique, on trouve des solutions très différentes. Certains croient d’ailleurs que ce sont des solutions concurrentes qui pourraient faire plus ou moins la même chose, et qu’on pourrait intervertir en cours de projet. C’est une erreur grossière, Cassandra n’a rien à voir avec MongoDB, qui n’a lui même rien à voir avec Neo4j… Ces solutions répondent à des use cases très différents, on n’est pas en train de parler de PostgreSQL, MySQL et SQL Server !
La team du Lyon JUG: Comment es-tu tombé dans la marmite NoSQL ?
Rémy : Pour deux raisons principales :
La team du Lyon JUG: Dernièrement, dans quels contextes as-tu pu utiliser une solution NoSQL ? Quels gains et quelles difficultés de mise en oeuvre ?
Rémy : Là encore deux raisons principales :
Les difficultés que je rencontre sont de deux types :
La team du Lyon JUG: Tes chouchoutes ? As-tu des solutions NoSQL de prédilection ? Si oui, pourquoi celles-là ?
Rémy : MongoDB, incontestablement. Déjà c’est la plus simple à appréhender quand on vient du monde relationnel. Après j’adore son côté pratique et fonctionnel. 3 terminaux, 5 lignes de commande et on a un replica set qui fonctionne ! Une solution haute disponibilité de persistance ! En tant que développeur Java, j’adore aussi le fait que Hibernate OGM, Spring Data, Eclipse Link, ou Jongo proposent des solutions abouties pour attaquer un MongoDB depuis Java. Tout cela est très agréable car c’est simple, ça marche, et ça répond à de vrais besoins client.
Idem pour ElasticSearch, même si on doit plus parler d’une solution d’indexation que d’une solution NoSQL. Ce sont vraiment des produits très intelligents, qui répondent à de vrais besoins clients, et sans introduire de difficulté démesurée et inutile.
Neo4j ou Cassandra sont des solutions intelligentes également, mais ils répondent à des besoins plus spécifiques et j’ai moins eu l’occasion de les utiliser dans un contexte professionnel. Par contre dans leur champ d’application, ce sont des solutions vraiment pertinentes.
La team du Lyon JUG: Quels sont les champs d’application de NoSQL ? Y a-t-il des domaines dans lesquels les bases de données relationnelles restent plus pertinentes ?
Rémy : Les bases de données relationnelles restent évidemment pertinentes. Sur un projet de gestion classique, peut-être 95% des données (en terme de type) vont rester dans le SGBDR. Par contre, peut-être qu’une ou deux tables vont être (ou devraient être :)) migrées vers un produit NoSQL, car elles n’avaient rien à faire dans le SGBDR. En terme de volume, bien que cela concerne 3 tables sur 200, cela fera peut-être quand même 70% du volume de data !
Les SGBDR ont un énorme atout, le support parfait des transactions ACID. Des produits NoSQL comme MongoDB ou Cassandra seront plutôt destinés à stocker des données volumineuses, très peu connectées entre elles, que l’on va empiler. De son côté Neo4j va permettre de répondre efficacement à toute problématique de parcours de graphe. Dans ce cas là les données sont fortement interconnectées, et c’est ce qui fait leur richesse, à l’image de l’exemple traditionnel du réseau social type Viadeo. Modéliser cela en relationnel est aisé, mais les temps de requêtage seraient prohibitifs (déterminer par exemple qui sont les amis de mes amis qui ne sont pas mes amis…). Neo4j est outillé pour cela et répondra parfaitement.
Vraiment ce sont des use cases bien précis qui doivent faire choisir une solution NoSQL, pas la hype, le logo, ou le nom sympa.
La team du Lyon JUG: Qui sont les principaux acteurs de NoSQL ?
Rémy : Il y a les éditeurs de solution, type 10Gen, Neo Technologies, mais désormais tout l’écosystème IT s’y intéresse. Dans le monde Java, avec Hibernate OGM et Spring Data on voit que les deux frameworks qui ont sauvé Java dans les années 2000 proposent des outils pour le NoSQL. C’est forcément un signe.
Les acteurs du Cloud type CloudFoundry, Heroku, Cloudbees proposent des stores NoSQL on demand, du Redis, ou du MongoDB par exemple.
Les produits NoSQL ont convaincu les développeurs de leur bien-fondé, la partie est gagnée de ce côté là je pense. Par contre il y a encore beaucoup de travail pour convaincre les équipes d’eploit des clients. DBA Oracle c’est un métier reconnu, demain il faut qu’on puisse cherche des System Administrator MongoDB ou Cassandra !
Merci à Anne-Laure Rigaudon pour sa relecture.
ET Merci Rémy!
Les inscriptions pour la session de Rémy au Lyon JUG le 15 janvier sont ouvertes! Rendez-vous sur le site du Lyon JUG pour vous inscrire! A noter également que le même soir au Lyon JUG, Sylvain Roussy présentera un Lightning Talk sur Neo4J.
[…] Une belle introduction au NoSQL par Rémy et Sylvain. Pour compléter, un article sur l’écosystème NoSQL. […]
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.