Les transactions ACID arrivent sur Apache Cassandra : voici pourquoi nous sommes ravis

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

Sortons d'abord la meilleure partie. Les transactions ACID arrivent sur Apache Cassandra.

Transactions à usage général disponibles dans le monde entier qui fonctionnent comme Cassandra. Ce n'est pas une astuce avec des petits caractères ou l'application d'anciennes techniques.

Cela est dû à une percée informatique extraordinaire appelée Accord d'une équipe d'Apple et de l'Université du Michigan. Cela aidera Cassandra à changer notre façon de penser les données en ouvrant de nouveaux cas d'utilisation.

Voici ce que cela signifie pour ceux qui ne connaissent pas les tenants et les aboutissants du projet Cassandra et de ses fonctionnalités. Rien n'est plus important que la vitesse à laquelle vous pouvez mettre une application en production. Mais les développeurs qui veulent mettre à profit l'échelle, la résilience et le support légendaire de plusieurs centres de données de Cassandra pour travailler sur quelque chose comme les transactions financières ont dû coder un tas de solutions de contournement compliquées dans leurs applications. Les compromis par rapport à l'utilisation, disons, d'Oracle étaient importants.

Avec Accord ? Aucun compromis. Cassandra prendra désormais en charge tout ce qui l'a rendue incroyable tout en transférant la prise en charge des transactions vers la base de données, ce qui réduira considérablement la complexité du code.

L'oeil de l'observateur

Un système de base de données a des fonctions essentielles, telles que le stockage fiable des données et la disponibilité pour les requêtes. La gestion des modifications apportées aux données n'est pas toujours une fonction de base de données. Dans le cas de nombreux systèmes NoSQL, la charge de la gestion des changements est reportée sur l'utilisateur. L'observateur du changement de données est celui qui attribue l'importance de l'exclusivité.

Supposons qu'il s'agisse d'accumuler des données telles qu'elles sont données. Dans ce cas, l'observateur doit savoir que les données ont été reçues et stockées de manière durable - par exemple, les données des cours boursiers où chaque point de données est unique et cumulatif. Il n'y a pas besoin d'exclusivité.

Dans les opérations plus sensibles, l'observateur d'un changement de données doit avoir l'impression d'être le seul processus utilisant la base de données. C'est un concept en informatique appelé « isolement » ; c'est le "I" dans ACID (atomicité, consistance, isolation, durabilité).

Un exemple classique est un virement bancaire où l'argent est soustrait d'un compte bancaire puis ajouté à un autre - précisément dans cet ordre. Le processus d'observation a besoin d'exclusivité pour éviter que d'autres processus n'apportent des changements qui peuvent conduire à des incohérences ou à des surprises.

Les surprises incluent l'autorisation par inadvertance d'un transfert depuis un compte qui est passé en dessous de 0 $.

L'isolement garantit qu'un seul processus peut apporter une modification à la fois, et si deux sont en concurrence pour les mêmes données, l'un d'eux devra attendre que l'autre se termine.

Acceptez votre paresse

Les développeurs doivent évoluer rapidement avec un système auquel ils peuvent faire confiance. Les transactions ACID sont l'étalon-or de la confiance dans les systèmes de bases de données depuis près de 50 ans. Les développeurs travaillent à travers des compromis basés sur les exigences, les amenant parfois à travailler avec des systèmes qui ne prennent pas en charge les transactions ACID.

Avec les systèmes NoSQL, les biais de compromis avaient historiquement tendance à pencher vers l'échelle et la disponibilité tout en sacrifiant les transactions.

Amener les transactions ACID à Cassandra a consisté à réduire les compromis. Cassandra a déjà une solide réputation pour la mise à l'échelle linéaire tout en maintenant la disponibilité dans les pires scénarios.

Cassandra a été le choix lorsque vous avez besoin d'une base de données qui résistera à ce qu'Internet peut offrir. Sans surprise, le besoin de transactions a été une source de conflit de compromis pour les développeurs.

Pouvons-nous obtenir un consensus?

