Création de services de données conviviaux pour les développeurs avec Apache Cassandra

Toutes les applications dépendent des données, mais les développeurs d'applications n'aiment pas penser aux bases de données. L'apprentissage des composants internes et du langage de requête d'une base de données particulière ajoute une charge cognitive et nécessite un changement de contexte qui nuit à la productivité. Néanmoins, les applications réussies doivent être réactives, résilientes et évolutives - toutes les caractéristiques qui seront déterminées par le choix de la base de données.

Comment, alors, un développeur d'applications doit-il équilibrer ces considérations ?

Et si nous pouvions modifier l'équilibre, en fournissant un service de données dans des idiomes conviviaux pour les développeurs, plutôt que d'attendre des développeurs qu'ils apprennent des idiomes spécifiques à la base de données ?

Au projet Stargate, la passerelle de données API open-source conçue pour fonctionner avec Apache Cassandra , nous sommes ravis de commencer à parler publiquement de notre prochaine API JSON qui répond aux développeurs orientés JSON selon leurs conditions. Non seulement c'est une excellente nouvelle pour les développeurs orientés JSON, mais la technique que nous avons suivie constitue un nouveau modèle de conception pour tirer parti des API de données et de la modélisation avancée des données pour produire des services de données.

Dans cet article, je vais expliquer comment fournir des idiomes conviviaux pour les développeurs en utilisant Cassandra avec Stargate, et comment nous travaillons pour faire exactement cela pour JSON .

Modèles de données : interopérabilité vs Idiom

Au début, Cassandra était parfois décrite comme "une machine à faire des index". Cela témoignait de la résilience et de la flexibilité inhérentes à Cassandra, une argile à partir de laquelle des structures plus robustes pouvaient être moulées. Cassandra est aujourd'hui une argile plus riche avec de plus grandes possibilités.

Non seulement c'est une excellente base de données, mais c'est aussi une excellente machine pour créer des bases de données. Ici, au projet Stargate, nous utilisons l'API JSON pour le prouver comme premier exemple d'un nouveau paradigme dans le développement de bases de données.

Il n'est pas rare qu'une base de données soit construite à partir d'une autre. Même MongoDB est construit sur WiredTiger , si vous creusez assez profondément. AWS est connu pour son utilisation intensive de MySQL dans les coulisses, y compris l'utilisation du moteur de stockage MySQL pour DynamoDB . L'idée d'utiliser Cassandra, avec son évolutivité et ses performances inhérentes, comme élément de base pour d'autres systèmes de données est donc logique.

Pourtant, les développeurs d'applications n'interagissent pas vraiment avec les bases de données. Même si votre organisation gère sa propre infrastructure de base de données et crée des applications sur cette infrastructure, la première étape consiste généralement à définir et à implémenter les modèles de données dont vos applications ont besoin.

Ces modèles de données assurent la médiation entre l'application et la base de données. Dans un certain sens, la modélisation des données limite une base de données ; il prend de l'argile non formée, et donc à usage général, et la façonne en quelque chose de spécialement conçu pour un idiome d'application particulier. Nous sacrifions l'interopérabilité pour quelque chose d'idiomatique.

Est-ce une bonne idée d'échanger contre quelque chose d'idiomatique et de renoncer à quelque chose d'interopérable ? Si vous voulez battre les moyennes, alors la réponse est un « oui » catégorique. Nous ne pensons pas beaucoup de cette façon lors du choix des bases de données, mais nous avons longtemps pensé de cette façon lors du choix des langages de programmation.

Cette idée a été bien exprimée par Paul Graham il y a des décennies lorsqu'il a expliqué comment Viaweb a remporté la première course des dot-com pour créer la première plate-forme de commerce électronique basée sur le Web.

