Comment Mongoose amènera les développeurs orientés JSON vers Apache Cassandra

Apache Cassandra devient la meilleure base de données pour gérer les documents JSON. Si vous êtes un développeur Cassandra qui trouve cette déclaration provocante, lisez la suite.

Dans un article précédent, nous avons discuté de l'utilisation des API de données et de la modélisation des données pour transformer Cassandra en une expérience de développeur plus idiomatique par rapport à la façon dont les développeurs pensent, améliorant ainsi la productivité des développeurs tout en préservant des performances et une échelle de base de données raisonnables. C'est une excellente hypothèse et qui doit être testée dans le contexte d'un idiome de développeur particulier et d'une communauté de développeurs.

Mongoose , une bibliothèque de mappage de données d'objets généralement utilisée avec le pilote MongoDB, est un projet open source avec une importante communauté de développeurs JavaScript autour de lui. Au projet Stargate , la passerelle de données API open source conçue pour fonctionner avec Cassandra, nous nous sommes associés à Mongoose, et nous travaillons sur une prochaine API JSON qui sera publiée avec une version de Mongoose qui fonctionnera à travers ce JSON API pour se connecter à Cassandra. Cela crée une pile de bout en bout pour les développeurs Mongoose qui est entièrement open source. Cela change la donne pour les développeurs de Mongoose et ouvre un nouveau chapitre important pour Cassandra.

Dans cet article, je vais expliquer comment fournir un idiome JSON convivial pour les développeurs en utilisant Cassandra avec Stargate, et comment nous travaillons pour faire exactement cela pour les développeurs de Mongoose.

Les Boucles d'or des communautés JS

En octobre 2022, nous avons sorti une nouvelle version de Stargate. Avec la nouvelle version 2 , les API individuelles ne sont plus intégrées dans le code central du coordinateur Stargate, mais plutôt séparées en services individuels. Cela améliore l'efficacité opérationnelle de Stargate ; les services d'API individuels peuvent désormais être déployés et mis à l'échelle indépendamment. Cela facilite également le développement de nouveaux services API. Tant qu'ils respectent la limite de service, ces services peuvent être développés en parallèle et indépendamment du travail de développement principal de Stargate.

Nous avons ensuite cherché une expérience vraiment idiomatique que nous pourrions offrir aux développeurs. Avec 18 millions de développeurs, JavaScript est le langage de programmation le plus populaire au monde, et JSON est le moyen standard utilisé par les développeurs JavaScript pour structurer les données. Cependant, 18 millions de personnes ne constituent pas une communauté ; ce sont de nombreuses communautés. Nous avions besoin des "Goldilocks" des communautés JavaScript - suffisamment grandes pour être significatives, mais suffisamment petites pour être ciblées. Nous avons trouvé la bonne communauté construite autour de Mongoose, une bibliothèque de mappage de données d'objets utilisée avec des applications qui se connectent à MongoDB. La mangouste a plusieurs caractéristiques importantes :

• C'est centré sur JavaScript
• Il bénéficie d'une large adoption, avec environ 2 millions de référentiels GitHub répertoriant Mongoose comme dépendance
• Le leadership actif du créateur de Mongoose, Valeri Karpov, fournit une orientation claire
• C'est un projet open source qui n'avait pas de base de données open source depuis la décision de MongoDB de passer à un modèle de source partagée avec sa licence publique côté serveur

Les développeurs n'interagissent pas vraiment directement avec une base de données, mais plutôt avec un modèle de données. Dans l'API Document originale de Stargate, l'API gère JSON en le faisant ressembler à une table Cassandra traditionnelle. Cela oblige les développeurs orientés JSON à penser en termes de structures de données Cassandra et alourdit la logique d'indexation orientée lignes de Cassandra, car un document JSON est réparti sur plusieurs lignes.