Dans les systèmes distribués, chaque nœud membre du plus grand cluster peut agir indépendamment ou doit se coordonner avec d'autres nœuds. Dans une transaction où, "Hé, nous devons tous nous mettre d'accord sur quelque chose", les informaticiens appellent ce consensus, et le développement de ces protocoles est un domaine d'amélioration continue.

Paxos est un protocole de consensus établi de longue date adopté par Cassandra en 2013 pour les « transactions légères ».

Léger car il garantit qu'un seul changement de données de partition est isolé dans une transaction, mais plus d'une table ou partition n'est pas une option. De plus, Paxos nécessite plusieurs allers-retours pour obtenir un consensus, ce qui crée beaucoup de latence supplémentaire et de petits caractères sur le moment d'utiliser des transactions légères dans votre application.

Le protocole Raft a été développé en tant que prochaine génération pour remplacer Paxos, et plusieurs systèmes tels que Etcd, CockroachDB et DynamoDB l'ont adopté. Il a réduit les allers-retours en créant un chef élu.

L'inconvénient pour Cassandra dans cette approche est que les leaders ne couvrent pas les centres de données, donc plusieurs leaders sont nécessaires (voir Spanner ).

Avoir un dirigeant élu viole également les principes du « rien partagé » de Cassandra et imposerait de nouvelles exigences en matière de gestion des échecs.

Si un nœud tombe en panne, un nouveau chef doit être élu.

D'autres bases de données - FaunaDB et FoundationDB, par exemple - ont tenté de résoudre le problème des multileaders en se réduisant à un seul leader mondial, comme décrit dans l' article de Calvin .

Étant donné que celles-ci ont été conçues pour d'autres bases de données avec des exigences différentes, les approches utilisées dans ces cas n'ont pas répondu aux critères auxquels Cassandra s'attend avec les modes de défaillance.

Cassandra suppose que les défaillances font partie de l'exécution d'un système distribué étendu. Un ou plusieurs nœuds mis hors ligne ne doivent pas entraîner une dégradation rapide des performances ou des problèmes de disponibilité. Nous avions besoin d'une approche différente.

Sommes-nous parvenus à un accord ?

Nous pouvons être très opiniâtres sur ce qui est acceptable pour le projet Cassandra. Nos critères consistent à rester fidèles aux convictions fondamentales sur la manière dont les systèmes distribués doivent fonctionner. Les performances et l'évolutivité doivent toujours être préservées lors de l'exploitation de plusieurs nœuds sur un ou plusieurs centres de données. Nous pouvons être assez exigeants, mais c'est ce qui fait de Cassandra le choix de tant d'organisations.

Les itérations précédentes des protocoles de consensus ont résolu différentes parties du problème, mais chacune présentait un compromis qui violerait certaines des valeurs de Cassandra. On dit que la prochaine grande percée est à deux articles du dernier. Dans ce cas, le document était Accord , et il a fallu un grand coup pour éliminer les compromis.

Accord résout deux problèmes qui ne sont pas résolus dans les protocoles de consensus précédents : comment pouvons-nous avoir un consensus disponible à l'échelle mondiale et y parvenir en un aller-retour ? Le premier nouveau mécanisme est le tampon de réorganisation.

En supposant que du matériel de base est utilisé, les différences d'horloge entre les nœuds sont inévitables. Le tampon de réorganisation mesure la différence entre les nœuds en plus de la latence entre eux. Chaque réplica peut utiliser ces informations pour ordonner correctement les données de chaque nœud et tenir compte des différences, garantissant un consensus aller-retour avec un protocole d'horodatage.

L'autre mécanisme est celui des électorats accélérés. Les modes d'échec peuvent créer une latence lors de l'élection d'un nouveau leader avant de reprendre. Les électeurs du chemin rapide utilisent des fonctionnalités préexistantes dans Cassandra avec quelques nouvelles implémentations pour maintenir un chemin rapide sans leader vers le quorum sous le même niveau d'échec toléré par Cassandra. Plus de détails peuvent être lus dans la proposition .

