no:sql(eu) et NoSQL : qu'en est il?

Vu les speakers annoncés, no:sql(eu) à Londres était très prometteur mais c'était sans compter sur mère nature et ce fameux volcan islandais qui allait bloquer l'espace aérien d'Europe du nord...Malgré tout, no:sql(eu) est resté disponible et a offert un mode de fonctionnement « graceful degradation ». Un mode finalement efficace puisque quelques speakers ont réalisé leur présentation via Skype, principalement depuis les USA (quelques fois très tôt à cause du décalage horaire). Cela a également été l’occasion de discuter avec le CTO d’Amazon : Werner Vogels.

Quoiqu'il en soit, voilà ce que j'ai envie de retenir.

- NoSQL concerne la modélisation de la donnée. Toutes les données ne sont pas simplement modélisées dans un RDBMS traditionnel. La présentation de The Guardian introduit ce principe à merveille : Oracle est encore utilisé sur la partie centrale et "fait le job". Redis est utilisé pour calculer des statistiques. Des Google Spreadsheets sont utilisées pour plus simplement utiliser un Google Maps. Autant de manière de simplifier le stockage de la donnée et son utilisation.

- NoSQL concerne l'utilisation de la donnée et nous rappelle qu'un point important - et je pense souvent oublié dans nos SIs traditionnels - est de comprendre comment la donnée est utilisée. Un système peut vivre avec de la donnée inconsistante. En fait, c'est déjà le cas si vous utilisez les mécanismes de réplication Master/Slave, du cache ou simplement l'utilisation de messages asynchrones. Juste se demander comment sera utiliser la donnée.

Que se passera-t-il du point de vue du métier si mon opération (disons un retrait) est consistant mais que mon solde reste inconsistant pendant quelques secondes ou même quelques minutes?