Notre nouvelle API JSON s'écarte de ce modèle de données et s'appuie à la place sur un modèle de données que nous appelons "super déchiquetage". Vous pouvez en savoir plus sur le super déchiquetage en regardant le discours d'Aaron Morton lors du récent événement Cassandra Forward . En bref, nous profitons de la nature à colonnes larges de Cassandra pour stocker un document par ligne, sachant qu'une ligne Cassandra peut gérer même des documents très volumineux. Nous avons également un ensemble de colonnes dans cette ligne qui sont explicitement destinées au stockage des caractéristiques de métadonnées standard d'un document JSON. Nous avons maintenant quelque chose de plus facilement indexable, ainsi qu'un moyen de préserver et de récupérer les métadonnées.

Nous présenterons ensuite ce modèle de données avec notre nouvelle API JSON, en utilisant la même spécification mQuery que Mongoose utilise comme exigence directrice pour les appels que l'API doit prendre en charge. Une fois terminé, cela devrait permettre à l'une des plus de 2 millions d'applications dépendantes de Mongoose de s'exécuter sur Cassandra open source ou sur le service Cassandra hébergé de DataStax, Astra DB , avec juste un changement de configuration.

Avec Mongoose et la nouvelle API JSON, nous fournirons une expérience entièrement idiomatique aux développeurs JavaScript orientés JSON, en leur donnant l' échelle et les performances de Cassandra qui sous-tendent un modèle de données JSON authentique.

Le créateur de Mongoose, Karpov, a également pris la parole lors du récent événement Cassandra Forward (vous pouvez regarder la rediffusion ici ), démontrant une application de commerce électronique simple qui utilise la version Stargate de Mongoose, Stargate open source et la version DataStax Enterprise (DSE) de Cassandra. Vous pouvez télécharger le code de travail de cette application et les éléments de plate-forme de support à partir de GitHub . Bien que nous ayons suffisamment de code pour exécuter cette application, nous n'avons pas encore terminé le code. Par exemple, nous courons contre DSE en ce moment parce que nous avons besoin de l'indexation de stockage attaché (SAI), qui fonctionne avec DSE et dont la sortie est prévue dans Cassandra 5.0 plus tard cette année.

Contribuer à Cassandra

Cassandra n'est pas un logiciel statique ; c'est un projet open source dynamique et évolutif. Nous poursuivons donc également une tradition de longue date de Cassandra consistant à utiliser des fonctionnalités telles que SAI qui émergent côté client pour favoriser les changements du côté de la base de données. améliorera non seulement l'API JSON de Stargate et le client Mongoose, mais ajoutera de nouvelles fonctionnalités puissantes au langage de requête Cassandra. C'est un excellent rappel que les ingénieurs de données et les développeurs d'applications ne sont pas deux communautés différentes, mais des cohortes complémentaires de la communauté Cassandra étendue.

Et JSON n'est que la première étape. Essentiellement, ce que nous aurons fait est de prendre les éléments de base de Cassandra, Stargate et un modèle de données Cassandra raisonnablement efficace et de créer une base de données de documents avec laquelle vous interagissez via une API JSON. En d'autres termes, nous avons utilisé le super déchiquetage pour créer une base de données spécialement conçue pour mieux servir la communauté des développeurs de Mongoose.

Avec l'architecture modulaire de Stargate v2 et le point de preuve de Mongoose pour l'approche idiomatique, nous sommes prêts à affronter de nouvelles communautés de développeurs qui s'organisent autour d'un langage de développement logiciel particulier. Le processus par lequel nous avons exploité Cassandra pour Mongoose est reproductible - et c'est celui que nous répéterons. Ce faisant, nous augmentons considérablement le nombre de développeurs et de cas d'utilisation auxquels Cassandra peut répondre, ce qui est le genre d'objectif digne d'un projet open source.

En savoir plus sur DataStax .

Par Mark Stone. Mark est chef de produit chez DataStax. Il est un vétéran de la technologie avec de nombreuses années d'expérience dans la gestion de produits, la gestion de programmes et la gestion des personnes. Travaillant toujours dans le cadre du tissu conjonctif entre les parties prenantes commerciales et les parties prenantes techniques, Mark aime défendre l'expérience des développeurs sur les plateformes technologiques et aider les organisations à rencontrer les développeurs là où ils se trouvent.