Examen de YugaByte: Cassandra et Redis à l'échelle planétaire

Au cours de mes décennies en tant que développeur d'applications de bases de données, je n'aurais jamais imaginé dans mes rêves les plus fous que j'aurais un jour accès à une base de données transactionnelle, à l'échelle planétaire et distribuée, et encore moins que je comparerais beaucoup d'entre elles. Mais avec Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise et, plus récemment, YugaByte DB, tous disponibles en production, ce rêve unique est désormais bien réel.

De manière générale, Google Cloud Spanner offre une base de données SQL évolutive, distribuée et fortement cohérente en tant que service qui peut gérer environ 2000 écritures par seconde et 10000 lectures par seconde, par nœud, avec une latence médiane d'environ cinq millisecondes. Pour accélérer les lectures qui n'ont pas besoin de données absolument à jour, vous pouvez demander à Spanner des lectures obsolètes, car il prend en charge les requêtes de voyage dans le temps. Spanner utilise un dialecte de Google SQL et ne s'exécute que sur Google Cloud Platform.

CockroachDB est une base de données SQL open source de type Spanner qui prend en charge le protocole filaire PostgreSQL et le dialecte SQL PostgreSQL. CockroachDB est construit sur RocksDB, un magasin de valeurs-clés transactionnel et cohérent open-source. Comme Spanner, il prend en charge les requêtes de voyage dans le temps. CockroachDB peut s'exécuter sur n'importe quel cloud, dans des conteneurs Docker avec ou sans orchestration, ou sur des serveurs Linux ou des machines virtuelles. La version entreprise de CockroachDB ajoute le géo-partitionnement, le contrôle d'accès basé sur les rôles et la prise en charge.

Azure Cosmos DB est une base de données multimodèle répartie à l'échelle mondiale, partitionnée horizontalement en tant que service. Il propose quatre modèles de données (valeur-clé, famille de colonnes, document et graphique) et cinq niveaux de cohérence réglables (fort, obsolescence limitée, session, préfixe cohérent et éventuel). Il propose cinq ensembles d'API: SQL (dialecte), compatible MongoDB, compatible Azure Table, graph (Gremlin) et compatible Apache Cassandra. Il ne fonctionne que sur le cloud Microsoft Azure.

Neo4j est une base de données de graphes évolutive et survivante qui utilise le langage de requête Cypher. Vous pouvez installer sa version open source, sans cluster sur Windows, MacOS et Linux, dans des conteneurs Docker et dans des machines virtuelles. Neo4j Enterprise prend en charge la haute disponibilité et les clusters causaux; Les clusters causals permettent des clusters de réplicas en lecture mis à jour de manière asynchrone, afin de permettre des performances élevées pour les déploiements répartis géographiquement.

Entrez Yugabyte DB

YugaByte DB, le sujet de cette revue, est une base de données open-source, transactionnelle et haute performance pour les applications à l'échelle planétaire qui prend en charge trois ensembles d'API: YCQL, compatible avec Apache Cassandra Query Language (CQL); YEDIS, compatible avec Redis; et PostgreSQL (actuellement incomplet et en version bêta). YugaWare est la couche d'orchestration pour YugaByte DB Enterprise Edition. YugaWare accélère la création et la suppression de clusters distribués sur Amazon Web Services, Google Cloud Platform et (prévu au quatrième trimestre 2018) Microsoft Azure. YugaByte DB implémente le contrôle de concurrence multiversion (MVCC), mais ne prend pas encore en charge les requêtes de voyage dans le temps.

YugaByte DB est construit au-dessus d'un fork amélioré du magasin de valeurs-clés RocksDB. YugaByte DB 1.0 expédié en mai 2018.

Les algorithmes de consensus de cluster et la synchronisation d'horloge des nœuds sont deux des technologies clés utilisées pour rendre les bases de données transactionnelles distribuées cohérentes et rapides. Google Cloud Spanner et Azure Cosmos DB utilisent tous deux l'algorithme de consensus Paxos proposé par Leslie Lamport. CockroachDB et YugaByte DB utilisent l'algorithme de consensus Raft proposé par Diego Ongaro et John Ousterhout.

Google Cloud Spanner utilise l'API TrueTime propriétaire de Google, basée sur le GPS et les horloges atomiques. Azure Cosmos DB, CockroachDB et YugaByte DB utilisent des horodatages d'horloge logique hybride (HLC) et la synchronisation d'horloge NTP (Network Time Protocol).

Objectifs de conception YugaByte

