DataStax Proxy pour DynamoDB et Apache Cassandra® : avant-première

Hier, à l’ApacheCon, Patrick McFadin de DataStax a annoncé la sortie d’un outil open source permettant aux développeurs d’exécuter leurs capacités de traitement AWS DynamoDB™ dans Apache Cassandra. Avec DataStax Proxy pour DynamoDB et Cassandra, les développeurs peuvent exécuter leurs capacités de traitement   DynamoDB en local et profiter des avantages de Cassandra en termes d’évolutivité, ainsi que dans les configurations hybrides ou multi-modèles.

Contexte

Amazon DynamoDB est une base de données clé-valeur et orientée documents qui offre aux développeurs une grande élasticité et une expérience cloud zéro intervention. Cependant, l’étroite intégration d’AWS, qui fait tout l’attrait de DynamoDB dans le cloud, constitue une barrière pour les clients qui souhaitent l’utiliser en local.

Cassandra a toujours pris en charge les ensembles de données clé-valeur et tabulaires. Pour les workloads  DynamoDB, les clients DataStax n’avaient donc besoin que d’une opération de traduction vers leur moteur de stockage.

Aujourd’hui, nous présentons en avant-première un proxy qui assure la compatibilité avec le SDK de DynamoDB, permettant aux applications existantes de lire/écrire des données vers DataStax Enterprise (DSE) ou Cassandra sans aucune modification de code. Il présente également des avantages en termes d’évolutivité, dans les environnements hybrides et multi-modèles de Cassandra pour les utilisateurs de DynamoDB.

Si vous avez simplement besoin du code, vous le trouverez dans GitHub et DataStax Labs : https://github.com/datastax/dynamo-cassandra-proxy/

Scénarios possibles

Gestion du cycle de vie des applications : bon nombre de clients développent en local avant de déployer dans le cloud pour la production. Le proxy permet aux clients d’exécuter leurs applications DynamoDB à l’aide de clusters Cassandra en local.

Déploiements hybrides : DynamoDB Streams peut être utilisé pour permettre la gestion de charges de travail hybrides et les transferts depuis des déploiements cloud DynamoDB vers des déploiements en local utilisant un proxy Cassandra. Cela est pris en charge dans l’implémentation actuelle qui, comme DynamoDB Global Tables, utilise DynamoDB Streams pour déplacer les données. Pour le transfert hybride vers DynamoDB, découvrez les améliorations apportées à Cassandra CDC qui pourraient être utiles et restez à l’affût des mises à jour sur nos fonctionnalités CDC (Change Data Capture) dans le blog de DataStax.

Qu’offre le proxy ?

Le proxy est conçu pour permettre d’utiliser les applications DynamoDB avec Cassandra. Nous avons publié le nouvel outil sous licence open source Apache version 2 pour permettre aux utilisateurs d’en tirer le maximum d’avantages.

Le code est constitué d’une couche de proxy évolutive, située entre l’application et la base de données. Il assure la compatibilité avec le SDK de DynamoDB, ce que permet aux applications DynamoDB existantes de lire et d’écrire des données vers Cassandra sans avoir à modifier l’application.

Comment fonctionne-t-il ?

Quelques décisions ont été prises lors de la conception du proxy. Comme toujours, celles-ci sont en accord avec les principes de conception que nous utilisons dans le cadre du développement de Cassandra et de DataStax Enterprise.

Pourquoi un processus séparé ?

Nous aurions pu le concevoir sous forme de plugin Cassandra qui s’exécuterait dans le cadre du processus principal, mais nous avons décidé d’en faire un processus séparé pour les raisons suivantes :

1. Possibilité de faire évoluer le proxy indépendamment de Cassandra
2. Possibilité d’exploiter des outils k8s/cloud natifs
3. Flexibilité des développeurs et attrait pour les contributeurs – le travail sur le proxy ne nécessite pas de connaissances approfondies de Cassandra
4. Cadence de publication indépendante, pas liée au projet Apache Cassandra
5. Meilleure intégration d’AWS pour les applications sans état (par ex. utilisation d’alarmes CloudWatch, Auto Scaling, etc.)

« Pluggable Persistence », de quoi s’agit-il ?

À première vue, le modèle de données de DynamoDB est plutôt simple. Il se compose d’une clé de hachage1[s1] , d’une clé de tri et d’une structure JSON que l’on appelle élément. Suivant vos objectifs, le modèle de données DynamoDB peut être rendu persistant dans le langage Cassandra Query Language (CQL) de différentes manières. Afin de permettre l’expérimentation et d’offrir une bonne modularité, nous avons conçu la couche de traduction de manière à permettre l’utilisation de différents programmes de traduction. Nous poursuivons sur cet échafaudage en vue de tester plusieurs modèles de données et déterminer ceux qui sont le mieux adaptés pour :

1. différentes charges de travail ;
2. différentes exigences en termes de cohérence/linéarisation ;
3. différentes exigences de performance en fonction des SLA.

Conclusion

Si cela vous intéresse d’exécuter des charges de travail DynamoDB dans Cassandra, jetez un œil à notre projet. Vous pouvez vous lancer facilement, tout est décrit dans la readme et les paragraphes sur DynamoDB. Les fonctionnalités prises en charge par le proxy se multiplient rapidement et les collaborateurs sont les bienvenus.

https://github.com/datastax/dynamo-cassandra-proxy/

Tous les noms de produits et de sociétés sont des marques commerciales ou déposées de leurs propriétaires respectifs. L’utilisation de ces marques commerciales n’implique aucune affiliation au propriétaire de la marque ni son approbation.

1 Souvent, dans la documentation sur DynamoDB, cette clé est appelée clé de partition, mais comme ce n’est pas exactement la même chose que les partitions DynamoDB, nous préférons utiliser à la place l’expression clé de hachage.

 [s1]This footnote does not appear in the English text, but this is where it should be in FR.