Recensione YugaByte: Cassandra e Redis su scala planetaria

Durante i miei decenni come sviluppatore di applicazioni di database, non avrei mai immaginato nei miei sogni più sfrenati che avrei mai avuto accesso a un database transazionale, su scala planetaria, distribuito, tanto meno che avrei confrontato molti di loro. Ma con Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise e più recentemente YugaByte DB tutti disponibili in produzione, quel sogno irrealizzabile una tantum è ora abbastanza reale.

In termini generali, Google Cloud Spanner offre un database SQL come servizio scalabile, distribuito e fortemente coerente in grado di gestire circa 2.000 scritture al secondo e 10.000 letture al secondo, per nodo, con una latenza mediana di circa cinque millisecondi. Per accelerare le letture che non necessitano di dati assolutamente aggiornati, puoi chiedere a Spanner letture obsolete, poiché supporta le query sui viaggi nel tempo. Spanner utilizza un dialetto di Google SQL e viene eseguito solo su Google Cloud Platform.

CockroachDB è un database SQL open source simile a Spanner che supporta il protocollo cablato PostgreSQL e il dialetto SQL PostgreSQL. CockroachDB è costruito su RocksDB, un archivio chiave-valore transazionale e coerente open source. Come Spanner, supporta le query sui viaggi nel tempo. CockroachDB può essere eseguito su qualsiasi cloud, in container Docker con o senza orchestrazione o su server Linux o VM. La versione aziendale di CockroachDB aggiunge il partizionamento geografico, il controllo degli accessi basato sui ruoli e il supporto.

Azure Cosmos DB è un database multimodello distribuito a livello globale, partizionato orizzontalmente come servizio. Offre quattro modelli di dati (valore-chiave, famiglia di colonne, documento e grafico) e cinque livelli di coerenza sintonizzabili (forte, obsoleto delimitato, sessione, prefisso coerente ed eventuale). Offre cinque set di API: SQL (dialetto), compatibile con MongoDB, compatibile con Azure Table, graph (Gremlin) e compatibile con Apache Cassandra. Funziona solo sul cloud Microsoft Azure.

Neo4j è un database a grafo scalabile e resistente che utilizza il linguaggio di query Cypher. Puoi installare la sua versione open source, non in cluster su Windows, MacOS e Linux, nei contenitori Docker e nelle VM. Neo4j Enterprise supporta alta disponibilità e cluster causali; i cluster causali consentono cluster aggiornati in modo asincrono di repliche di lettura, per consentire prestazioni elevate per distribuzioni distribuite geograficamente.

Immettere Yugabyte DB

YugaByte DB, oggetto di questa recensione, è un database open source, transazionale e ad alte prestazioni per applicazioni su scala planetaria che supporta tre set di API: YCQL, compatibile con Apache Cassandra Query Language (CQL); YEDIS, compatibile con Redis; e PostgreSQL (attualmente incompleto e in beta). YugaWare è il livello di orchestrazione per YugaByte DB Enterprise Edition. YugaWare semplifica la creazione e lo smantellamento di cluster distribuiti su Amazon Web Services, Google Cloud Platform e (previsto per il quarto trimestre 2018) Microsoft Azure. YugaByte DB implementa il controllo della concorrenza multiversione (MVCC), ma non supporta ancora le query sui viaggi nel tempo.

YugaByte DB è costruito su un fork migliorato del key-value store RocksDB. YugaByte DB 1.0 è stato spedito a maggio 2018.

Due delle tecnologie chiave utilizzate per rendere coerenti e veloci i database transazionali distribuiti sono gli algoritmi di consenso del cluster e la sincronizzazione dell'orologio dei nodi. Google Cloud Spanner e Azure Cosmos DB utilizzano entrambi l'algoritmo di consenso Paxos proposto da Leslie Lamport. CockroachDB e YugaByte DB utilizzano l'algoritmo di consenso Raft proposto da Diego Ongaro e John Ousterhout.

Google Cloud Spanner utilizza l'API TrueTime proprietaria di Google, basata su GPS e orologi atomici. Azure Cosmos DB, CockroachDB e YugaByte DB usano i timestamp dell'orologio logico ibrido (HLC) e la sincronizzazione dell'orologio NTP (Network Time Protocol).

Obiettivi di progettazione di YugaByte

I fondatori di YugaByte - Kannan Muthukkaruppan, Karthik Ranganathan e Mikhail Bautin - erano i committer di Apache HBase, i primi ingegneri di Apache Cassandra e i costruttori della piattaforma NoSQL di Facebook (alimentata da Apache HBase). Il loro obiettivo per YugaByte DB era un server di database distribuito filosoficamente tra Azure Cosmos DB e Google Cloud Spanner; ovvero, volevano combinare gli attributi multimodello e ad alte prestazioni di Cosmos DB con le transazioni ACID e la coerenza globale di Spanner. Un altro modo per descrivere il loro obiettivo è che volevano che YugaByte DB fosse transazionale, ad alte prestazioni e su scala planetaria, tutto in una volta.

