La version 4.0 du SGBD open source ScyllaDB est en disponibilité générale le 6 mai. Depuis la création de ScyllaDB en 2015, l’éditeur a positionné le projet open source comme un remplaçant de la base de données Apache Cassandra, tout en offrant ses propres avantages en termes de performances. L’objectif est de permettre aux utilisateurs de Cassandra et maintenant de DynamoDB d’utiliser les mêmes données, tables et schémas avec le SGBD ScyllaDB.
Prendre en charge DynamoDB était quelque chose de naturel pour ScyllaDB puisque les deux sont des bases de données NoSQL en colonnes, selon le PDG de ScyllaDB, Dor Laor.
« La façon dont les données sont conservées et rendues accessibles dans l’API Cassandra est assez bien adaptée à l’API DynamoDB. »
Dor LaorPDG, ScyllaDB
« Pour nous, l’ajout de cette API a été relativement simple, car la façon dont les données sont conservées et rendues accessibles dans l’API Cassandra est assez bien adaptée à l’API DynamoDB », ajoute-t-il.
Le PDG ne remet pas en cause les qualités de DynamoDB, mais pour lui, le fait qu’elle soit uniquement disponible sur AWS limite son adoption par certaines organisations, qui ne veulent pas se retrouver enfermées auprès du géant du cloud. Évidemment, Dor Laor met en avant le fait que ScyllaDB est un SGBD open source disponible sur site et dans le cloud.
Le passage de DynamoDB à ScyllaDB serait facilité par les outils de migration de l’éditeur open source. Ils peuvent scanner les données d’une base de données Cassandra ou DynamoDB existante et les envoyer à une nouvelle cible ScyllaDB. Le PDG explique qu’une migration inverse est également possible.
L’éditeur n’hésite pas à comparer les coûts estimés entre le déploiement de ScyllaDB et DynamoDB. Par ailleurs, Dor Laor était enthousiaste à la commercialisation de la version managée de Cassandra par AWS. Il voit dans les mouvements du cloudiste des opportunités pour son produit.
ScyllaDB cède lui aussi aux sirènes de l’opérateur Kubernetes
Une autre fonctionnalité clé que ScyllaDB prévoit de mettre en place en même temps que la mise à jour 4.0 n’est autre qu’un opérateur Kubernetes.
Kubernetes Operator est un mécanisme qui permet de définir et d’automatiser le déploiement d’applications sur un cluster Kubernetes. De nombreux éditeurs de bases de données, dont DataStax, Couchbase, NuoDB et CockroachDB, ont également adopté ce modèle.
« Si vous m’aviez demandé il y a un an ou deux, je n’étais pas du tout enthousiaste à propos de Kubernetes, car il ajoutait une couche de complexité supplémentaire », assure Dor Laor. « Mais Kubernetes s’est amélioré au fil des ans et il est extrêmement facile de mettre à l’échelle Scylla avec le Kubernetes Operator ».
Simplifier la gestion des streamings d’événements
ScyllaDB 4.0 bénéficie d’une série d’améliorations qui ont été présentées en avant-première lors de la conférence Scylla Summit 2019. Parmi ces fonctionnalités, la fonction Lightweight Transactions, qui permet de s’assurer que les données sont correctement enregistrées de manière cohérente et simultanée sur tous les nœuds d’un cluster ScyllaDB.
Parmi les utilisateurs de ScyllaDB figure l’éditeur de technologies marketing Numberly, basé à Paris. Alexys Jacob, directeur technique de Numberly, assure que sa société utilise Scylla en production depuis plus de deux ans pour maintenir des charges de travail à haut débit et sensibles à la latence. Des équipes d’ingénieurs, d’analystes de données et même de chefs de projet de Numberly utilisent ScyllaDB.
« En tant qu’expert en données, Numberly doit traiter beaucoup de types d’informations différents et si la vitesse est importante pour nous, notre capacité à être intelligent dans la façon dont nous gardons nos données à jour l’est tout autant », affirme Alexy Jacob. « C’est pourquoi nous discutons depuis un certain temps déjà avec les développeurs de ScyllaDB des transactions légères, et nous avons de fortes attentes à ce sujet ».
ScyllaDB 4.0 offre également une capacité de change data capture (CDC) en bêta qui intéresse Numberly. CDC permet aux applications de streaming d’événements d’écrire plus facilement les changements de base de données. Numberly, qui utilise Apache Kafka pour gérer ses flux d’événements, s’attend donc à ce que CDC lui permette de réagir plus rapidement aux changements de données au sein de ses pipelines.
