Après l’introduction NoSQL une petite pause et la rencontre avec les habitués du JUG, des discussions intéressantes, questions et réponses non formulées et un joli buffet. Après cette demi-heure, on est monté pour la deuxième partie de la conférence : le retour d’expérience de Steven Noels dans l’utilisation de NoSQL pour l’implémentation d’un CMS (Content Management System).
Lucian Precup – Photo : Claude Falguière
Lucian Precup nous a présenté le groupe “ALM France” – Application Lifecycle Management. La soirée d’ouverture aura lieu le 30 septembre prochain à 18h30.
ALM a pour objectif de promouvoir la gestion du cycle de vie des applications et les outils associés. 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 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.
Pour en savoir plus : http://blog.alm-france.org/
Après ce moment publicitaire, la conférence de Steven Noel a commencé.
CMS on top of NoSQL
Steven Noels – Photo : Claude Falguière
Steven Noels est le co-fondateur de Outerthought. Ils développent des applications scalables de management de contenu et publishing avec les technologies Java, REST et maintenant aussi NoSQL.
Steven est un speaker renommé sur les thèmes du management de contenu, NoSQL et l’Open Source en général. Outerthought offre un catalogue de produits développés en open source basés sur les solutions open source existantes :
– Daisy, content-and knowledge management : http://ww.daisycms.org
– Lily, scalable store and research : http://www.lilycms.org
– Kauri, REST centric internet application developement : http://www.kauriproject.org
Il a été invité au Paris JUG pour partager un retour d’expérience avec NoSQL : le développement du produit Lily, un dépôt de contenu sur Apache HBase.
Daisy est un petit système de management de contenus (similaire à Alfresco). L’image ci-dessous illustre l’architecture technique classique d’un CMS :
Architecture type d’un CMS
Pourquoi autant de cache ?
Principalement pour éviter d’aller en base. La lecture et l’écriture vers la base de données relationnelle est coûteuse.
Avec Daisy, Steven Noels et son équipe sont arrivés aux limites de la scalabilité :
Et derrière cette problématique de scalabilité :
Finalement Lucene ne permet pas de gérer la fonction “failover”. Ils ont trouvé des solutions pour réaliser du master/slave mais ce n’était pas très satisfaisant.
L’équipe a donc commencé à réfléchir à leur nouveau besoin :
La première solution à laquelle ils ont réfléchi passait par l’utilisation d’encore plus de base de données relationnelles. Ainsi, les caractéristiques de l’architecture cible imaginée peut se résumer à la liste suivante :
Le design était une usine à gaz. Non seulement l’architecture devenait ultra complexe, mais générait également des arbitrages financiers : les licences d’oracle, par exemple, sont vendues par CPU. La quantité d’argent à payer pour avoir N bases de données est extrêmement élevée.
Définitivement, aller vers cette solution c’était partir vers une catastrophe en terme de satisfaction d’utilisateur par rapport au budget.
Heureusement, l’explosion de NoSQL est arrivée à ce moment précis !
La persistance polyglotte, “la tour de babel”. Apparemment une nouvelle technologie émergente couvrait les besoins auxquels on a fait référence : scalabilité dynamique, performance avec des gros volumes de données et l’architecture distribuée.
L’offre étant assez riche – Cassandra, MongoDB, CouchDB, Redis, Riak, HBase… – quelle solution choisir ?
Clé/Valeur ? Document ? Colonne ? Graphe ?
Lorsqu’on est confronté à un défi tel que celui là, le plus important est de faire les bons choix pour le problème précis. Aujourd’hui on dispose de beaucoup de choix mais toutes les bases ne sont pas adaptées à tous les usages. Certaines ne scalent pas, certaines nécessitent des compétences dans des langages peu répandus (Erlang) etc. Il faut faire aussi attention au marketing (qui finance la solution ? est-elle vraiment NoSQL ?).
L’équipe a donc décrit une série de pré-requis initiaux qu’on résume ci-dessous :
Après cette première réflexion, ils ont constaté qu’en plus des pré-requis déjà cités, les points suivants étaient aussi très importants :
HBase suit un modèle de données Column, très flexible, avec lequel on peut garder toutes les versions d’un document. La solution offre la possibilité de ranger les données permettant la création d’index scalables, ainsi qu’un espace HDFS pour stocker les blobs. De plus, elle s’appuie sur l’implémentation Open Source de Google : BigTable. Entre autres caractéristiques techniques, HBase offre l’intégration avec Hadoop MapReduce et des API’s Java, REST, Thrift, Ruby Shell, Java M/R.
Enfin Steven a ajouté aussi que l’équipe se sentait à l’aise avec l’utilisation de la licence Apache et avec la communauté déjà très familière pour eux.
Grâce à HBase, ils ont trouvé le dépôt de données qu’ils recherchaient. Or, contenu est aussi synonyme de recherche ! Ils utilisaient le produit Lucene, mais le cadre avait complétement changé car la recherche devait tenir compte de la scalabilité dynamique.
Un CMS se compose de deux types de recherche :
En partant de l’idée des Index Datastore de Google App Engine l’équipe a développé la librairie HBase Indexing Library, et pour implémenter la méthode de recherche dont ils avaient besoin, ils se sont fait aider par le framework SOLR qui appartient aussi au projet Lucene.
La dernière étape était de pouvoir mettre à jour les index de données de HBase pour bien les connecter avec la recherche SOLR. Il fallait impérativement une méthode fiable de copie dans un environnement distribué. Finalement WAL/Queue a été choisi comme solution pour l’ensemble de garanties qu’il fournit dans la synchronisation de données.
Le résultat final est Lily :
Steven a conclu en disant qu’ils ont réussi quelque chose qui leur plaît beaucoup et qu’ils sont très satisfaits des résultats.
Vous pouvez télécharger le guide d’apprentissage (architecture, modelé, API, Javadoc) – www.lilycms.org. La release complète de Lily sera aussi distribuée fin octobre 2010.
Si votre architecture de données est correcte avec un seul CPU et une seule RAM, vous n’avez pas (encore) besoin de NoSQL. NoSQL sert principalement à couvrir le besoin d’une architecture distribuée et de haute disponibilité.
Mais si vous constatez que NoSQL est la solution à vos problématiques de distribution, scalabilité et performance sur des gros volumes de données, vous devrez donc faire le bon choix. Il faut surtout éviter de succomber aux sirènes du marketing, ou de faire un choix basé sur le “buzz”. Steven Noels et son équipe ont choisi HBase juste 2 mois avant le hype de Cassandra, mais si au départ Cassandra est plus simple, HBase est plus configurable.
Utiliser une base NoSQL implique de mettre les mains dans le code pour constater que la base fait vraiment ce qu’on dit qu’elle fait. Le choix est un risque ! Rappelez-vous que le choix le moins amusant peut être aussi le meilleur.
Pour en savoir plus :
Devoxx !
Vous y retrouverez des speakers comme Tom White (Cloudera/Hadoop O’Reilly author), Jonathan Ellis (Cassandra), Michael Stack (HBase), des conférences dédiés aux produits comme MongoDB, Voldemort et Elastic Search et cas d’applications pratiques sur Twitter, Facebook et Adobe
3ème mi temps
De retour au Vavin, la fin de la soirée agréable et amusante comme toujours. Des conversations intéressants et retrouver encore quelques têtes.
Quelques personnes, comme d’habitude 
ont encore continué vers la quatrième mi-temps !
Et voilà, c’est tout !
Rendez-vous au prochain Paris JUG !!!
I'm a Software Engineer based in Paris, working at Red Hat. I've joined the Infinispan Team and I contribute to Infinispan, Vert.x and Spring-Boot projects for my work and for fun! I'm a Duchess France Board member. I share knowledge about Java, Infinispan, Vert.x, Scala, Go, MongoDB or Agile Development through formal presentations (Codemotion, Agile France, MongoDB SF, Google Fest W Paris, Geneva JUG ...) or hands-on workshops (Devoxx, Duchess France). I'm passionate about the community contribution, open-source and drama.
Claude Falguière est coach devops chez Valtech. Son expertise concerne le déploiement et l’analyse des performances. Elle s’intéresse aussi aux langages fonctionnels et aux moyens ludiques d’apprendre l’informatique. Elle est co-fondatrice de Duchess France mais elle s’est mise en retrait pour se concentrer sur la fondation de Devoxx4Kids France et oeuvrer contre les stéréotypes auprès des plus jeunes. Elle est membre du Paris JUG et du comité de programme de Devoxx France en charge du track Future.
les 24 et 25 mai à Lyon
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.