Couchbase 4.0 : Quand le NoSQL se met au SQL

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.