Hanno suddiviso il processo in cinque fasi, ciascuna delle quali ha richiesto circa sei mesi per la costruzione. Il primo passo è stato quello di creare una versione fortemente coerente di RocksDB, un archivio di valori-chiave ad alte prestazioni scritto in C ++, aggiungendo il protocollo di consenso Raft, lo sharding e il bilanciamento del carico e rimuovendo la registrazione delle transazioni, i backup point-in-time, e recupero, che doveva essere implementato in un livello superiore.

Il passaggio successivo è stato quello di creare un motore di archiviazione da chiave a documento strutturato in log, aggiungendo tipi non primitivi e nidificati, come righe, mappe, raccolte e JSON. Quindi hanno aggiunto un livello API collegabile, come Azure Cosmos DB, implementando API compatibili con Cassandra e Redis e rimandando un'API SQL compatibile con PostgreSQL a una fase successiva. Poi sono arrivati ​​i linguaggi di query estesi.

YugaByte Cloud Query Language (YCQL) estende l'API Cassandra con il supporto per transazioni distribuite, indici secondari fortemente coerenti e JSON. YugaByte Dictionary Service (YEDIS) è un'API compatibile con Redis con aggiunte di persistenza incorporata, partizionamento automatico e scalabilità lineare. Facoltativamente, YEDIS consente letture coerenti con la timeline ea bassa latenza dal data center più vicino, mentre le operazioni di scrittura forte mantengono la coerenza globale. YEDIS include anche un nuovo tipo di dati di serie temporali.

Infine, con la versione 1.0, YugaByte DB Enterprise aggiunge un livello per orchestrare, proteggere e monitorare le distribuzioni di livello di produzione su più regioni e più cloud e archivia i backup distribuiti su un endpoint configurabile come Amazon S3. Il supporto di PostgreSQL rimane incompleto ea livello di beta test.

Transazioni ACID distribuite 

A rischio di semplificare completamente il processo, vorrei provare a riassumere il modo in cui YugaByte esegue le transazioni ACID distribuite. ACID (che sta per atomicità, consistenza, isolamento e durata) era considerato una proprietà limitata ai database SQL.

Supponiamo di inviare una query YCQL contenente aggiornamenti all'interno di una transazione, ad esempio un debito e un credito accoppiati che devono essere interrotti entrambi se uno fallisce per mantenere la coerenza di un database finanziario. YugaByte DB accetta la transazione in un gestore di transazioni senza stato, uno dei quali viene eseguito su ogni nodo del cluster. Il gestore delle transazioni tenta quindi di pianificare la transazione sul server tablet che possiede la maggior parte dei dati a cui la transazione accede, ai fini delle prestazioni.

Il gestore delle transazioni aggiunge una voce di transazione con un ID univoco nella tabella dello stato della transazione. Quindi scrive i record provvisori su tutti i tablet responsabili delle chiavi che la transazione sta tentando di modificare. In caso di conflitti, viene eseguito il rollback di una delle transazioni in conflitto.

Una volta che tutti i record provvisori sono stati scritti correttamente, il gestore delle transazioni chiede al tablet dello stato della transazione di sostituire tutti i record provvisori con record regolari utilizzando il timestamp della voce "transazione confermata" nel suo registro Raft. Infine, il tablet dello stato della transazione invia richieste di pulizia a ciascuno dei tablet che hanno partecipato alla transazione.

Per migliorare le prestazioni, YugaByte memorizza nella cache in modo aggressivo le informazioni per le transazioni in corso, implementa blocchi a grana fine e utilizza i leasing dei leader del tempo ibridi per impedire ai clienti di leggere i valori non aggiornati dai vecchi leader. Le transazioni ACID su riga singola sono ottimizzate per avere basse latenze quando non ci sono operazioni in conflitto. Le transazioni ACID distribuite preservano la correttezza a scapito di latenze più elevate.

YCQL, YEDIS e PostgreSQL

YugaByte include un'implementazione quasi completa di CQL, oltre ad alcune estensioni. Un enorme miglioramento rispetto a Cassandra è che YugaByte è fortemente coerente, mentre Cassandra è alla fine coerente. Gli altri miglioramenti riguardano transazioni distribuite, indici secondari fortemente coerenti e JSON. YugaByte supera Cassandra per ogni operazione ad eccezione delle scansioni a corto raggio, almeno in parte a causa della sua forte coerenza, che consente una singola lettura invece del quorum necessario in Cassandra.

