What's next : SQLFire par Jags Ramnarayan

Lors de son talk SQLFabric – Scalable SQL instead of NoSQL Jags Ramnarayan, architecte en chef des produits Gemfire chez VMware, a débuté par un retentissant « The rules have changed ! ».

Nouvelles contraintes applicatives

Jags parle ici de la manipulation des données et des nouveaux besoins en terme de mémoire et de scalabilité. SQLFire est encore en version alpha et le sujet n’était pas facile car SQLFire est un produit assez nouveau, on apprend d’ailleurs que le nom SQLFire remplace l’ancien nom SQLFabric. Ses fonctionnalités sont très nombreuses et ses domaines d’application sont encore un mystère pour beaucoup d’entre nous, et, pour avoir parlé à plusieurs personnes après le talk, il s’avère que le sujet n’a pas toujours été très bien compris, et je vais essayer de vous rapporter les informations de cette keynote (et un peu plus j’espère).
Vous connaissez sans doute les SGBD et les bases NoSQL (et grille mémoire). SQLFire essaye de réunir le (meilleur) des deux mondes, en prenant en compte les contraintes techniques liées au cloud et à la scalabilité.

A mi-chemin entre SGBD et NoSQL

Les bases relationnelles qu’on ne présente plus, utilisent un modèle familier pour tout le monde, donc facile d’accès et pas uniquement pour les développeurs. Je ne compte plus le nombre de fois où j’ai vu des fonctionnels, des chefs de projet faire une requête pour récupérer les données.
De l’autre côté, les bases NoSQL et grilles mémoires font beaucoup parler d’elles en ce moment mais demande un effort non négligeable pour les développeurs et architectes. Je vous parle en connaissance de cause, car j’ai moi même mis en place la grille mémoire Gemfire dans le cadre du Challenge USI 2011.
Au passage, Gemfire et SQLFire font tous les deux partie de la gamme de produit vFabric et seront présents sur CloudFoundry.

Fonctionnalités

Pour résumer simplement, voici sous forme de liste les fonctionnalités que SQLFire reprend des deux mondes.
– Du monde SGBD :

• La notion de table
• Les requêtes SQL
• Le langage DDL
• Support des clauses update
• Les drivers JDBC
• Les outils associés

– Du monde NoSQL :

• Chargement des données en mémoire
• Réplication des données entre les noeuds (ou cluster)
• Partitionnement des données entres les noeuds
• Scalabilité et découverte automatique des noeuds
• Tolérance aux pannes (grâce à la redondance des données notamment)
• Technologie de Map/Reduce
• Temps d’accès en lecture/écriture

Alors forcément, tout ça paraît très alléchant et ça l’est en effet. Il suffit de lire la documentation pour voir le potentiel de ces nouvelles techno.

Contraintes du Cloud

Mais il ne faut pas oublier que le cloud et la scalabilité amènent de nouvelles contraintes, notamment dans le domaine de la manipulation des données !
Par exemple, le partitionnement des données entre plusieurs noeuds n’est pas fait pour agréger (comprenez faire des jointures) des données réparties à travers le réseau comme on le ferait avec un SGBD. Pour illustrer mes propos, imaginez simplement la quantité de données à faire transiter par le réseau lors de requêtes sur plusieurs centaines de millions d’enregistrements !
Pour répondre à ce problème de partitionnement, Jags Ramnarayan à présenté le système de collocation de données de SQLFire. Ce système permet de regrouper automatiquement sur le même noeud, les données « liées » issues de tables différentes. Par exemple, dans un système de réservation d’une compagnie aérienne, on peut indiquer à SQLFire (via le DDL) de regrouper les données des tables vol et réservation en utilisant une clé commune, ici le numéro du vol. Cette solution de collocation permet ainsi d’effectuer des requêtes SQL avec des jointures entre ces deux tables.
Malheureusement, nous n’avons pas eu de solution pour traiter les cas plus complexes. Lors de la conception, il faut donc faire attention à la structure des données et anticiper les données que l’on souhaite agréger pour organiser les données au mieux. Et pour les autres cas, il faudra vraisemblablement passer par des agrégations manuelles plus coûteuses, en utilisant par exemple l’équivalent des curseurs bases de données pour limiter le chargement des objets en mémoire…

Disponibilité

Jags nous indique que le produit sortira en version alpha dans environ 15 jours, mais si mes informations sont bonnes, SQLFire devrait sortir aujourd’hui. Malgré sa version alpha, Alexandre Vasseur, responsable produit de la gamme vFabric m’a confié que certaines sociétés l’avaient déjà « early » adopté !
Alors pour être complet, il faut savoir que Gemfire et SQLFire sont les deux seuls produits vFabric « commerciaux ». Ils proposent une licence d’évaluation gratuite jusqu’à 3 noeuds, ce qui permet de tester ces produits facilement et également de récupérer directement les jars depuis les repo maven.

En résumé

SQLFire répond donc à un besoin réel et la possibilité d’utiliser les outils existants grâce au driver JDBC est un vrai plus pour son adoption. C’est peut être ce qui fera la différence par rapport aux bases NoSQL, même s’il s’agit bien de deux outils, qui répondent à des problématiques légèrement différentes, malgré leurs caractéristiques similaires.
En tout cas, chez Zenika nous allons suivre la sortie de ce produit et si vous avez des besoins en terme d’OLTP, vous pouvez regarder de plus près Gemfire et SQLFire… N’hésitez pas à nous posez vos questions ou nous faire des retours sur vos essais dans ce billet.
Edit : [8 juin] La version alpha est disponible à cette adresse :

• http://communities.vmware.com/community/vmtn/appplatform/vfabric_sqlfire

Et quelques liens complémentaires :

• Blog VMware
• Documents