Couchbase met une touche de relationnel dans son SGBD NoSQL

Scopes et collections : la frontière entre SQL et NoSQL semble de plus en plus poreuse

Selon l’éditeur, les points forts de cette version sont les « scopes » et les « collections ». L’objectif derrière le développement de ces deux objets est d’apporter une nouvelle capacité d’organisation au sein de la base de données NoSQL qui mimique le mécanisme des tables et des schémas d’un SGBD relationnel.

Couchbase est perçue comme une « base de données sans schéma » (schema-less en VO) et ne disposait pas auparavant d’une fonction de ce type.

Les scopes et les collections sont « des avancées majeures », selon Carl Olofson.

Lorsque plusieurs applications reposent sur des bases de données orientées documents, ces documents peuvent contenir des données qui se superposent. Dans ce cas, il doit y avoir un mécanisme pour coordonner ce chevauchement.

Dans les collections de documents, les fichiers JSON qui sont uniques à une application et les documents qui sont partagés sont traités ensemble, ce qui offrirait un fonctionnement similaire au précédent système, mais débarrassé des problèmes de duplication et de synchronisation.

Chasser sur les terres d’Oracle et de Microsoft

« L’objectif pour Couchbase est d’évoluer vers le haut de la chaîne alimentaire. Il s’agit de ne plus seulement être le back-end des applications métiers et Edge, mais de pouvoir traiter une gamme de transactions plus complexes basées sur les processus d’entreprise », constate-t-il.

Couchbase a conçu les scopes comme des équivalents à des schémas, tandis que les collections s’apparentent aux tables d’une base de données relationnelle. Une collection contient des documents, analogues aux lignes dans une table d’un SGBDR, et les documents comportent des champs de données, similaires à des colonnes.

« Nous avons tous une très bonne idée de la manière dont nos données sont structurées dans une base de données relationnelle. Il existe une ontologie pour cela, avec un schéma de base de données, une table, des lignes et des colonnes ; c’est ainsi que les données sont organisées », explique Ravi Mayuram, directeur technique de Couchbase. « Nous avons donc voulu offrir un équivalent de cela ».

Ravi Mayuram a déclaré qu’avec les scopes et les collections de Couchbase 7.0, il existe désormais une correspondance « 1:1 » entre les données provenant du système relationnel d’une entreprise et la façon dont elles peuvent être structurées dans Couchbase.

 Ces fonctionnalités faciliteront la migration d’une base de données relationnelle vers Couchbase, avance le CTO. En clair, l’éditeur adopte la même position que MongoDB et Redis Labs souhaitant lui aussi devenir un généraliste capable de supporter la plupart des cas d’usage dont les applications customer 360, dixit Couchbase. Selon ce principe, une technologie de base de données doit suffire à couvrir tous les besoins d’une entreprise. C’est avec ce pari en tête que l’éditeur a lancé son IPO. L’objectif semble clair : chasser sur les terres d’Oracle, de Microsoft, MariaDB ou tous autres distributeurs d’un SGBD SQL, MySQL ou PostgreSQL.

Un procédé de migration moins évident qu’il n’y paraît

En réalité, le processus de migration n’est pas aussi simple que le prétend le CTO. Pour les entreprises ou équipes de développement qui utilisent déjà Couchbase, leurs documents et index sont directement stockés dans les scopes et collections par défaut. Des index secondaires globaux doivent être créés pour chaque collection, selon la documentation.

L’éditeur recommande de consolider le contenu des anciens buckets vers les nouvelles collections dans un seul bucket. L’autre stratégie de migration consiste à séparer les données d’un seul bucket vers des collections multiples contenues dans un bucket. Cette deuxième solution s’avère plus complexe, car il faut administrer les champs de type et préfixes de clés, c’est-à-dire les composants nécessaires à l’organisation des données avant la version 7.0. Il faut aussi modifier les requêtes au sein des applications associées à la base de données pour prendre en charge le nommage des scopes et des collections. Là encore, il faut supprimer les mentions aux champs de type et aux préfixes de clés, désormais inutiles.

Cette migration intime également le changement de flux TLS. Couchbase recommande d’adopter le protocole TLS 1.2 ou supérieur. Sans trop de surprise, le support pour CentOS 8, mais aussi pour Windows Server 16 est déprécié.

Cependant, l’éditeur impose un chemin de migration bien spécifique qui oblige les utilisateurs des versions antérieures à la release 6.0 de passer par la version 6.6 avant de pouvoir installer Couchbase Server 7.0, soit à effectuer au moins deux mises à jour. Par ailleurs, Couchbase Server est disponible suivant deux licences.

La community edition (CE), gratuite, est réservée aux environnements de développement et de test ou aux petits déploiements, tandis l’Enterprise Edition (EE), payante, supporte les usages en production (la version open source du projet Server est « la plateforme dédiée à l’innovation », en clair, aux nouvelles contributions avant leur intégration dans les éditions CE et EE). Pour passer d’un modèle de licence à l’autre, les versions de deux éditions doivent être identiques.

Enfin, la migration des données d’une base relationnelle vers Couchbase 7.0 n’est pas réellement standardisée. L’éditeur recommande de combiner ces connecteurs JDBC avec son SDK Java pour MySQL. De son côté, Matthew D. Groves, Senior Product Marketing Manager chez Couchbase, a créé un outil de conversion automatique des données, des schémas et index de SQL Server vers Couchbase, disponible sur GitHub. Il faudra sans doute passer par un intégrateur ou les services de consultance payants de l’éditeur pour y voir plus clair.