Il y a un nouveau mouvement dont je voulais vous parler depuis quelques temps qui commence à faire du bruit : NoSQL (Not only SQL). Lancé au mois de juin 2009 à l’initiative de quelques architectes de grands sites communautaire comme FaceBook ou LinkedIn, ce mouvement prend de l’ampleur. La première soirée du groupe NoSQL France a eu lieu en janvier à Paris à l’initiative d’Octo Technology. L’objectif de ce mouvement est de parler des solutions de bases de données non relationnelles majoritairement utilisées par les grands sites communautaires. Les sites à fort trafic utilisent tous des solutions non relationnelles pour leurs bases de données. En fait au rythme où vont les choses, le modèle relationnel est remis en question dans toutes les architectures où les principes ACID ne peuvent pas être respectés. Je vous avais déjà parlé du Théorème de CAP qui montre qu’une donnée ne peut pas être à la fois consistante, accessible à tout moment par tous, et partitionnée de manière sûre :
[…] le Théorème de CAP d’Eric Brewer, utile lorsque l’on parle de données massivement partagées :
– Strong Consistency: all clients see the same view, even in presence of updates
– High Availability: all clients can find some replica of the data, even in the presence of failures
– Partition-tolerance: the system properties hold even when the system is partitionedCe qui donne en français :
– L’ensemble des clients voient la même vue, même lorsqu’il y a des mises-à-jour
– Massivement disponible : tous les clients peuvent trouver de la donnée répliquée, même lorsqu’un crash survient
– Partitionable : votre app-serveur et votre base de données peuvent être installé sur 2 machines, votre système est tolérant au partitionnement.Il s’avère que seul 2 des 3 postulats peuvent être respectés en même temps
C’est donc à l’initiative des architectes des solutions de Cloud Computing et des sites communautaires, que ce mouvement NoSQL a débuté. Lors des premières réunions aux USA, il y a eu ainsi des présentations des projets suivants:
– Le Projet Voldemort par Jay Kreps, Linkedin (slides pdf ppt, video1, video2)
– Le projet Apache Cassandra – Avinash Lakshman, Facebook (slides pdf ppt, video)
– Le projet Dynomite par Cliff Moon, Powerset (slides, video)
– Le projet Hadoop HBase – Ryan Rawson, Stumbleupon (slides, video)
– Hypertable – Doug Judd, Zvents (slides pdf ppt, video1, video2)
– Le projet Apache CouchDB par Chris Anderson, couch.io (slides, video1, video2)
Le projet Voldemort par exemple, utilisé par les équipes d’Algo Deal en France, est une énorme Map distribuée, capable de redistribuer la donnée entre plusieurs serveurs, en divisant celle-ci et en proposant une architecture transparente d’accès à un espace clé-valeur. LinkedIn s’en sert aussi en partie sur leurs serveurs. Avec 4 opérations de bases, c’est une API très simple (GET,PUT,GET_ALL et DELETE) qui rappelle le concept de JavaSpace il y a 10 ans. Jay Kreps dans sa présentation parle d’un environnement avec 12 serveurs, 300 millions d’opérations par jour, 4 milliards d’objets stockés dans 10 datastores pour son équipe seulement…
Apache Cassandra est une base de données distribuées, caractérisée par une structure de données par colonnes et super-colonnes, là où Voldermort est une simple hashmap. En termes de performances, un exemple sur une base MySQL de 50Gb montre des temps de lecture moyen de 350 ms, et de 1.5 ms pour Cassandra. Pour réaliser cette prouesse, Cassandra est une base de données distribuées, qui fonctionne donc avec plusieurs serveurs physiques. Vous vous en êtes certainement déjà servi si vous avez un compte sur Facebook (ce qui n’est pas mon cas) car cette technologie a été créé par les équipes de Facebook. L’accès à un nœud Cassandra s’effectue via l’API Apache Thrift. Un guide complet pour Mac OS X est dispo ici. C’est encore délicat à mettre en oeuvre par rapport à d’autres projets, mais les concepts sont intéressants.
Je passe sur Dynomite, un projet en Python encore trop en Alpha, pour parler de HBase, la base de données du projet Hadoop. C’est un projet qui vise à proposer une solution lorsque vous devez stocker une quantité énorme de données, et qu’une répartition physique de celles-ci devient obligatoire. Pensez à Google, c’est un candidat pour HBase. Thrift là encore peut être utilisé pour l’accès aux données. HBase est un projet construit sur Java, et la programmation est clairement plus facile que d’autres projets. On retrouve les concepts de Quorums, de finalement cohérent (Eventually Consistent, lisez cet article !) bref ce qui caractérise un système de données massivement distribué.
Hypertable est un projet porté par les équipes de ZVents qui est sponsorisé par Baidu, l’un des plus gros moteurs de recherche en Chine. Peut-être plus proche de l’approche classique par Table, Hypertable n’est pas très bien documenté et il est difficile de connaître ses points forts par rapport aux autres. Il dispose lui aussi d’une interface pour Apache Thrift.
Enfin Apache CouchDB est assez connu maintenant dans la communauté Java. C’est une base orientée document, capable d’utiliser l’algo Map-Reduce pour effectuer de la recherche sur les données. Ecrit avec le langage Erlang, l’accès s’effectue avec une API Javascript/JSON orientée REST ce qui ouvre l’accès de la base à un très grand nombre de clients. CouchDB n’est pas une base relationnel, il n’y a pas de schémas. L’indexation des documents avec un B-Tree construit sur le nom du document et un numéro de séquence permet de gérer les versions des documents tout en assurant des performances intéressantes. Pour un moteur de gestion de documents (GED) ou pour un moteur de gestion de pages webs (WCM) je pense que CouchDB doit être intéressant à regarder. Je pense aussi à un JCR (Java Content Repository) où le serveur serait CouchDB par exemple… (ça c’est pour Julien V. qui râle sur Tuan sur Twitter) (voir aussi ce comparatif entre JCR et CouchDB)
Et un standard ?
Il nous manque quelque chose pour l’instant pour que ces solutions soient exploitables dans le cadre d’une solution d’entreprise : un standard. Merci au langage SQL et aux drivers JDBC. Grâce à eux nous pouvons coder avec une base HSQL en développement, puis une base MySQL en production. Il manque encore un peu de recul, de bonnes pratiques, et de personnes capables de factoriser ces concepts pour créer un nouveau standard. Il y a une niche en ce moment pour qu’un éditeur passe devant les autres et propose une solution. Mais le marché aujourd’hui est piloté par les grands sites comme MySpace, Facebook ou Google, les seuls avec ces problématiques, les seuls avec les finances suffisantes pour explorer et développer ce type de solution.
Et toi ? Tu comptes t’en servir ?
Dans notre projet j’y ai pensé. Neo4J est une base qui travaille sur la théorie des Graphes pour modéliser les tables sous la forme de Nodes, avec des liens entrants, des liens sortants, et qui permet s’abstraire des contraintes des tables relationnelles, donc de monter en charge plus facilement. Grails a un plugin Neo4J qui offre un mapping limité, afin d’utiliser directement les objets d’un domaine Grails avec Neo4J. Il y a aussi un plugin Google App Engine, qui permet de travailler avec la base de données type BigTable de GAE et une application Grails.
Les 4 types de bases NoSQL
Nous venons de voir qu’il existe 4 catégories de solution dans le monde du « Not Only SQL ».
– les solutions clés-valeurs comme Voldemort, Dynomite ou le projet Tokyo
– les solutions basées sur le concept de BigTable de Google comme HBase ou Hypertable
– les solutions orientées document avec la recherche et l’indexation en tête, inspiré par Lotus Notes, comme CouchDB
– les solutions basées sur la théorie des graphes (Euler) comme Neo4J, AllegroGraph ou VertexDB
Les solutions les plus simples comme Voldemort permettent de gérer facilement un grand nombre de données. A l’opposé, les solutions comme Neo4J permettent de gérer des graphes d’objet où les relations entre les données sont très importantes par rapport à un modèle plat. Ceci a un coût en complexité et en performance. Un modèle graphique ressemble à un modèle clé-valeur où il serait possible de définir des relations entre les objets. Le sens des relations est important, l’exemple que j’ai vu était ce dessin de super-vilains de Marvel. Une structure en graphe enfin peut être traversée par un Visitor, ce qui permet de réaliser un véritable crawler et d’extraire des données de votre base… Neo4J est une solution de persistance pour des applications développées aussi avec des choses plus exotiques comme Qi4J dont nous avons parlé il y a quelques temps.
Enfin Google a sorti un papier intéressant en juin 2009 sur la théorie des Graphes autour de leur projet « Google Pregel », si vous cherchez un article pour bien dormir ce soir, je vous le conseille chaudement.
Je vous tiendrai informé de la prochaine réunion du groupe NoSQL sur Paris, car c’est aussi un sujet sur lequel je travaille.
Références
– Le Débriefing officiel de la première rencontre NoSQL en juin 2009
– Le Google Group NoSQL si vous voulez « en être » et briller aux diners du JUG
– Article de Denis Dollfus sur NoSQL
– Neo4J et Graph SQL une présentation intéressante. Le volume des données s’accroît rapidement, et les solutions relationnelles vont/doivent mourir. Sympa pour Oracle.
– Google Pregel avec des pointeurs intéressants.
– Devoxx 2009, présentation HBase article très intéressante de Michael Figuiere de Xebia
– Amazon SimpleDB, le Harry Potter de Voldemort ? et Des Alternatives aux Bases de données relationnelles, très bonne introduction au monde du NoSQL par Olivier Mallassi d’OCTO Technology.
Bonjour,
Super article, juste une petite correction eventually se traduit en ‘finalement’ donc eventually consistent se traduit par ‘finalement cohérent’…
En effet, super article montrant un peu les R&D sur les BDD, et autre chose que les SGBDR.
Dommage que le Web n’en parle pas plus.
Le projet Redis mérite également d’être connu : http://code.google.com/p/redis/ (GitHub)
@pgras corrigé, merci !
Bonjour,
Super article 🙂
Pour info il semble que pour Grails il existe aussi un plugin couchDB mais je ne sais pas ce que ca vaut
gorm-couchdb
Bonne journée
@Armetiz
Au contraire, il y a énormément d’articles sur le sujet (les sujets ?), c’est même difficile de s’y retrouver ! Il suffit de faire une recherche sur le terme « nosql » et c’est parti…
Je ne peux pas m’en empêcher, ça me rappelle quand j’étais jeune et con, quand on se moquait de nos camarades Cobolistes avec leur base de données hiérarchique (IMS, DL/1, ça vous dit quelque chose?). Comme les applis avaient des (dizaines d’?)années, le modèle était devenu … un vrai monstre.
Ceci dit ça n’a rien à voir avec le type de base (en relationnel ça aurait été pareil). C’est juste pour l’anecdote… Heureusement qu’on a pris cette habitude de faire du neuf avec du vieux et qu’aucune de nos applis ne durera aussi longtemps 😉
@Thomas, c’est parti pour le quart d’heure google :p !!
Les graphes sont partout!
Dans un modèle UML
Dans un fichier XML
Dans une grappe d’objets
Dans une BDD
…
Partout que j’vous dis! 🙂
Article très intéressant, je vais garder un oeil sur tout ceci, quelque chose me dit que le choix d’une de ces technos à court terme sur un projet sera nécessaire… 🙂
Sympathique article, d’autant que je suis (encore) resté à la porte de chez Octo. Monsieur Octo, madame Octa, si jamais tu réorganises des soirées entre geek,tu peux laisser la porte ouverte stp? Ou mettre une petite feuille en bas pour expliquer comment on monte?
Bref!
Qu’est ce qui ferait choisir une solution nosql plutôt qur full-sql?
Dans quels cas?
Il y a le cas traité dans l’article (intéressant) sur Pregel.
Il y a les cas avec des documents plutôt que des données structurées. Et encore?
Mais sinon, quel est le use case?
Car sinon, au lieu de la bataille entre bases hiérarchiques et relationnelles, on peut aussi penser aux bases de données objet, qui marchent tellement mieux (à ce qu’on dit) et qui n’ont pas du tout dégagé les sgbd habituelles du tableau
Je tenais à souligner un problème sur les solutions actuelles qui poussent vraiment à échapper aux bases de données normalisées, il s\’agit des performances de la base même. Aujourd\’hui sur une application bien faite on cache les appels les plus couteux en temps, et ce sont souvent des appels ou il y a des délais d\’attente sur un système extérieur.
Dans le cas des bases de données traditionnelles, les performances de calcul de l\’application base de données ont des chances d\’être de plus en plus optimales. Ceci s\’explique par le fait que les processeurs voient leurs limites physiques approchées, du coup on s\’oriente davantage vers le multi-threading, en hardware avec le nombre de cœur qui grandit et dans la manière de concevoir un logiciel. Cela étant bien sur soumis à la loi d\’Amdahl. Bref les limites sur les bases de données ne seront plus sur les performances en calcul mais sur les performances de la machine sur lesquelles elles tournent, et en particulier les performances des disques durs. Même avec les SSD qui arrivent doucement, je doute que les performances s\’améliorent radicalement, on est définitivement pas sur les mêmes technologies de mémoire. Mais le progrès peut changer les choses.
En attendant des solutions à ces problèmes émergent. Un des points que tu n\’aborde pas dans ce mouvement NoSQL c\’est le sharding ou les données sont découpées en zones assignées à des machines. Bien souvent voire tout le temps le sharding repose sur des systèmes clé-valeur. Il est alors possible de cacher facilement les données afin de stresser encore moins une base de données.
Par exemple Memcached en frontal et MySQL pour la persistance. J\’ai aussi entendu parler du projet TokyoCabinet, qui est un cache persistant et extrêmement performant, je pense qu\’il s\’agit du projet Tokyo dont tu parles plus haut. Comme il n\’y a pas de standard bien défini les architectures peuvent variée, je pense qu\’il faut être prudent dans les démarches; ce que nous faisons aujourd\’hui peut très bien être identifié par le mouvement NoSQL ou autre comme un anti-pattern dans 5ans.