Couchbase 4.0 : Quand le NoSQL se met au SQL

Couchbase a lancé cette semaine la version 4.0 de sa base NoSQL pensée pour les développements agiles et les applications à large échelle. Au menu, l’introduction d’un scaling « multi-dimensionnel », de filtres de réplication et surtout l’arrivée de SQL comme langage de requête.

Couchbase est avec MongoDB, HBase et Cassandra, l’une des bases de données NoSQL les plus populaires et les plus employées, aussi bien dans l’univers des services Web que dans celui plus conservateur des entreprises. Elle est aussi assez prisée auprès des développeurs mobiles puisqu’elle bénéficie d’une déclinaison mobile native.

Couchbase a récemment attiré sur lui les projecteurs de l’actualité en se livrant à une guerre de benchmarks avec MongoDB, chacun se prétendant le plus rapide. En réalité les benchs de Couchbase mesuraient la performance sur une infrastructure très répartie alors que ceux de MongoDB se focalisaient sur la performance mono-serveur. Autant comparer des pommes et des oranges.

Couchbase revient aujourd’hui sous les feux de l’actualité avec une annonce beaucoup moins polémique et très attendue : l’annonce de la disponibilité de Couchbase 4.0 Server.

Comme la plupart des bases NoSQL, Couchbase est sur un rythme d’évolution rapide. Cette version 4.0 apporte des avancées majeures qui ne laisseront pas de marbre les grandes entreprises qui ont déjà adopté la base pour gérer leur Big Data très réparties. C’est le cas de Amadeus, Criteo, Marriott, LinkedIn, eBay, General Electric, DirecTV, Paypal ou Visa.

Du tuning Scale Up dans du Scale Out

A la base, Couchbase est issue du rapprochement des développeurs de deux projets Open Source : Memcache et Apache CouchDB. Base NoSQL orientée Documents en JSON, Couchbase cède à la tendance du moment en adoptant les index secondaires. L’éditeur affirme cependant avoir porté une attention toute particulière à ce que l’utilisation traditionnelle en Key/Value ne souffre d’aucun impact de performances.

Ce qui les a en partie conduits à introduire avec cette version « 4.0 » une nouvelle mécanique de répartition des charges grâce à une isolation des fonctionnalités clés désignée sous le nom assez ésotérique de « Multi Dimensional Scaling ».

Désormais, plutôt que de déployer toutes les fonctionnalités du moteur sur tous les nœuds d’un cluster, vous pourrez dédier certains nœuds au requêtage, d’autres à l’indexation, et le reste aux données. Une telle configuration évite que le requêtage n’impacte l’indexation par exemple (ou inversement). Surtout, cela permet d’ajuster les configurations matérielles de chaque nœud en fonction de la tâche qui lui est confié ; ce qui a du sens aussi bien on-premise que dans le Cloud (histoire d’optimiser les dépenses sur les configurations VM allouées).

Ils y reviennent au SQL…

Mais la grande nouveauté, c’est l’introduction d’un langage d’interrogation dénommé N1QL (prononcez Nickel) qui n’est rien d’autre qu’une évolution syntaxique de SQL. Il étend la syntaxe de sorte à permettre la désimbrication à la volée des documents JSON et de les traiter comme des données tabulaires. Rencontré lors d’un évènement Couchbase à Paris la semaine dernière, Ravi Mayuram, SVP Products and Engineering chez Couchbase, a décrypté la génèse du projet et l’utilité d’ainsi implanter du SQL sur du NoSQL : « L‘intérêt de NoSQL réside à la fois dans ses capacités de « scale-out » sur du hardware de commodité et dans l’absence des schémas qui contraignent les bases relationnelles traditionnelles.

Mais quand on s’intéresse aux interfaces de programmation au-dessus de cette architecture, je pense que l’on est allé trop loin dans le « No SQL » en se focalisant sur uniquement des API et aucun langage d’interrogation.

Les bases de données documents délaissent beaucoup trop de choses à la couche applicative. On peut créer des relations, mais la base de données elle-même ne s’occupe que du stockage. C’est en partant de cette constatation que nous avons commencé à réfléchir à un nouveau langage d’interrogation, un nouveau QL. On s’est souvenu qu’il y avait eu déjà plusieurs tentatives en la matière mais que finalement le seul QL qui ait survécu était SQL. Le problème, c’est que le modèle de données (tables liées par des relations) a changé, remplacé par un modèle récursif imbriqué (JSON). On s’est dit pourquoi ne pas simplement modifier SQL et étendre sa syntaxe pour supporter ce modèle ? C’est ainsi qu’est né N1QL et ses commandes Nest et UnNest ».

Du SQL sur du NoSQL

N1QL présente l’avantage d’insuffler bien plus d’intelligence dans la base elle-même. Il permet de recréer des relations entre les objets (et documents JSON) sans pour autant imposer la rigidité des schémas relationnels des SGBDR. Il simplifie par la même occasion toutes les opérations qui nécessitent de manipuler l’ensemble des données. Et il devrait aider à l’adoption des bases NoSQL auprès des développeurs qui maîtrisent SQL.

Mais N1QL apporte un autre atout dans l’escarcelle qui permet de concrétiser des scénarios jusqu’à aujourd’hui très complexes à réaliser. Ravi Mayuram explique ainsi : « N1QL se plugue dans l’écosystème SQL. Tous les outils, toute la BI, tous les outils de reporting que les utilisateurs exploitent déjà avec leur SGBDR deviennent maintenant utilisables avec les données non structurées hébergées dans Couchbase ». Un exploit rendu possible par l’introduction de pilotes ODBC/JDBC qui vont permettre désormais de créer des jointures entre des bases relationnelles et des bases Couchbase. Voilà qui devrait enfin rapprocher deux univers qui jusqu’ici prenaient grand soin de s’éviter.

On notera au passage que cette tendance est bien dans l’air du temps puisque MongoDB a aussi annoncé sa volonté d’intégrer un connecteur SQL d’ici la fin de l’année.

Autres améliorations de la 4.0

Parmi les autres nouveautés remarquables de cette 4.0, on retiendra l’arrivée officielle d’index géo-spatiaux (avec toutefois une limitation à une gestion de zones forcément rectangulaires dans cette version) jusqu’ici expérimentaux, ainsi que l’introduction du nouveau moteur développé maison et dénommé ForestDB qui utilise une structure hiérarchique B+ Trie que Couchbase affirme plus souple et évoluée que le traditionnel B-Tree. Celui-ci permet à la base de gérer les index secondaires.

Enfin dernière nouveauté, l’introduction de filtres de réplications. Couchbase est particulièrement apprécié par ses utilisateurs pour son mécanisme de réplication entre Data Center (XDCR = Cross Data Center Replication). Désormais, XDCR s’enrichit de filtres qui permettent de sélectionner les données à répliquer en fonction de la destination, par exemple, de ne répliquer vers les datacenters aux Etats-Unis que les données utiles aux clients américains.

Participer à la conversation

5 commentaires

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

Annuler
Annuler
Annuler
Annuler

- ANNONCES GOOGLE

Close