Les fondateurs de YugaByte - Kannan Muthukkaruppan, Karthik Ranganathan et Mikhail Bautin - étaient des committers Apache HBase, des premiers ingénieurs sur Apache Cassandra et les constructeurs de la plate-forme NoSQL de Facebook (propulsée par Apache HBase). Leur objectif pour YugaByte DB était un serveur de base de données distribué, philosophiquement entre Azure Cosmos DB et Google Cloud Spanner; c'est-à-dire qu'ils voulaient combiner les attributs multimodèle et haute performance de Cosmos DB avec les transactions ACID et la cohérence globale de Spanner. Une autre façon de décrire leur objectif est qu'ils voulaient que YugaByte DB soit à la fois transactionnel, haute performance et à l'échelle de la planète.

Ils ont divisé le processus en cinq étapes, dont chacune a pris environ six mois à construire. La première étape a consisté à créer une version fortement cohérente de RocksDB, un magasin clé-valeur haute performance écrit en C ++, en ajoutant le protocole de consensus Raft, le partitionnement et l'équilibrage de charge, et en supprimant la journalisation des transactions, les sauvegardes ponctuelles, et la récupération, qui devait être mise en œuvre dans une couche supérieure.

L'étape suivante consistait à créer un moteur de stockage clé-à-document structuré en journaux, en ajoutant des types non primitifs et imbriqués, tels que des lignes, des cartes, des collections et JSON. Ensuite, ils ont ajouté une couche d'API enfichable, comme Azure Cosmos DB, implémentant des API compatibles Cassandra et compatibles Redis, et reportant une API SQL compatible PostgreSQL à une étape ultérieure. Puis vinrent les langages de requête étendus.

YugaByte Cloud Query Language (YCQL) étend l'API Cassandra avec la prise en charge des transactions distribuées, des index secondaires fortement cohérents et JSON. YugaByte Dictionary Service (YEDIS) est une API compatible Redis avec des ajouts de persistance intégrée, de partitionnement automatique et d'évolutivité linéaire. YEDIS permet en option des lectures cohérentes dans le temps et à faible latence à partir du centre de données le plus proche, tandis que des opérations d'écriture fortes maintiennent la cohérence globale. YEDIS comprend également un nouveau type de données de série chronologique.

Enfin, avec la version 1.0, YugaByte DB Enterprise ajoute une couche pour orchestrer, sécuriser et surveiller les déploiements de niveau production dans plusieurs régions et plusieurs clouds, et stocke les sauvegardes distribuées sur un point de terminaison configurable tel qu'Amazon S3. Le support de PostgreSQL reste incomplet et à un niveau de test bêta.

Transactions ACID distribuées 

Au risque de simplifier à l'extrême le processus, permettez-moi d'essayer de résumer la façon dont YugaByte effectue les transactions ACID distribuées. ACID (qui signifie atomicité, cohérence, isolation et durabilité) était auparavant considéré comme une propriété limitée aux bases de données SQL.

Supposons que vous soumettiez une requête YCQL contenant des mises à jour à l'intérieur d'une transaction, par exemple un débit et un crédit couplés qui doivent tous deux abandonner en cas d'échec afin de maintenir la cohérence d'une base de données financière. YugaByte DB accepte la transaction dans un gestionnaire de transactions sans état, dont l'un s'exécute sur chaque nœud du cluster. Le gestionnaire de transactions tente ensuite de planifier la transaction sur le serveur de tablette qui possède la plupart des données auxquelles la transaction accède, à des fins de performances.

Le gestionnaire de transactions ajoute une entrée de transaction avec un ID unique dans la table de statut de transaction. Ensuite, il écrit des enregistrements provisoires sur toutes les tablettes responsables des clés que la transaction tente de modifier. S'il y a des conflits, l'une des transactions en conflit est annulée.

Une fois que tous les enregistrements provisoires ont été écrits avec succès, le gestionnaire de transactions demande à la tablette de statut de transaction de remplacer tous les enregistrements provisoires par des enregistrements réguliers en utilisant l'horodatage de l'entrée «transaction validée» dans son journal de radeau. Enfin, la tablette d'état de la transaction envoie des demandes de nettoyage à chacune des tablettes ayant participé à la transaction.

Pour améliorer les performances, YugaByte met en cache de manière agressive les informations pour les transactions en cours, implémente des verrous à granularité fine et utilise des baux hybrides pour empêcher les clients de lire les valeurs obsolètes des anciens dirigeants. Les transactions ACID sur une seule ligne sont optimisées pour avoir de faibles latences en l'absence d'opération conflictuelle. Les transactions ACID distribuées préservent l'exactitude au détriment des latences plus élevées.

YCQL, YEDIS et PostgreSQL

YugaByte inclut une implémentation presque complète de CQL, ainsi que quelques extensions. Une énorme amélioration par rapport à Cassandra est que YugaByte est fortement cohérent, tandis que Cassandra est finalement cohérent. Les autres améliorations concernent les transactions distribuées, les index secondaires fortement cohérents et JSON. YugaByte surpasse Cassandra pour chaque opération, à l'exception des analyses à courte portée, au moins en partie en raison de sa forte cohérence, qui permet une seule lecture au lieu de la lecture de quorum nécessaire dans Cassandra.