Cassandra supporta quattro tipi di dati primitivi non ancora supportati in YugaByte: data, ora, tupla e varint. YugaByte ha anche alcune restrizioni sulle espressioni. 

L'implementazione di Redis da parte di YugaByte non ha il tipo di dati elenco, ma aggiunge un tipo di dati serie temporale. Aggiunge persistenza integrata, auto-sharding e scalabilità lineare, oltre alla capacità di leggere dal data center più vicino per una bassa latenza.

L'implementazione PostgreSQL di YugaByte non è molto lontana. Al momento mancano le istruzioni, le espressioni UPDATE e DELETE e l'istruzione SELECT non ha una clausola join.

Installazione e test di YugaByte

Puoi installare il DB YugaByte open source dal codice sorgente, dai tarball su MacOS, Centos 7 e Ubuntu 16.04 o versioni successive e dalle immagini Docker su Docker o Kubernetes. È quindi possibile creare cluster e testare le tre API di query e alcuni generatori di carichi di lavoro di esempio.

Ho scelto di installare YugaByte DB Enterprise su Google Cloud Platform. Sebbene ci fossero più passaggi manuali da eseguire di quanto avrei voluto, sono stato in grado di eseguire l'installazione e i test in un solo pomeriggio dopo aver ottenuto la mia chiave di licenza Enterprise Edition.

Una volta che l'istanza YugaWare era in esecuzione su un'istanza a quattro CPU in Google Cloud, ho configurato Google Cloud Platform come provider di cloud per il mio cluster di database.

Quindi ho creato un cluster a tre nodi di istanze a otto CPU nella regione Stati Uniti orientali.

Ho eseguito test di carico utilizzando entrambe le API CQL e Redis.

Sono stato in grado di interrogare sia i dati CQL che Redis dalla riga di comando.

Ho anche creato un cluster a tre nodi in diverse regioni sparse in tutto il mondo (sotto). La creazione ha richiesto più tempo (circa 45 minuti) e ha avuto una latenza di scrittura molto più elevata, come previsto. Sfortunatamente non puoi aggirare la velocità della luce.

YugaByte costa

Il prezzo di una licenza YugaByte DB Enterprise Edition a tre nodi parte da $ 40.000 all'anno. Inoltre, è necessario tenere conto del costo dei server. Per un cluster a tre nodi su Google Cloud Platform che utilizza istanze VM a otto CPU, il costo è compreso tra $ 800 e $ 900 al mese più il traffico di rete, forse $ 11.000 all'anno.

I miei costi per un pomeriggio di test sono stati di $ 0,38 per le istanze e di $ 0,01 per l'uscita tra zone. L'eliminazione dei cluster di database dall'interfaccia YugaByte DB Enterprise è stata facile e, una volta arrestata l'istanza VM che esegue l'interfaccia di amministrazione e orchestrazione, non ha più accumulato addebiti significativi.

Più veloce, migliore, distribuito

Nel complesso, YugaByte DB si è comportato come pubblicizzato. A questo punto del suo sviluppo è utile come Redis e Cassandra più veloci, meglio distribuiti. Alla fine dovrebbe anche essere un PostgreSQL migliore, anche se nella mia esperienza ci vuole molto tempo (anni anziché mesi), specialmente quando si arriva al punto di provare a mettere a punto i join relazionali.

YugaByte DB non è ancora in concorrenza con Google Cloud Spanner, CockroachDB o l'interfaccia SQL per Azure Cosmos DB per mancanza di un'interfaccia SQL completa. Non è ancora in concorrenza con Neo4j o l'interfaccia grafica di Cosmos DB per mancanza di supporto per il database grafico. È in concorrenza con Redis, Cassandra e l'interfaccia compatibile con Cassandra per Cosmos DB.

Dovresti provare YugaByte DB da solo? Se hai bisogno di una versione distribuita di Redis o Cassandra, oppure devi sostituire MongoDB per uno scenario distribuito a livello globale, allora sì. YugaByte DB potrebbe anche essere utilizzato per standardizzare su un singolo database per molteplici scopi, come la combinazione di un database Cassandra con la memorizzazione nella cache Redis, come ha fatto il cliente YugaByte Narvar. YugaByte DB aggiunge anche indici secondari ad alte prestazioni e un tipo JSON a Cassandra, aumentando la sua utilità come database transazionale.

Se desideri la versione open-source o enterprise di YugaByte DB dipende dal tuo budget. In generale, se sei una startup, probabilmente vorrai la versione open source. Se sei un'azienda globale affermata con molte applicazioni di database transazionali, soprattutto se devi ridimensionare i cluster su e giù spesso, potresti trarre vantaggio dalle funzionalità aggiuntive nella versione aziendale.