Comment ça marche?

Le plus grand impact sera sur la productivité des développeurs, alors voyons à quoi cela ressemble dans la pratique. Considérez l'exemple de transfert de compte bancaire suivant que nous avons mentionné précédemment :

La première est la nouvelle syntaxe que vous verrez dans le langage de requête Cassandra (CQL). Les transactions sont contenues dans une déclaration BEGIN TRANSACTION et COMMIT TRANSACTION . Tout ce qui se trouve à l'intérieur des marqueurs de transaction se produira de manière atomique, isolé des autres processus. Nous allons transférer 20 $ du compte d'Alice à Bob dans cet exemple. Il n'y a pas plus classique que ça !

Dans la section A, nous pouvons sélectionner des données à partir d'un enregistrement existant et affecter le résultat à un tuple (plusieurs éléments stockés dans une seule variable). En fonction du nombre de colonnes dans la clause SELECT , vous pouvez stocker une ou plusieurs valeurs dans le tuple. Ces valeurs seront utilisées dans la section B pour tester les conditions avant de modifier les données.

Dans ce cas, nous testerons pour voir si Alice a 20 $ sur son compte avant de transférer à Bob. Si tel est le cas, une UPDATE décrémente le solde du compte d'Alice de 20 $, puis incrémente celui de Bob de 20 $. Si Alice avait moins de 20 $, les changements ne se produiraient pas.

Dans les coulisses se trouve un ensemble sérialisé de commandes de base de données qui s'exécutent exclusivement, comme le montre le processus d'observation. Dans un ou plusieurs centres de données, la transaction ne nécessitait qu'un aller-retour pour obtenir un consensus, et si des nœuds étaient hors ligne, l'action se produirait toujours si au moins un quorum de répliques était disponible.

C'est exactement comme ça que Cassandra aime travailler, mais nous venons d'améliorer notre jeu avec une transaction disponible dans le monde entier.

Et après

Accord et tout le travail qui l'accompagne sont toujours en cours et devraient être inclus dans la prochaine version de Cassandra. Comme tout est en open source, ceux d'entre vous qui ne peuvent pas attendre peuvent cloner une copie de la branche cep-15-accord à partir du référentiel Cassandra et créer votre propre copie.

Pour le reste d'entre vous, à mesure que nous nous rapprochons de la date de sortie, nous aurons des versions disponibles que vous pourrez utiliser et tester. Cela changera la donne pour Cassandra, et je suis sûr que vous voudrez le voir par vous-même.

Je suis très intéressé par les commentaires de la communauté sur les cas d'utilisation que vous trouverez avec une transaction disponible dans le monde entier fonctionnant à la vitesse et à la résilience que vous attendez de Cassandra. Est-il enfin temps d'abandonner ces dernières charges de travail de base de données relationnelle ?

Nous sommes également impatients d'entendre vos commentaires sur tous nos canaux, y compris Apache Software Foundation Slack ou la liste de diffusion du projet . Les fonctionnalités d'un projet open source évoluent constamment pour répondre aux besoins des utilisateurs. C'est pourquoi vous avez un rôle essentiel à jouer dans la conception d'Apache Cassandra pour l'avenir.

Et restez à l'écoute pour plus de cas d'utilisation et d'informations à mesure que nous développons cette nouvelle fonctionnalité passionnante. Vous pouvez vous attendre à ce qu'il y ait plusieurs discussions à ce sujet lors du sommet numérique Cassandra Forward qui se tiendra le 14 mars. Vous ne voudrez pas les manquer.

Par Patrick McFadin, DataStax

Patrick McFadin est co-auteur du livre d'O'Reilly "Managing Cloud Native Data on Kubernetes". Il travaille actuellement chez DataStax dans les relations avec les développeurs et en tant que contributeur au projet Apache Cassandra. Patrick a travaillé comme évangéliste en chef pour Apache Cassandra (il est également un nouveau committer Cassandra !) et comme consultant pour DataStax, où il a passé un bon moment à construire certains des plus grands déploiements en production.