Cassandra prend en charge quatre types de données primitifs non encore pris en charge dans YugaByte: date, heure, tuple et varint. YugaByte a également quelques restrictions sur les expressions. 

L'implémentation de Redis par YugaByte n'a pas le type de données de liste, mais ajoute un type de données de série chronologique. Il ajoute une persistance intégrée, un partage automatique et une évolutivité linéaire, ainsi que la possibilité de lire à partir du centre de données le plus proche pour une faible latence.

L'implémentation PostgreSQL de YugaByte n'est pas très avancée. À l'heure actuelle, il manque les instructions UPDATE et DELETE, les expressions, et l'instruction SELECT n'a pas de clause de jointure.

Installation et test de YugaByte

Vous pouvez installer la base de données open source YugaByte à partir du code source, des archives tar sur MacOS, Centos 7 et Ubuntu 16.04 ou version ultérieure, et à partir d'images Docker sur Docker ou Kubernetes. Vous pouvez ensuite créer des clusters et tester les trois API de requête et quelques exemples de générateurs de charge de travail.

J'ai choisi d'installer YugaByte DB Enterprise sur Google Cloud Platform. Bien qu'il y ait eu plus d'étapes manuelles à suivre que je ne l'aurais souhaité, j'ai pu effectuer mon installation et mes tests en un seul après-midi après avoir eu ma clé de licence Enterprise Edition.

Une fois que l'instance YugaWare s'exécutait sur une instance à quatre processeurs dans Google Cloud, j'ai configuré Google Cloud Platform en tant que fournisseur de cloud pour mon cluster de base de données.

Ensuite, j'ai créé un cluster à trois nœuds d'instances à huit processeurs dans la région USA Est.

J'ai exécuté des tests de charge en utilisant à la fois les API CQL et Redis.

J'ai pu interroger les données CQL et Redis à partir de la ligne de commande.

J'ai également créé un cluster à trois nœuds dans différentes régions du monde (ci-dessous). Cela prenait plus de temps à créer (environ 45 minutes) et avait une latence d'écriture beaucoup plus élevée, comme prévu. Vous ne pouvez pas contourner la vitesse de la lumière, malheureusement.

Coûts YugaByte

Le prix d'une licence YugaByte DB Enterprise Edition à trois nœuds commence à 40 000 $ par an. En plus de cela, vous devez prendre en compte le coût des serveurs. Pour un cluster à trois nœuds sur Google Cloud Platform utilisant des instances de VM à huit processeurs, ce coût est compris entre 800 et 900 USD par mois, plus le trafic réseau, peut-être 11 000 USD par an.

Mes propres coûts pour un après-midi de tests étaient de 0,38 USD pour les instances et de 0,01 USD pour la sortie inter-zone. La suppression des clusters de bases de données de l'interface YugaByte DB Enterprise était facile, et une fois que j'ai arrêté l'instance de VM exécutant l'interface d'administration et d'orchestration, elle ne représentait plus de frais importants.

Plus rapide, mieux, distribué

Dans l'ensemble, YugaByte DB a fonctionné comme annoncé. À ce stade de son développement, il est utile en tant que Redis et Cassandra plus rapide, mieux distribué. Cela devrait finalement être un meilleur PostgreSQL, bien que, d'après mon expérience, cela prenne beaucoup de temps (des années plutôt que des mois), surtout lorsque vous en arrivez à essayer d'ajuster les jointures relationnelles.

YugaByte DB n'est pas encore en concurrence avec Google Cloud Spanner, CockroachDB ou l'interface SQL d'Azure Cosmos DB faute d'une interface SQL étoffée. Il n'est pas encore en concurrence avec Neo4j ou l'interface graphique de Cosmos DB faute de support de base de données graphique. Il est en concurrence avec Redis, Cassandra et l'interface compatible Cassandra avec Cosmos DB.

Devriez-vous essayer YugaByte DB vous-même? Si vous avez besoin d'une version distribuée de Redis ou Cassandra, ou si vous devez remplacer MongoDB pour un scénario distribué à l'échelle mondiale, alors oui. YugaByte DB pourrait également être utilisé pour standardiser sur une seule base de données à des fins multiples, telles que la combinaison d'une base de données Cassandra avec la mise en cache Redis, comme l'a fait Narvar, client de YugaByte. YugaByte DB ajoute également des index secondaires hautes performances et un type JSON à Cassandra, augmentant son utilité en tant que base de données transactionnelle.

Que vous souhaitiez la version open source ou entreprise de YugaByte DB dépend de votre budget. En gros, si vous êtes une startup, vous voulez probablement la version open source. Si vous êtes une entreprise mondiale établie avec de nombreuses applications de base de données transactionnelles, en particulier si vous devez souvent augmenter et réduire les clusters, vous pouvez bénéficier des fonctionnalités supplémentaires de la version entreprise.