Viaweb n'était pas nécessairement la plateforme de commerce électronique la plus rapide ou la plus évolutive. Selon les mots de Graham, c'était "raisonnablement efficace". Au lieu de cela, Graham soutient que, pour les langages de programmation, sur une échelle allant du lisible par machine au lisible par l'homme, les langages plus lisibles par l'homme (et donc de niveau supérieur) sont plus puissants car ils améliorent la productivité des développeurs. Et à l'époque de Viaweb, Graham pensait que le langage le plus puissant était Lisp . Le nœud de l'argument de Graham est le suivant :

« Notre hypothèse était que si nous écrivions notre logiciel en Lisp, nous serions en mesure d'obtenir des fonctionnalités réalisées plus rapidement que nos concurrents, et aussi de faire des choses dans notre logiciel qu'ils ne pourraient pas faire. Et parce que Lisp était de si haut niveau, nous n'aurions pas besoin d'une grosse équipe de développement, donc nos coûts seraient plus bas. Si tel était le cas, nous pourrions offrir un meilleur produit pour moins d'argent tout en réalisant un profit. Nous finirions par avoir tous les utilisateurs, et nos concurrents n'en auraient aucun et finiraient par faire faillite.

Libérer la productivité des développeurs

Graham a écrit ces mots il y a 20 ans, et la productivité des développeurs reste l'étoile polaire qui guide une grande partie de l'innovation technologique. Là où Graham parle de la puissance des langages de niveau supérieur, nous exprimons ce même concept en fournissant aux développeurs des outils plus idiomatiques pour leur expérience de développement logiciel.

Graham fait l'éloge de Lisp (à juste titre), et depuis l'époque des dot-com, nous avons assisté à une prolifération de nouveaux langages de niveau supérieur : Ruby et Rust, pour n'en nommer que quelques-uns. Nous avons également assisté à la naissance et à la prolifération de langages et de frameworks de développement d'appareils mobiles, tels que Swift, Flutter et Dart.

Alors pourquoi des langages comme C et C++ sont-ils toujours importants ? La vieille blague sur C contient une vérité importante : "Combiner la puissance du langage d'assemblage avec la facilité d'utilisation du langage d'assemblage." Si vous voulez écrire un compilateur, vous devez vous rapprocher de l'idiome du langage machine et vous éloigner de l'idiome du langage naturel.

Autrement dit, entre autres vertus, C et C++ sont des machines à construire de nouveaux langages. Ce qu'il est facile d'oublier dans l'éloge de Lisp par Graham, c'est que Lisp a aussi une partie de cette caractéristique de « machine à construire des langages ».

Lisp a été le premier langage largement utilisé à introduire le concept de macros, et c'est souvent le concept de macros qui déclenche les nouveaux Lisp. Une fois que vous comprenez les macros, vous comprenez que Lisp est plus un méta-langage qu'un langage et que les macros peuvent être utilisées pour créer un langage spécialement conçu pour un domaine de problème spécifique.

Concevoir et créer un ensemble initial de macros est un travail difficile et stimulant sur le plan intellectuel. Mais une fois que Graham et l'équipe de Viaweb ont fait cela, ils avaient en fait un langage de programmation de commerce électronique avec lequel travailler, et cela a débloqué la productivité des développeurs qui leur a permis de devancer leurs concurrents.

Vingt ans plus tard, tout cela semble assez clair dans le contexte des langages de programmation. Alors, que s'est-il passé dans le monde des bases de données ? La réponse courte est que les bases de données ont évolué plus lentement.

La révolution des API de données

Si les données tabulaires sont le langage d'assemblage du monde des bases de données, alors SQL est le C/C++ des langages de requête. Nous avons développé des structures de données tabulaires et le concept de normalisation des données à une époque où le calcul et le stockage étaient coûteux, et pour des cas d'utilisation bien définis avec des changements de schéma relativement peu fréquents. Dans ce contexte, pour fonctionner efficacement à n'importe quelle échelle, les bases de données devaient imiter étroitement la manière dont les ordinateurs stockaient les informations et y accédaient.

