Couchbase

Actualites

Couchbase met une touche de relationnel dans son SGBD NoSQL

Avec la mise à jour Couchbase Server 7.0, l’éditeur introduit des fonctionnalités équivalentes à des tables et des schémas dans sa base de données NoSQL. L’objectif affiché est de réduire les frictions à l’adoption pour les utilisateurs habitués au SGBDR. Dans le détail, ce n’est pas aussi simple qu’il y paraît.

par
Publié le: 02 août 2021

Le 29 juillet, une semaine après son entrée en bourse, l’éditeur a présenté la version 7.0 de sa base de données NoSQL freemium. La précédente mise à jour majeure, Couchbase 6.5, avait été dévoilée en octobre 2019.

Couchbase Server 7.0 apporte de nouvelles capacités de requêtes SQL. Elles doivent améliorer les transactions SQL ACID – atomicité, cohérence, isolation et durabilité - multidocuments, introduites avec la mouture 6.5. Cette fonction est censée offrir plus d’évolutivité et de meilleures performances aux utilisateurs.

Avec les transactions SQL ACID multi-documents, lorsqu’une action impliquant des mises à jour dans plusieurs documents se produit, cette action réussit ou échoue totalement, ce qui permet de conserver la cohérence des données, explique Carl Olofson, analyste chez IDC.

« Cette fonctionnalité [de transactions SQL ACID multidocuments] est courante dans les bases de données relationnelles depuis des dizaines d’années, mais sa présence au sein de SGBD orientés documents permet à Couchbase de prendre en charge les opérations plus sophistiquées nécessaires aux processus des applications des entreprises », déclare l’analyste.

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.

Un système de poupée russe

Dans le détail, un scope est stocké dans un bucket (autrement dit, une base de données) qui lui-même contient les collections de documents. Ce bucket est lui-même associé à un cluster formant ainsi une structure en forme de poupée russe. Un bucket peut rassembler plusieurs collections de documents types rattachées à une thématique.

Par exemple, un bucket peut être assigné à une activité, le voyage, et peut consigner un scope inventaire regroupant des collections liées aux informations des compagnies aériennes et d’autres aux hôtels, comme l’illustre la documentation de l’éditeur. Un cluster peut contenir jusqu’à 30 buckets et 1 000 collections. Un scope n’est pas indexé, mais il peut être abandonné, tandis que son contenu peut être répliqué. Il existe plusieurs méthodes pour générer ce scope (CLI, API Rest, langage de requêtes N1QL, SDK). Les collections elles-mêmes peuvent être éphémères. Ainsi, il semble possible d’établir une règle de conservation maximale de deux ans sur les données clients, comme l’impose le RGPD. L’accès à chacune des parties de cette poupée russe dépend d’un système de gouvernance régi par un RBAC.

 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.

Pour approfondir sur Base de données