Ma donnée sera-t-elle accéder de manière concurrente? Y aura-t-il une forte probabilité de conflit sur cette donnée? En cas de conflit, de quelle stratégie de "read-repair" aurai-je besoin (un modèle type Vector Clock ou plus simplement l'approche timestamp de Cassandra)?

Combien de temps y a t-il entre le moment ou j'écris ma donnée et le moment où elle est lue? Du coup, quelle est la probabilité de "Stale State"? S'il y a un une heure entre les deux opérations, la probabilité est faible...

Ma donnée est-elle plutôt utilisée en écriture ou en lecture? Certains de ces systèmes ont été optimisés pour l'écriture. Par exemple, Cassandra réalise plus d'accès disque pour une lecture que pour une écriture.

- NoSQL concerne la souplesse et l'élasticité. L'élasticité car l'on souhaite pouvoir rajouter ou enlever des machines à la demande. Souplesse car ces systèmes permettent d'avoir des structures de données qui évoluent. Dans neo4j, les relations entre les nœuds peuvent évoluer, les attributs des nœuds ou des relations peuvent changer En somme, votre graphe évolue en fonction de son utilisation...Dans des espaces de stockage type Key/Value comme Voldemort ou Column-oriented comme Cassandra, le modèle peut évoluer (ajout d'un attribut...) et l'espace de stockage l'acceptera. La prochaine version (0.7) de Cassandra devrait permettre le redéploiement automatique et successif des nœuds du Cluster en cas d'ajout d'une « colonne ».

- NoSQL parle de diversité. L'écosystème est très riche et composé de systèmes variés. Quelques uns de ces outils sont centrés sur la simplicité, la facilité d'utilisation et d'adoption. MongoDB par exemple fournit une façon simple de représenter la donnée (dans un style JSON) et propose des mécanismes de requêtes. D'autres solutions sont centrées sur la performance et la scalabilité. Riak, Cassandra and Voldemort (qui n'était pas représenté et je le regrette car cette solution est également utilisée sur des sites de e-commerce) en sont les meilleurs exemples. Enfin, certaines solutions proposent des alternatives de modélisation voire des modélisations impossibles dans les modèles relationnels. Les bases de données orientées Graph et Neo4j sont un parfait exemple de modélisation impossible à réaliser dans une base relationnelle. Neo4j peut parcourir un graphe d'1 million de nœuds en moins de 2ms...

- NoSQL parle aussi de collaboration. Cette conférence était l'opportunité de voir différentes approches et comment ces approches peuvent se mixer. Vous pouvez parfaitement avoir un système ou des metadatas sont stockées et requêtées dans Neo4j (imaginez la valeur ajoutée à pouvoir faire évoluer les relations entre les metadatas...) et où les objets eux mêmes sont stockées dans Cassandra (et accédés via la clé...) ou même un base relationnelle.

- NoSQL concerne également les Data Warehouse. Kevin Weil de Twitter a bien entendu parlé de Cassandra mais a également expliqué comment ils utilisent les 300Go par heure de données que génère le site. Scribe est utilisé pour collecter la donnée. Hadoop est utilisé pour analyser la donnée via Map/Reduce (le nombre de tweets - 12 milliards - est compté en 5 minutes). Pig (une sorte de DSL permettant de requêter la donnée) est utilisé pour exploiter la donnée. Un truc intéressant est que cette base de données n'est pas seulement utile à des fins marketing mais permet de comprendre les problèmes techniques (notamment ceux qui ont des effets en cascade).

- NoSQL a finalement plus à voir avec la disponibilité que la performance et la scalabilité que Amazon ou Twitter ont atteint. Jon Moore nous a parlé de disponibilité et d'accès concurrents à la donnée dans des environnements ou plusieurs Data Center coexistent. Sa présentation zoome sur le théorème de CAP et nous rappelle ce que Partition-Tolerant signifie dans des environnements multi-data center et comment choisir CP ou AP dans ces cas. Ces systèmes sont pensés pour être disponible et tolérant à la panne.

- NoSQL concerne aussi le requêtage. Bien évidement, les Key/Value ou les modèles orientés colonnes proposent peu de possibilités de requêtage mais des bases Graph comme neo4j fournissent des moyens évolués de requêter la donnée (sur les attributs d'un node, sur une relation...). Les bases orientées Document comme MongoDB ou CouchDB fournissent également des mécanismes pour sélectionner, filtrer la donnée en fonction de ses attributs.

Alors bien entendu il existe des inconvénients et des limitations. - la gestion des clés dévient essentielle : c'est le point d'entrée pour récupérer votre donnée. Alors il faut soit utiliser des algorithmes générant des clés aléatoires (sans pour autant en faire un SPOF...), soit utiliser des clés fonctionnellement plus riches et uniques. La clé fonctionnelle revient... - L'humain et l'expertise...Ces systèmes imposent de nouveaux paradigmes. Nous aurons l'occasion d'en reparler mais en tant que développeurs, nous devons apprendre à développer avec ces paradigmes (Eventually Consistent, partitionning...). En tant que production, nous devons apprendre à superviser et opérer ces systèmes. Les bases de données relationnelles sont parfaitement connues et matures principalement à cause de leur âge : 40 années d'amélioration en font des systèmes stables et fiables c'est certain! - La supervision est certainement la part faible de ces systèmes qui ne fournissent pas vraiment d'outillage "out of the box". Nous devons cependant noter que Riak (qui est sponsorisé par Basho) commence à développer des outils basés sur SNMP (le futur nous dira si ces outils feront partis de la version Open Source). Cassandra propose des statistiques en utilisant JMX et la jConsole. De plus, JMX est largement supporté et permet d'agréger vos différents nœuds Cassandra dans des outils type Graphite

En fait et pour conclure, NoSQL parle d'alternatives : "using the best tools for the best job". Je vous entends déjà crier "Rien de nouveau!" et vous avez raison sauf que nous n'avons jamais challengé le monde des bases de données occupé par 40 ans de suprématie des bases relationnelles...Enfin NoSQL concerne aussi le Cloud (avec SimpleDB, S3...) mais c'est une autre histoire.