Le monde d'aujourd'hui est à l'opposé, ce qui fait que cette époque antérieure semble archaïque en comparaison : les coûts de calcul et de stockage sont hautement banalisés, mais dans un monde de données en temps réel combinées à l'apprentissage automatique et à l'intelligence artificielle, les cas d'utilisation sont ouverts et les changements de schéma sont fréquent.

La révolution la plus récente dans la technologie des bases de données a été la révolution NoSQL, une réponse directe au canon des données tabulaires et normalisées établi par les grands prêtres du monde des bases de données relationnelles. Lorsque nous disons « révolution NoSQL », nous faisons référence à la période allant de 2004, lorsque Google a publié son livre blanc MapReduce , jusqu'en 2007, lorsque Amazon a publié son livre blanc Dynamo .

Ce qui a émergé de cette période était une famille de bases de données qui a atteint une vitesse, une évolutivité et une résilience sans précédent en abandonnant deux principes relationnels précieux : les bases de données NoSQL favorisaient les données dénormalisées par rapport à la normalisation des données et favorisaient la cohérence éventuelle par rapport à la cohérence transactionnelle. Cassandra, sorti pour la première fois en 2008, est issu de cette révolution.

Les API de données seront la prochaine révolution majeure dans la technologie des bases de données, une révolution qui ne fait que commencer. Les changements dans le monde des bases de données ont tendance à être en retard sur les changements dans les langages de programmation et le développement d'applications. Ainsi, alors que les API RESTful existent depuis un certain temps et ont aidé à inaugurer l'architecture des applications distribuées orientées services, nous commençons tout juste à voir les API de données se manifester comme un élément clé de l'infrastructure des applications.

Pour comprendre l'importance de cette révolution et comment, 20 ans après la proclamation de Paul Graham, le monde des bases de données offre enfin la productivité des développeurs, regardons la propre histoire de Stargate. Il commence par revenir sur le thème de l'interopérable versus idiomatique.

Stargate : une expérience de développement idiomatique haute fidélité

Lorsque nous avons décidé que l'écosystème Cassandra avait besoin d'une passerelle de données, nous avons construit l'ensemble original d'API Stargate avec un sentiment d'urgence. Cela signifiait une architecture monolithique; les monolithes sont plus rapides à construire, mais pas toujours meilleurs. Nous avons lancé avec une API Cassandra Query Language (CQL), une API REST et une API RESTful Document. Nous avons rapidement ajouté GraphQL comme API supplémentaire. À ce jour, Stargate est interopérable ; tout de Stargate est stocké à l'aide d'un modèle de données CQL natif, donc en principe, vous pouvez interroger n'importe quelle table à partir de n'importe quelle API.

Nous avons appris qu'en pratique, personne ne fait vraiment cela. Les développeurs s'en tiennent à leur langage particulier. En favorisant l'interopérabilité, nous avons saigné Cassandra-isms dans l'expérience du développeur, entravant ainsi la productivité du développeur. Parce que la version originale de Stargate exigeait que les développeurs comprennent les structures de données tabulaires à larges colonnes de Cassandra, pour comprendre les espaces de clés et les partitions, nous nous sommes ancrés trop près de l'idiome de la machine et trop loin de l'idiome humain.

Le piège de l'interopérabilité consiste à privilégier l'objectif général par rapport à la pensée de conception intégrée à l'objectif. Nous nous sommes tournés vers une réflexion en termes d'objectifs, qui échangent une capacité générale contre un mode d'expression plus spécifique, nous rapprochant de l'idiome humain et nous éloignant de l'idiome de la machine. Et nous avons donc commencé à réfléchir : pourrions-nous offrir une expérience de développeur idiomatique haute fidélité tout en conservant les vertus des fondations NoSQL de Cassandra (évolutivité, disponibilité et performances) ?

