Il y avait une ambiance de rentrée au Paris Java User Group mardi soir. Comme chaque deuxième mardi du mois, 210 personnes étaient présentes pour suivre une présentation de 2 heures sur le sujet du moment : NoSQL. Si vous avez manqué la soirée, nous mettrons rapidement à disposition les vidéos de la soirée sur le site Parleys.com du Paris JUG. Petit retour à lire tranquillement devant un bon café.
Startup Weekend Paris
Sacha Bostoni nous a présenté le concept de Startup Weekend. Voici le pitch : le temps d’un week-end, réunissez dans un seul endroit des apporteurs d’affaires, des personnes avec des idées et des développeurs. Cela permet de monter un projet en 54 heures et d’initier de vraies aventures. Ce sera la 3eme édition. Si l’on associe traditionnellement Java à développement d’entreprise, PHP ou RubyOnRails sont plus souvent associés au développement Web. Et c’est dommage, il est possible de faire des trucs sympas en Java. Rendez-vous le 8 octobre prochain pour participer, cela se passera à Paris dans les locaux de Paris Telecom. Vous connaissez peut-être mon aventure de Startup de décembre dernier, et moi c’est un truc qui me tente. Trop court pour le mois d’octobre, je ferai le prochain.
NoSQL
Michael Figuiere de Xebia et Olivier Mallassi d’OCTO Technology nous ont fait une présentation sympa sur NoSQL. Au delà du buzz, ils ont présenté avec justesse les concepts et ils nous ont donné un bon aperçu de la partie technologie.
NoSQL c’est Not only SQL. Le titre lui-même ne dit pas mort au SQL mais plutôt y’a pas que le SQL. Si vous êtes administrateur de base de données, ne vous inquiétez pas, vous n’êtes pas encore au chômage. Il y a même de belles opportunités pour les quelques années qui viennent. NoSQL a été initié par les grands du Web qui ont mis en évidence que le modèle classique SGBDR ne pouvait pas convenir aux exigences des sites de commerces ou aux moteurs de recherches. Ce qui est intéressant, c’est que le monde de l’entreprise ne l’a pas encore intégré. J’en parlais avec Olivier à la pause, il y a un monde classique dominé par les éditeurs comme Oracle et Microsoft et un nouveau monde dominé par Google, Amazon ou LinkedIn, avec un gouffre technologique. Les années qui viennent seront aussi plus marquées en terme d’opposition et de divergence. Bref à mon avis on a pas terminé de jaser sur NoSQL.
Sur la présentation elle-même, j’avais écrit un long article en janvier dernier qui couvre un peu prêt ce qu’Olivier et Michael ont présenté. Olivier donne beaucoup de retour intéressant sur le positionnement de NoSQL aujourd’hui par rapport à notre métier. Michael a bien présenté les concepts techniques. La présentation était bien équilibrée. Je dirai même bien clusterisée.
Retenez qu’il existe 4 familles technologiques dans le monde NoSQL :
– les bases Graphes comme Neo4J (qui ne marche pas en cluster par contre)
– le type clé/valeur comme Riak ou Voldemort
– le modèle orienté colonne comme HBase ou Cassandra
– le modèle document comme MongoDB
Sur la partie technique, on note que toutes ces technologies sont encore très jeunes. Beaucoup de produit en version 0.x par exemple. Sur les protocoles d’accès aux données, pas de standard. Chaque logiciel a son modèle de programmation. Les différents exemples montrés mettent en évidence la singularité de chaque solution. Bref pas de cloudJDBC car cela n’aurait pas de sens.
Si je peux me permettre, il y a cependant une réflexion pas bête initié par Olivier par rapport à notre métier de développeur. Biberonné à l’ORM depuis quelques années, avec le succès de JPA2, j’ai l’impression que le développeur Java se fiche déjà pas mal du modèle de persistance. Je rappelle qu’il est possible de programme avec un modèle JPA plus simple sur Google App Engine. J’ai vu des équipes où les développeurs n’avaient pas de client Oracle installé sur leur machine. Bref il serait intéressant de réfléchir à un modèle non relationnel de mapping simple, une sorte de JPAforCloud, car je dis haut et fort qu’il y a une place à prendre pour un standard technique. Qui est d’accord avec moi ?
En conclusion, NoSQL est un mouvement intéressant. Nous remettons en question un modèle vieux de 40 ans. Il est cependant prématuré de penser que le DBA passera l’arme à gauche ou que les solutions classiques SGBDR sont mortes. On vient déjà de virer les équipes d’administration système de son SI avec le Cloud, et maintenant on souhaite titiller les DBAs… Mon côté geek est emballé par les technologies, tout en relativisant sur le côté innovant. Faut pas pousser mamie dans les orties, une table dénormalisée et non-relationnelle ça marche aussi depuis 40 ans. Mon côté boss se dit que si je dois choisir entre le TJM d’un développeur Java qui découvre une technologie et la licence d’une base de données classique, et bien je prendrai la base. On a beau hurler sur le prix des licences, c’est toujours moins cher (et moins risqué) qu’une solution qui doit encore faire ses preuves. Pourvu que je me trompe et que ces technologies arrivent dans l’entreprise.
Coupure publicité
Après la pause buffet, toujours sympa de vous rencontrer et de discuter avec vous, nous avons repris avec la présentation d’un nouveau user group, Application Lifecycle Managment France.
Lucian Precup que vous voyez souvent au Paris JUG nous a présenté le projet, dont la soirée inaugurale aura lieu le 30 septembre prochain à 18h30. Le pitch :
ALM viens de « Application Lifecycle Management » et cette discipline recouvre de nombreux aspects comme la conception, la gestion des exigences, l’architecture, la gouvernance des processus, la gestion de projet, les outils, l’assurance qualité, la gestion des configurations, le déploiement, l’exploitation et la prise en compte de l’expérience utilisateur.
ALM France est une communauté qui vise à promouvoir la gestion du cycle de vie des applications et les outils associés. Le
fonctionnement du groupe privilégiera le partage d’expériences concrètes sur tous ces domaines, afin de permettre à chacun de
bénéficier des meilleures pratiques du terrain.
Présentation du projet Lily, un CMS construit avec HBase et Solr
Steven Noels est le fondateur de la société Outerthought, basé à Gant en Belgique. Sa société édite Daisy CMS, concurrent de Sharepoint et de Drupal. Il nous propose de nous raconter l’histoire du projet Lily, une évolution vers le monde du NoSQL, basé sur HBase et Solr.
Steven nous montre avant tout le programme de la prochaine semaine de conférence à Devoxx mi-novembre. Il y a une session sur NoSQL par jour. C’est vraiment le sujet du moment. Il y aura les meilleurs speakers des différents projets, bref à ne pas manquer.
Le projet Lily a démarré car le modèle de Daisy atteignait des limites. Basé sur une base de données classique, avec un cache, puis un autre cache par dessus, le moteur ne tenait pas sur de forts volumes de documents. La heap size était limité. Les coûts des solutions demandaient beaucoup de solutions. Le problème du Cold cache au démarrage, les problèmes de fiabilité, bref le succès du CMS Daisy a aidé l’entreprise à construire une nouvelle version.
Steven explique qu’en substance, l’information est stockée en 3 endroits : la base MySQL, l’index Lucène et le système de fichier sur lequel se trouve le document. Or la synchronisation de ces espaces de données créée de la latence. L’application ne peut pas aller plus vite.
Il existe alors 2 solutions. La première, qui fait plaisir aux vendeurs de logiciels de base de données, est de rajouter plus de machines et plus de base de données. Youpi cela fait vendre de la licence. Que votre application soit mal écrit, on s’en claque. Par contre si vous pouvez nous prendre 2 serveurs RAC pour Noël, ça serait cool pour ma prime de fin d’années. Si vous ne comprenez pas la solution que l’on vous vend pour résoudre un problème, c’est que vous faîtes partie du problème, et que celui qui sait n’a pas forcément envie que vous compreniez. Vous me suivez ?
La solution 2 fut de regarder il y a un an ce qui se passait dans la communauté NoSQL. Attention, tout est encore très jeune. Il y a parfois un peu trop de marketing. Steven parle rapidement de Neo4J qui n’est pas capable d’absorber de forts volumes, et qui ne marche pas en cluster. Bref pas trop NoSQL pour lui.
NoSQL c’est une nouvel ère. Steven nous dit cependant que si vos données tiennent en RAM, comme 8Go par exemple, pas la peine de regarder les solutions NoSQL. Les moteurs SGBDR avec un schéma bien pensé et des indexes, ça marche aussi. Ah tiens les indexes sur les clés multiples c’est un truc qui n’existe pas dans le monde NoSQL. Steven dit même que parfois le choix le moins fun est le plus sage pour l’instant.
La recherche d’une solution les amène à étudier différents logiciels. Ce fut le projet open-source Apache HBase finalement qui remporta l’affaire. Avec des capacités à monter en charge, avec une tolérance aux pannes, un partage de la donnée automatique, le fait qu’il fonctionne sur du matériel simple et pas cher, c’est la solution retenue pour le projet Lily.
S’agissant de gestion documentaire, il était important pour son projet d’avoir une consistance sur l’écriture. Ce qu’il appelle « atomic update ». Le projet Apache HBase est une grille de stockage distribuée, versionnée, open-source et oriéntée colonne modélisé sur l’algo Map-Reduce de Google.
HBase is an open-source, distributed, versioned, column-oriented store modeled after Google’ Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, HBase provides Bigtable-like capabilities on top of Hadoop. HBase includes:
* Convenient base classes for backing Hadoop MapReduce jobs with HBase tables
* Query predicate push down via server side scan and get filters
* Optimizations for real time queries
* A high performance Thrift gateway
* A REST-ful Web service gateway that supports XML, Protobuf, and binary data encoding options
* Cascading, hive, and pig source and sink modules
* Extensible jruby-based (JIRB) shell
* Support for exporting metrics via the Hadoop metrics subsystem to files or Ganglia; or via JMXHBase 0.20 has greatly improved on its predecessors:
* No HBase single point of failure
* Rolling restart for configuration changes and minor upgrades
* Random access performance on par with open source relational databases such as MySQL
Steven nous a montré l’architecture de son produit, au risque de ressembler aux slide d’Oracle dont nous nous moquions au début de sa présentation. Cependant rien à voir. Le gain en terme de performance, de capacité à monter en charge et le vrai support d’un modèle distribué sont énormes.
Il détaille la stratégie d’indexation, qui ne fut pas simple à mettre en oeuvre. Apace Lucene fut abandonné car il est adapté pour indexer et retrouver très rapidement les données en local. Sur HBase, l’équipe s’est tournée vers Apache SolR, ce qui est curieux car SolR est basé sur Lucene… J’avoue que je n’ai pas tout suivi.
En conclusion, Steven nous encourage à regarder ces technologies tout en nous mettant en garde sur la relative jeunesse pour l’instant de ces projets. Ce fut très bien présenté et très intéressant. Rendez-vous à Devoxx pour la suite.
Conclusion et un scoop
Pour terminer, une belle soirée en plus. Organisation tip-top avec préparation de la salle à 8 en 20 minutes. J’ai filmé le tout et je vous réserve une petite vidéo surprise…
Et le scoop donc : à priori changement de thème pour octobre prochain.
Ce sera Play! Framework pour la première partie et une surprise pour la deuxième partie. Le tout est encore à confirmer.
Hello
Merci pour ce retour… je n’ai pas pu assister à la soirée.. un projet perso à terminer pour le CNAM..
Merci pour ce résumé complet !
Peut être que via les solutions de cache comme membase/memcached arriveront à s’introduire plus facilement en entreprise.
dommage pour le paris startup weekend, on aurait pu faire une super team 🙂
je te retrouverai à la prochaine édition ++
Olivier.
Perso, le « phénomène » NoSQL me fait sourire…et m’interesse !
En tant que « Lotus » guy, je manipule le format NSF des applis Domino depuis des années maintenant …et que n’ai-je entendu sur le « c’est pas relationel, ca pue », « c’est nul y’a pas de transactions »…Alors que pendant ce temps, en le méllant intelligement a des données plus structurées, je faisait des applis plutot sympas, avec des clients satisfaits d’avoir eu un minimum d’ouverture d’esprit de ne pas jurer que par le relationel.
Enfin, le « NoSQL » commence a sortir du bois et attire les « Geeks ». Comme quoi, y’a que les imbéciles qui ne changent pas d’avis…ou alors qu’il y en a bcp qui suivent la mode 😉
PS : pour info, CouchDB, créé par Damien Katz, est énormément inspiré du format NSF de Lotus puisqu’il y a bossé de nombreuses années. On y retrouve les memes concepts, le meme type d’API etc. A ceci pret que, pour le moment, NSF est infiniement plus robuste car testé et éprouvé par des millions d’applis critiques.
PS : merci de ne pas me sortir le couplet « Notes c’est nullll »…je ne parle pas de la messagerie ici mais du serveur d’appli et du repository qui se cache derrière !
« Steven nous dit cependant que si vos données tiennent en RAM, comme 8Go par exemple, pas la peine de regarder les solutions NoSQL. Les moteurs SGBDR avec un schéma bien pensé et des indexes, ça marche aussi »
Si vraiment ça tient en mémoire, ça parait presque étrange d’avoir à utiliser la machinerie d’un SGBDR. Peut-être un solution de type Prevayler est plus adaptée. Pourquoi devoir tout retranscrire en SQL alors qu’on a les POJO sous la main?
@HinkyMimnky merci michael pour ton retour. Pour la forme sur Wikipedia dans la définition de NoSQL, je crois que celle-ci cite les travaux d’IBM dans les années 90 sur le non-relationnel. Je pense que l’on parle plus de NoSQL aujourd’hui car le mouvement ne vient pas d’éditeurs (comme Oracle, IBM ou Microsoft) mais de vendeurs de patates (Google, Amazon ou LinkedIn). Comme je dis dans mon retour, ce qui est intéressant c’est les technologies derrières et le fait que le débat avance. Ce que disait aussi Olivier.
Il semble donc que NoSQL prône certaines idées des années 70 utilisées pour programmer en COBOL: modèle de données hiérachique, CODASYL. Intéressant.