La clé réside dans la modélisation des données. Afin de transformer Cassandra en "Lisp des bases de données", nous avions besoin d'un modèle de données qui pourrait servir un objectif analogue aux macros Lisp, ainsi qu'une API Stargate qui permettrait aux développeurs d'interagir idiomatiquement avec ce modèle de données. Nous avons commencé avec JSON, le plus grand dénominateur commun des structures de données parmi les développeurs d'applications, et avons donc commencé à construire l'API JSON pour Stargate. Ensuite, nous avons dû trouver la meilleure façon de modéliser JSON dans Cassandra.

Stargate a déjà une API de document, mais dans l'API de document originale de Stargate, nous avons utilisé un modèle de données que nous appelons "déchiquetage " pour rendre un document JSON sous la forme d'une table Cassandra. Ce modèle mappe un document sur plusieurs lignes dans une seule table Cassandra et préserve l'interopérabilité. Si vous utilisez CQL pour interroger la table résultante, vous obtiendrez des résultats significatifs.

Ce modèle de données de déchiquetage original a des inconvénients. Il ne conserve pas les métadonnées d'un document. Par exemple, pour tout document contenant des tableaux, une fois le document écrit, nous ne savons rien de la taille du tableau sans inspecter complètement le document. Plus important encore, nous nous sommes écartés des attentes de Cassandra concernant l'indexation. Index Cassandra sur les lignes, mais nous avons maintenant réparti notre document sur plusieurs lignes, ce qui rend impossible un index Cassandra natif des documents.

Pour faire de Cassandra un moteur de stockage adapté à JSON, nous allions avoir besoin d'un nouveau modèle de données, quelque chose de supérieur au déchiquetage. Nous l'avons appelé "super déchiquetage". Vous pouvez en savoir plus sur le super déchiquetage lors de la conférence Cassandra Summit d'Aaron Morton en décembre, mais voici un petit aperçu : 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 de très gros documents.

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.

Contribuer à Cassandra

Oui, pour que tout cela fonctionne à grande échelle, nous aurons besoin de quelques changements sous-jacents à Cassandra. Accord, qu'Apple contribue à Cassandra 5, nous aidera à gérer les changements de données de manière plus transactionnelle. L'indexation liée au stockage (SAI) et le tri global, que DataStax contribue à Cassandra 5 , nous aideront à gérer les requêtes étendues sur les documents JSON de manière plus performante.

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 les exigences qui émergent côté client pour favoriser les changements côté base de données. Les besoins des utilisateurs ont incité les propositions pour Accord, SAI et Global Sort. Cela améliorera non seulement l'API JSON de Stargate, mais rendra Cassandra meilleure. 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, nous aurons construit une base de données de documents avec laquelle vous interagissez via une API JSON à partir de Cassandra, Stargate et un modèle de données Cassandra raisonnablement efficace. Le super déchiquetage est notre macro. Cette approche transforme Cassandra en une machine à créer des bases de données.

Cette approche pourrait-elle être suivie par une autre base de données en plus de Cassandra ? Pas facilement, et voici pourquoi. Il existe une sorte de base de données analogue à la deuxième loi de la thermodynamique qui joue en faveur de Cassandra. Nous commençons avec quelque chose de rapide, évolutif et résilient, mais pas très idiomatique pour les développeurs. Dans les limites d'une efficacité raisonnable, nous échangeons une partie de cette vitesse, de cette échelle et de cette résilience contre une interface plus idiomatique à présenter aux développeurs. Ce qu'on ne peut pas faire facilement, c'est aller dans le sens inverse. Commencer avec quelque chose de très idiomatique, puis essayer de trouver comment le rendre rapide, évolutif et résilient est une tâche ardue qui pourrait même ne pas être possible.

Ce principe thermodynamique est la raison pour laquelle les API de données sont la nouvelle révolution des bases de données, et pourquoi Cassandra est la base de données qui alimentera cette révolution.

Également publié ici.