Bigtable per gli utenti di Cassandra

Questo documento è rivolto agli sviluppatori di software e agli amministratori di database che vogliono eseguire la migrazione di applicazioni esistenti o progettare nuove applicazioni da utilizzare con Bigtable come datastore. Questo documento applica le tue conoscenze di Apache Cassandra all'utilizzo di Cloud Bigtable.

Bigtable e Cassandra sono database distribuiti. Implementano archiviazione di coppie chiave-valore multidimensionali in grado di supportare decine di migliaia di query al secondo (QPS), archiviazione che scala fino a petabyte di dati e tolleranza per i guasti dei nodi.

Sebbene le funzionalità di questi database siano simili a un livello generale, le relative architetture sottostanti e i dettagli di interazione differiscono in modi importanti per la comprensione. Questo documento evidenzia le somiglianze e le differenze tra i due sistemi di database.

Come utilizzare questo documento

Non è necessario leggere questo documento dall'inizio alla fine. Sebbene questo documento fornisca un confronto tra i due database, puoi anche concentrarti sugli argomenti applicabili al tuo caso d'uso o ai tuoi interessi.

Confrontare due database maturi non è un compito semplice. Per raggiungere questo obiettivo, il documento svolge le seguenti operazioni:

• Confronta la terminologia, che può differire tra i due database.
• Fornisce una panoramica dei due sistemi di database.
• Osserva come ogni database gestisce la modellazione dei dati per comprendere le diverse considerazioni sulla progettazione.
• Confronta il percorso seguito dai dati durante le operazioni di scrittura e lettura.
• Esamina il layout dei dati fisici per comprendere gli aspetti dell'architettura del database.
• Descrive come configurare la replica geografica per soddisfare i requisiti e come affrontare il dimensionamento del cluster.
• Esamina i dettagli relativi a gestione, monitoraggio e sicurezza dei cluster.

Confronto della terminologia

Sebbene molti dei concetti utilizzati in Bigtable e Cassandra siano simili, ogni database presenta convenzioni di denominazione leggermente diverse e differenze sottili.

Uno degli elementi fondamentali di entrambi i database è la tabella delle stringhe ordinate (SSTable). In entrambe le architetture, le tabelle SSC vengono create per rendere persistenti i dati utilizzati per rispondere alle query di lettura.

In un post del blog (2012), Ilya Grigorik scrive quanto segue: "Una SSTable è una semplice astrazione per archiviare in modo efficiente un numero elevato di coppie chiave/valore durante l'ottimizzazione per carichi di lavoro di lettura/scrittura ad alta velocità effettiva."

La tabella seguente illustra e descrive i concetti condivisi e la terminologia corrispondente utilizzata da ciascun prodotto:

Cassandra	Bigtable
chiave primaria: un valore unico o multi-campo univoco che determina il posizionamento e l'ordine dei dati. partition key: un valore a campo singolo o multi-campo che determina il posizionamento dei dati con hash coerente. colonna clustering: un valore a campo singolo o multicampo che determina l'ordinamento basato su dati lexicografici all'interno di una partizione.	chiave di riga: una singola stringa di byte che determina il posizionamento dei dati in base a un ordinamento specifico. Le chiavi composti vengono imitate unendo i dati di più colonne utilizzando un delimitatore comune, ad esempio i simboli di cancelletto (#) o percentuale (%).
node: una macchina responsabile della lettura e della scrittura di dati associati a una serie di intervalli hash di partizioni chiave principali. In Cassandra, i dati vengono archiviati nell'archiviazione a livello di blocco collegata al server nodo.	node: una risorsa di calcolo virtuale responsabile della lettura e della scrittura dei dati associati a una serie di intervalli di chiavi di riga. In Bigtable, i dati non vengono posizionati insieme ai nodi di computing. ma viene archiviato in Colossus, il file system distribuito di Google. Ai nodi viene data la responsabilità temporanea della gestione di vari intervalli di dati in base al carico delle operazioni e all'integrità di altri nodi nel cluster.
data center: simile a un cluster Bigtable, ad eccezione di alcuni aspetti della strategia di topologia e replica sono configurabili in Cassandra. rack: un raggruppamento di nodi in un data center che influenza il posizionamento delle repliche.	cluster: un gruppo di nodi nella stessa zona geografica di Google Cloud, in coordine per problemi di latenza e replica.
cluster: un deployment di Cassandra costituito da una raccolta di data center.	instance: un gruppo di cluster Bigtable in diverse zone o aree geografiche Google Cloud tra cui si verificano la replica e il routing delle connessioni.
vnode: un intervallo fisso di valori hash assegnati a un nodo fisico specifico. I dati in un vnode vengono archiviati fisicamente sul nodo Cassandra in una serie di SSTables.	tablet: una tabella SSTable contenente tutti i dati per un intervallo contiguo di chiavi riga ordinate in modo conciso. I tablet non vengono archiviati sui nodi di Bigtable, ma sono archiviati in una serie di SSTables su Colossus.
fattore di replica: il numero di repliche di un vnode che vengono mantenute su tutti i nodi del data center. Il fattore di replica viene configurato in modo indipendente per ogni data center.	replica: il processo di replica dei dati archiviati in Bigtable in tutti i cluster dell'istanza. La replica all'interno di un cluster di zona viene gestita dal livello di archiviazione Colossus.
tabella (in precedenza famiglia di colonne): un'organizzazione logica di valori indicizzati dalla chiave primaria univoca.	tabella: un'organizzazione logica di valori indicizzati dalla chiave di riga univoca.
keyspace: uno spazio dei nomi di tabella logica che definisce il fattore di replica per le tabelle che contiene.	Non applicabile. Bigtable gestisce i problemi degli spazi chiave in modo trasparente.
Non applicabile	qualificatore colonna: un'etichetta per un valore archiviato in una tabella indicizzata dalla chiave di riga univoca.
Non applicabile	famiglia di colonne: uno spazio dei nomi specificato dall'utente che raggruppa i qualificatori di colonna per operazioni di lettura e scrittura più efficienti.
colonna: l'etichetta di un valore archiviato in una tabella indicizzata dalla chiave primaria univoca.	colonna: l'etichetta di un valore archiviato in una tabella indicizzata dalla chiave di riga univoca. Il nome della colonna viene creato combinando la famiglia di colonne e il qualificatore di colonna.
cella: un valore di timestamp in una tabella associato all'intersezione di una chiave primaria con la colonna.	cella: un valore di timestamp in una tabella associato all'intersezione di una chiave di riga con il nome della colonna. È possibile archiviare e recuperare più versioni con timestamp per ogni cella.
criterio del bilanciamento del carico: un criterio che configuri nella logica dell'applicazione per instradare le operazioni a un nodo appropriato nel cluster. Il criterio tiene conto degli intervalli di token dei nodi e della topologia dei data center.	profilo applicazione: impostazioni che indicano a Bigtable come instradare una chiamata API client al cluster appropriato nell'istanza. Puoi anche utilizzare il profilo dell'applicazione come tag per segmentare le metriche. Puoi configurare il profilo dell'applicazione nel servizio.
CQL: Cassandra Query Language, un linguaggio come SQL utilizzato per la creazione di tabelle, modifiche allo schema, mutazioni di righe e query.	API Bigtable: le librerie client e le API gRPC utilizzate per la creazione di istanze e cluster, la creazione di tabelle di tabelle e colonne, le mutazioni di righe e le query.

Panoramiche sui prodotti

Le sezioni seguenti forniscono una panoramica della filosofia di progettazione e degli attributi chiave di Bigtable e Cassandra.

Bigtable

Bigtable offre molte delle funzionalità principali descritte nel documento Bigtable: A Distributed Storage System for Structured Data. Bigtable separa i nodi di computing, che servono le richieste del client, dalla gestione dello spazio di archiviazione sottostante. I dati sono archiviati su Colossus. Il livello di archiviazione replica automaticamente i dati per garantire una durabilità superiore ai livelli forniti dalla replica a tre vie standard Hadoop Distributed File System (HDFS).

Questa architettura fornisce operazioni di lettura e scrittura coerenti all'interno di un cluster, consente lo scale up e lo scale down senza alcun costo di ridistribuzione dello spazio di archiviazione e può bilanciare i carichi di lavoro senza modificare il cluster o lo schema. Se un nodo di elaborazione dati è compromesso, il servizio Bigtable lo sostituisce in modo trasparente. Bigtable supporta anche la replica asincrona tra i cluster distribuiti geograficamente in topologie di massimo quattro cluster in diverse zone o aree geografiche di Google Cloud in tutto il mondo.

Oltre alle librerie client e gRPC per vari linguaggi di programmazione, Bigtable mantiene la compatibilità con la libreria client Java open source Apache HBase, un'implementazione alternativa del motore di database open source di Bigtable.

Il seguente diagramma mostra in che modo Bigtable separa fisicamente i nodi di elaborazione dal livello di archiviazione:

Nel diagramma precedente, il nodo di elaborazione centrale è responsabile solo della pubblicazione delle richieste di dati per il set di dati C nel livello di archiviazione. Se Bigtable specifica che il ribilanciamento dell'assegnazione dell'intervallo è necessario per un set di dati, gli intervalli di dati per un nodo di elaborazione sono semplici da modificare perché il livello di archiviazione è separato dal livello di elaborazione.

Il seguente diagramma mostra, in termini semplificati, un ribilanciamento dell'intervallo di chiavi e un ridimensionamento del cluster:

L'immagine Rebalancing illustra lo stato del cluster Bigtable dopo che il nodo di elaborazione all'estrema sinistra riceve un numero maggiore di richieste per il set di dati A. Dopo il ribilanciamento, il nodo centrale, invece del nodo più a sinistra, è responsabile della pubblicazione delle richieste di dati per il set di dati B. Il nodo più a sinistra continua a gestire le richieste per il set di dati A.

Bigtable può riordinare gli intervalli chiave di riga per bilanciare gli intervalli di set di dati su un numero maggiore di nodi di elaborazione disponibili. L'immagine Ridimensionamento mostra lo stato del cluster Bigtable dopo aver aggiunto un nodo.

Cassandra

Apache Cassandra è un database open source in parte influenzato dai concetti del white paper Bigtable. Utilizza un'architettura di nodi distribuiti, in cui l'archiviazione è coposizionata con i server che rispondono alle operazioni di dati. Una serie di nodi virtuali (vnodi) viene assegnata in modo casuale a ciascun server per gestire una parte dello spazio chiave del cluster.

I dati vengono archiviati nei nodi in base alla chiave di partizione. In genere, viene utilizzata una funzione hash coerente per generare un token per determinare il posizionamento dei dati. Come con Bigtable, puoi utilizzare un partizionatore per la conservazione degli ordini per la generazione dei token e, di conseguenza, anche per il posizionamento dei dati. Tuttavia, la documentazione di Cassandra sconsiglia questo approccio perché è probabile che il cluster non venga bilanciato, una condizione che è difficile da risolvere. Per questo motivo, questo documento presume che tu utilizzi una strategia di hashing coerente per generare token che generano una distribuzione dei dati tra nodi.

Cassandra offre tolleranza di errore tramite livelli di disponibilità correlati al livello di coerenza regolabile, consentendo a un cluster di gestire i client mentre uno o più nodi sono compromessi. Puoi definire la replica geografica tramite una strategia di topologia di replica dei dati configurabile.

Specifica un livello di coerenza per ogni operazione. L'impostazione tipica è QUORUM (o LOCAL_QUORUM in alcune topologie di più data center). Questa impostazione del livello di coerenza richiede che la maggioranza dei nodi di replica risponda al nodo coordinatore affinché l'operazione venga considerata riuscita. Il fattore di replica, configurato per ogni spazio chiave, determina il numero di repliche di dati archiviate in ogni data center nel cluster. Ad esempio, è normale utilizzare un valore del fattore di replica pari a 3 per garantire un equilibrio pratico tra durabilità e volume di archiviazione.

Il seguente diagramma mostra in termini semplificati un cluster di sei nodi con l'intervallo di chiavi di ogni nodo diviso in cinque nodi. In pratica, si possono avere più nodi e probabilmente ne avranno più.

Nel diagramma precedente puoi vedere il percorso di un'operazione di scrittura, con un livello di coerenza QUORUM, che ha origine da un'applicazione o da un servizio client (client). Ai fini di questo diagramma, gli intervalli chiave sono visualizzati come intervalli alfabetici. In realtà, i token prodotti da un hash della chiave primaria sono numeri interi firmati molto grandi.

In questo esempio, l'hash della chiave è M e i nodi di M si trovano sui nodi 2, 4 e 6. Il coordinatore deve contattare ogni nodo in cui sono archiviati in locale gli intervalli hash chiave, in modo che la scrittura possa essere elaborata. Poiché il livello di coerenza è QUORUM, due repliche (la maggior parte) devono rispondere al nodo del coordinatore prima che il client riceva una notifica che indica che la scrittura è stata completata.

Nota: se utilizzi un criterio di bilanciamento del carico che riconosce i token, viene scelta una replica vnode come nodo coordinatore, eliminando un hop di rete.

A differenza di Bigtable, lo spostamento o la modifica di intervalli di chiavi in Cesandra richiede la copia fisica dei dati da un nodo all'altro. Se un nodo è sovraccarico con richieste per un determinato intervallo di hash del token, aggiungere l'elaborazione per quell'intervallo di token non è facile come in Cassandra come in Bigtable.

Replica e coerenza geografica

Bigtable e Cassandra gestiscono la replica e la coerenza geografica (nota anche come multi-regione) in modo diverso. Un cluster Cassandra è composto da nodi di elaborazione raggruppati in rack, che vengono raggruppati nei data center. Cassandra utilizza una strategia di topologia di rete che configuri per determinare la modalità di distribuzione delle repliche dei nodi tra gli host in un data center. Questa strategia rivela le radici di Cassandra come un database originariamente di cui è stato eseguito il deployment in data center fisici on-premise. Questa configurazione specifica anche il fattore di replica per ogni data center nel cluster.

Cassandra usa le configurazioni di data center e rack per migliorare la tolleranza di errore delle repliche dei dati. Durante le operazioni di lettura e scrittura, la topologia determina i nodi dei partecipanti necessari per garantire la coerenza. Devi configurare manualmente i nodi, i rack e i data center quando crei o estendi un cluster. In un ambiente cloud, un tipico deployment di Cassandra considera una zona cloud come un rack e una regione cloud come un data center.

Puoi utilizzare i controlli del quorum di Cassandra per regolare le garanzie di coerenza per ogni operazione di lettura o scrittura. I livelli di forza della coerenza finale possono variare, incluse le opzioni che richiedono un singolo nodo di replica (ONE), la maggioranza dei nodi di replica di un singolo data center (LOCAL_QUORUM) o la maggior parte di tutti i nodi di replica in tutti i data center (QUORUM).

In Bigtable, i cluster sono risorse di zona. Un'istanza Bigtable può contenere un singolo cluster o un gruppo fino a un massimo di quattro cluster replicati. Puoi posizionare i cluster di istanza in qualsiasi combinazione di zone in tutte le aree geografiche offerte da Google Cloud. Puoi aggiungere e rimuovere cluster da un'istanza con un impatto minimo sugli altri cluster nell'istanza.

In Bigtable, le scritture vengono eseguite (con coerenza di lettura/scrittura) su un singolo cluster e alla fine saranno coerenti negli altri cluster di istanze. Poiché le singole celle sono sottoposte a controllo delle versioni in base al timestamp, le scritture non vanno perse e ogni cluster pubblica le celle con i timestamp più recenti disponibili.

Il servizio espone lo stato della coerenza del cluster. L'API Cloud Bigtable fornisce un meccanismo per ottenere un token di coerenza a livello di tabella. Puoi utilizzare questo token per verificare se tutte le modifiche apportate alla tabella prima della creazione del token sono state replicate completamente.

Assistenza transazioni

Sebbene nessuno dei due database supporti transazioni multiriga complesse, ciascuna supporta alcune transazioni.

Cassandra ha un metodo di transazione leggera (LWT) che fornisce atomicità per gli aggiornamenti ai valori di colonna in una singola partizione. Cassandra ha anche la semantica e l'impostazione della semantica che completano l'operazione di lettura delle righe e il confronto dei valori prima che venga avviata una scrittura.

Bigtable supporta scritture a riga singola completamente coerenti all'interno di un cluster. Le transazioni su riga singola sono ulteriormente abilitate tramite le operazioni di lettura, modifica e scrittura, nonché di controllo e modifica. I profili di applicazione di routing multi-cluster non supportano le transazioni a riga singola.

Modello dati

Bigtable e Cassandra organizzano i dati in tabelle che supportano le ricerche e l'intervallo di scansioni utilizzando l'identificatore univoco della riga. Entrambi i sistemi sono classificati come archivi wide-colonne NoSQL.

In Cassandra devi utilizzare CQL per creare in anticipo lo schema della tabella completa, che include la definizione della chiave primaria insieme ai nomi delle colonne e ai relativi tipi. Le chiavi primarie in Cassandra sono valori composti unici composti da una chiave di partizione obbligatoria e da una chiave di cluster facoltativa. La chiave di partizione determina il posizionamento del nodo di una riga, mentre la chiave del cluster determina l'ordinamento in una partizione. Quando crei gli schemi, devi essere a conoscenza dei potenziali compromessi tra l'esecuzione di scansioni efficienti all'interno di una singola partizione e i costi di sistema associati alla gestione di partizioni di grandi dimensioni.

In Bigtable, devi solo creare la tabella e definire le famiglie di colonne in anticipo. Le colonne non vengono dichiarate durante la creazione delle tabelle, ma vengono create quando le chiamate API dell'applicazione aggiungono celle alle righe della tabella.

Le chiavi di riga sono disposte in ordine alfabetico attraverso il cluster Bigtable. I nodi all'interno di Bigtable bilanciano automaticamente la responsabilità nodale per gli intervalli delle chiavi, spesso definiti tablet e talvolta come split. Le chiavi di riga di Bigtable sono spesso costituite da diversi valori di campi che vengono collegati utilizzando un carattere separatore di uso comune scelto da te, ad esempio un segno di percentuale. Se separati, i singoli componenti della stringa sono analoghi ai campi di una chiave primaria Cassandra.

Progettazione della chiave di riga

In Bigtable, l'identificatore univoco di una riga della tabella è la chiave di riga. La chiave di riga deve essere un singolo valore univoco in un'intera tabella. Puoi creare chiavi composte da più parti concatenando elementi disparati separati da un delimitatore comune. La chiave di riga determina l'ordinamento globale dei dati in una tabella. Il servizio Bigtable determina in modo dinamico gli intervalli di chiavi assegnati a ciascun nodo.

A differenza di Cassandra, dove l'hash della chiave di partizione determina il posizionamento delle righe e le colonne di clustering determinano l'ordinamento, la chiave della riga Bigtable fornisce sia l'assegnazione nodale che l'ordinamento. Come con Cesandra, dovresti progettare una chiave di riga in Bigtable in modo che le righe che vuoi recuperare insieme siano archiviate insieme. Tuttavia, in Bigtable non è necessario progettare la chiave di riga per il posizionamento e l'ordine prima di utilizzare una tabella.

Tipi di dati

Il servizio Bigtable non applica i tipi di dati di colonna inviati dal client. Le librerie client forniscono metodi di supporto per scrivere valori di celle come byte, stringhe codificate UTF-8 e big-endian numeri interi con codifica a 64 bit (per le operazioni con incrementi atomici sono necessari).

Famiglia di colonne

In Bigtable, una famiglia di colonne determina quali colonne di una tabella vengono archiviate e recuperate insieme. Ogni tabella richiede almeno una famiglia di colonne, ma le tabelle spesso ne hanno di più (il limite è di 100 famiglie di colonne per ogni tabella). Devi creare esplicitamente famiglie di colonne prima che un'applicazione possa utilizzarle in un'operazione.

Qualificazioni delle colonne

Ogni valore archiviato in una tabella in corrispondenza di una chiave di riga è associato a un'etichetta chiamata qualificatore di colonna. Poiché i qualificatori di colonna sono solo etichette, non esiste un limite pratico al numero di colonne che puoi avere in una famiglia di colonne. I qualificatori di colonna vengono spesso utilizzati in Bigtable per rappresentare i dati delle applicazioni.

Cellule

In Bigtable, una cella è l'intersezione della chiave della riga e del nome della colonna (una famiglia di colonne combinata con un qualificatore di colonna). Ogni cella contiene uno o più valori con timestamp che possono essere forniti dal client o applicati automaticamente dal servizio. I valori delle celle precedenti vengono recuperati in base a un criterio di garbage collection configurato a livello di famiglia di colonne.

Indici secondari

Bigtable non supporta gli indici secondari. Se è necessario un indice, consigliamo di utilizzare un design tabella che utilizza una seconda tabella con una chiave di riga diversa.

Bilanciamento del carico del client e failover

In Cassandra, il client controlla il bilanciamento del carico delle richieste. Il driver client imposta un criterio che viene specificato come parte della configurazione o in modo programmatico durante la creazione della sessione. Il cluster definisce il criterio relativo ai data center più vicini all'applicazione e il client identifica i nodi di tali data center per gestire un'operazione.

Il servizio Bigtable instrada le chiamate API a un cluster di destinazione in base a un parametro (un identificatore del profilo dell'applicazione) fornito con ogni operazione. I profili delle applicazioni vengono gestiti all'interno del servizio Bigtable; le operazioni client che non selezionano un profilo utilizzano un profilo predefinito.

Bigtable prevede due tipi di criteri di routing dei profili di applicazioni: cluster singolo e multi-cluster. Un profilo multi-cluster instrada le operazioni al cluster più vicino disponibile. I cluster nella stessa area geografica sono considerati equidistanti dal punto di vista del router operativo. Se il nodo responsabile dell'intervallo di chiavi richiesto è sovraccarico o temporaneamente non disponibile in un cluster, questo tipo di profilo fornisce il failover automatico.

Per quanto riguarda Cassandra, un criterio multi-cluster offre i vantaggi di failover di un criterio di bilanciamento del carico che è consapevole dei data center.

Un profilo di applicazione con routing a cluster singolo indirizza tutto il traffico a un unico cluster. L'elevata coerenza delle righe e le transazioni su riga singola sono disponibili solo nei profili con routing a cluster singolo.

Lo svantaggio di un approccio a cluster singolo è che, in un failover, l'applicazione deve essere in grado di riprovare utilizzando un identificatore del profilo dell'applicazione alternativo oppure devi eseguire manualmente il failover dei profili di routing a cluster singolo interessati.

Routing delle operazioni

Cassandra e Bigtable utilizzano metodi diversi per selezionare il nodo di elaborazione per le operazioni di lettura e scrittura. In Cassandra viene identificata la chiave di partizione, mentre in Bigtable viene utilizzata la chiave di riga.

In Cassandra, il client controlla innanzitutto il criterio di bilanciamento del carico. Questo oggetto lato client determina il data center a cui viene instradata l'operazione.

Una volta identificato il data center, Cassandra contatta un nodo coordinatore per gestire l'operazione. Se il criterio riconosce i token, il coordinatore è un nodo che serve i dati dalla partizione vnode di destinazione, altrimenti il nodo è un nodo casuale. Il nodo coordinatore identifica i nodi in cui si trovano le repliche dei dati per la chiave di partizione dell'operazione, quindi indica ai nodi di eseguire l'operazione.

In Bigtable, come discusso in precedenza, ogni operazione include un identificatore del profilo dell'applicazione. Il profilo dell'applicazione è definito a livello di servizio. Il livello di routing di Bigtable analizza il profilo per scegliere il cluster di destinazione appropriato per l'operazione. Il livello di routing fornisce quindi un percorso per l'operazione per raggiungere i nodi di elaborazione corretti utilizzando la chiave di riga dell'operazione.

Processo di scrittura dei dati

Entrambi i database sono ottimizzati per le scritture rapide e utilizzano una procedura simile per completare le scritture. Tuttavia, i passaggi seguiti dai database variano leggermente, in particolare per Cassandra, dove, a seconda del livello di coerenza dell'operazione, potrebbe essere necessaria la comunicazione con ulteriori nodi partecipanti.

Dopo che la richiesta di scrittura è stata indirizzata ai nodi appropriati (Cassandra) o al nodo (Bigtable), le scritture vengono conservate in modo permanente su un disco in sequenza in un log di commit (Cassandra) o in un log condiviso (Bigtable). Successivamente, le scritture vengono inserite in una tabella in memoria (nota anche come memtable) ordinata come le SSTables.

Dopo questi due passaggi, il nodo risponde per indicare che la scrittura è stata completata. In Cassandra, diverse repliche (a seconda del livello di coerenza specificato per ogni operazione) devono rispondere prima che il coordinatore informi il client che la scrittura è completa. In BigTable, poiché ogni chiave di riga è assegnata a un solo nodo in un determinato momento, è sufficiente una risposta del nodo per confermare che una scrittura sia riuscita.

Successivamente, se necessario, puoi svuotare il memtable sul disco sotto forma di una nuova SSTable. In Cassandra, lo svuotamento si verifica quando il log di commit raggiunge una dimensione massima o quando la subnet supera una soglia configurata. In Bigtable, viene avviato un svuotamento per creare nuove SSTable immutabili quando la memtable raggiunge una dimensione massima specificata dal servizio. Periodicamente, un processo di compattazione unisce le SSTables per un determinato intervallo di chiavi in un'unica SSTable.

Aggiornamenti dei dati

Entrambi i database gestiscono gli aggiornamenti dei dati in modo simile. Tuttavia, Cassandra consente un solo valore per cella, mentre Bigtable può mantenere un numero elevato di valori sottoposti al controllo delle versioni per ogni cella.

Quando il valore all'intersezione di un identificatore riga univoco e di una colonna viene modificato, l'aggiornamento viene mantenuto come descritto in precedenza nella sezione Procedura di scrittura dei dati. Il timestamp di scrittura viene archiviato insieme al valore nella struttura SSTable.

Se non hai scaricato una cella aggiornata in una SSTable, puoi memorizzare solo il valore della cella nella memtable, ma i database differiscono in base ai dati archiviati. Cassandra salva solo il valore più recente nella memtable, mentre Bigtable salva tutte le versioni nella memtable.

In alternativa, se hai scaricato almeno una versione del valore di una cella su disco in SSTables distinte, i database gestiscono le richieste per questi dati in modo diverso. Quando viene richiesta la cella da Cassandra, viene restituito solo il valore più recente in base al timestamp; in altre parole, vince l'ultima scrittura. In Bigtable, utilizzi i filtri per controllare le versioni delle celle restituite da una richiesta di lettura.

Eliminazioni riga

Poiché entrambi i database utilizzano file SSTable immutabili per mantenere i dati su disco, non è possibile eliminare immediatamente una riga. Per garantire che le query restituiscano i risultati corretti dopo che una riga è stata eliminata, entrambi i database gestiscono le eliminazioni utilizzando lo stesso meccanismo. Un indicatore (chiamato tomba in Cassandra) viene aggiunto per primo alla memtable. A un certo punto, una SSTable appena scritta contiene un indicatore con timestamp che indica che l'identificatore riga univoco è stato eliminato e non deve essere restituito nei risultati della query.

Durata

Le funzionalità di durata (TTL) nei due database sono simili, ad eccezione di una disparità. In Cassandra puoi impostare il TTL per una colonna o una tabella, mentre in Bigtable puoi impostare solo i TTL per la famiglia di colonne. Esiste un metodo per Bigtable che può simulare il TTL a livello di cella.

Garbage collection

Poiché non è possibile aggiornare o eliminare immediatamente i dati con le tabelle SSC immutabili, come spiegato in precedenza, la garbage collection si verifica durante un processo chiamato compaction. Il processo rimuove le celle o le righe che non devono essere pubblicate nei risultati delle query.

Il processo di garbage collection esclude una riga o una cella quando si verifica un'unione SSTable. Se per una riga è presente un indicatore o una lapide, questa non viene inclusa nella SSTable risultante. Entrambi i database possono escludere una cella dalla tabella SSSS unita. Se il timestamp della cella supera una qualifica TTL, i database escludono la cella. Se esistono due versioni con timestamp per una determinata cella, Cassandra include solo il valore più recente nella SSTable unificata.

Percorso di lettura dati

Quando un'operazione di lettura raggiunge il nodo di elaborazione appropriato, il processo di lettura per ottenere i dati in modo da soddisfare un risultato della query è lo stesso per entrambi i database.

Per ogni SSTable su disco che potrebbe contenere risultati di query, viene controllato un filtro Bloom per determinare se ogni file contiene righe da restituire. Poiché i filtri Bloom non garantiscono mai un falso negativo, tutte le SSTables idonee vengono aggiunte a un elenco di candidati da includere in un'ulteriore elaborazione dei risultati di lettura.

L'operazione di lettura viene eseguita utilizzando una visualizzazione combinata creata dalla memtable e dalle SSTables candidati su disco. Poiché tutte le chiavi sono ordinate casualmente, è efficiente ottenere una vista unita che venga analizzata per ottenere risultati di query.

A Cassandra deve partecipare un insieme di nodi di elaborazione determinati dal livello di coerenza dell'operazione. In Bigtable, è necessario considerare solo il nodo responsabile dell'intervallo di chiavi. Per Cassandra, devi considerare le implicazioni per il calcolo del calcolo perché è probabile che più nodi elaborino ogni lettura.

I risultati di lettura possono essere limitati al nodo di elaborazione in modi leggermente diversi. In Cassandra, la clausola WHERE in una query CQL limita le righe restituite. Il vincolo è che le colonne nella chiave principale o nelle colonne incluse in un indice secondario potrebbero essere utilizzate per limitare i risultati.

Bigtable offre un assortimento di filtri avanzati che interessano le righe o le celle recuperate da una query di lettura.

Esistono tre categorie di filtri:

• Limita i filtri, che controllano le righe o le celle incluse nella risposta.
• Modificare i filtri, che influiscono sui dati o sui metadati per le singole celle.
• Composizione di filtri, che consentono di combinare più filtri in un unico filtro.

I filtri limitati sono i più utilizzati, ad esempio l'espressione regolare della famiglia di colonne e l'espressione regolare del qualificatore di colonna.

Archiviazione dei dati fisici

Bigtable e Cassandra archiviano entrambi i dati in SSTables, che vengono uniti regolarmente in fase di compattazione. La compressione dei dati SSTable offre vantaggi simili per la riduzione delle dimensioni dello spazio di archiviazione. Tuttavia, la compressione viene applicata automaticamente in Bigtable ed è un'opzione di configurazione in Cassandra.

Quando confronti i due database, devi comprendere in che modo ogni database archivia fisicamente i dati nei seguenti aspetti:

• Strategia di distribuzione dei dati
• Il numero di versioni di cella disponibili
• Il tipo di disco di archiviazione.
• Meccanismo di replica e durabilità dei dati

Distribuzione dei dati

In Cassandra, un hash coerente delle colonne di partizione della chiave primaria è il metodo consigliato per determinare la distribuzione dei dati tra le varie SSTables pubblicate dai nodi del cluster.

Bigtable utilizza un prefisso variabile per la chiave a riga intera per posizionare i dati in modo tabellare nelle SSTables.

Versioni di cella

Cassandra mantiene una sola versione attiva del valore della cella. Se vengono effettuate due scritture in una cella, un criterio last-win-win garantisce che venga restituito un solo valore.

Bigtable non limita il numero di versioni con timestamp per ogni cella. Potrebbero essere applicati altri limiti di dimensioni della riga. Se non viene impostato dalla richiesta client, il timestamp viene determinato dal servizio Bigtable nel momento in cui il nodo di elaborazione riceve la mutazione. Le versioni delle celle possono essere eliminate utilizzando un criterio di garbage collection che può essere diverso per la famiglia di colonne di ogni tabella oppure filtrato da un risultato della query impostato tramite l'API.

Archiviazione disco

Cassandra archivia le tabelle SSA su dischi collegati a ciascun nodo del cluster. Per riequilibrare i dati in Cassandra, i file devono essere fisicamente copiati tra i server.

Bigtable utilizza Colossus per archiviare le SSTables. Poiché Bigtable utilizza questo file system distribuito, è possibile che il servizio Bigtable riassegni quasi istantaneamente SSTables a nodi diversi.

Durabilità e replica dei dati

Cassandra fornisce durabilità dei dati attraverso l'impostazione dei fattori di replica. Il fattore di replica determina il numero di copie SSTable che sono archiviate su nodi diversi nel cluster. Un'impostazione tipica per il fattore di replica è 3, che consente comunque una maggiore coerenza della garanzia con QUORUM o LOCAL_QUORUM anche in caso di errore del nodo.

Con Bigtable, vengono fornite garanzie di elevata durabilità tramite la replica fornita da Colossus.

Il seguente diagramma illustra il layout fisico dei dati, i nodi di elaborazione di calcolo e il livello di routing per Bigtable:

Nel livello di archiviazione Colossus, ogni nodo viene assegnato per gestire i dati archiviati in una serie di SSTables. Queste tabelle contengono i dati degli intervalli di chiavi di riga assegnati in modo dinamico a ciascun nodo. Anche se il diagramma mostra tre tabelle SSSS per ogni nodo, è probabile che ce ne siano di più perché le tabelle SSC vengono create continuamente man mano che i nodi ricevono nuove modifiche ai dati.

Ogni nodo ha un log condiviso. Le scritture elaborate da ogni nodo vengono mantenute immediatamente nel log condiviso prima che il client riceva una conferma di scrittura. Poiché una scrittura in Colossus viene replicata più volte, la durabilità è garantita anche se si verifica un guasto hardware nodale prima che i dati vengano mantenuti in una SSTable per l'intervallo di righe.

Interfacce delle applicazioni

In origine, l'accesso al database di Cassandra veniva esposto tramite un'API Thrift, ma questo metodo di accesso era deprecato. L'interazione consigliata con il client è tramite CQL.

Analogamente all'API Thrift originale di Cassandra, l'accesso al database Bigtable viene fornito tramite un'API che legge e scrive i dati in base alle chiavi di riga fornite.

Come Cassandra, Bigtable ha sia un'interfaccia a riga di comando, chiamata cbt, sia librerie client che supportano molti linguaggi di programmazione comuni. Queste librerie si basano sulle API gRPC e REST. Le applicazioni scritte per Hadoop e che si basano sulla libreria open source Apache HBase per Java possono connettersi senza modifiche significative a Bigtable. Per le applicazioni che non richiedono la compatibilità HBase, consigliamo di utilizzare il client Java Bigtable di Bigtable.

I controlli di Identity and Access Management (IAM) di Bigtable sono completamente integrati con Google Cloud e le tabelle possono essere utilizzate anche come origine dati esterna da BigQuery.

Configurazione del database

Quando configuri un cluster Cassandra, devi prendere diverse decisioni di configurazione, nonché completare i passaggi da eseguire. Innanzitutto, devi configurare i nodi del server per fornire capacità di calcolo ed eseguire il provisioning dell'archiviazione locale. Quando utilizzi un fattore di replica pari a tre, l'impostazione consigliata e più comune, devi eseguire il provisioning dell'archiviazione per archiviare il triplo della quantità di dati prevista nel cluster. Devi inoltre determinare e impostare le configurazioni per nodi, rack e replica.

La separazione del computing dall'archiviazione in Bigtable semplifica la scalabilità verso l'alto e verso il basso dei cluster rispetto a Cassandra. In un cluster normalmente in esecuzione, ti preoccupa solo lo spazio di archiviazione totale utilizzato dalle tabelle gestite, che determina il numero minimo di nodi e la presenza di nodi sufficienti per mantenere il valore QPS attuale.

Puoi regolare rapidamente la dimensione del cluster Bigtable se il provisioning del cluster è eccessivo o insufficiente in base al carico di produzione.

Spazio di archiviazione Bigtable

A parte la località geografica del cluster iniziale, l'unica scelta che devi fare quando crei la tua istanza di Bigtable è il tipo di archiviazione. Bigtable offre due opzioni per l'archiviazione: unità a stato solido (SSD) o unità disco rigido (HDD). Tutti i cluster in un'istanza devono condividere lo stesso tipo di archiviazione.

Quando prendi in considerazione le esigenze di archiviazione con Bigtable, non devi tenere conto delle repliche di archiviazione come faresti per il dimensionamento di un cluster Cassandra. Non ci sono perdite di densità di archiviazione per raggiungere la tolleranza di errore come si vede in Cassandra. Inoltre, poiché non è necessario eseguire il provisioning esplicito dello spazio di archiviazione, ti viene addebitato solo lo spazio di archiviazione in uso.

SSD

La capacità del nodo SSD di 5 TB, preferita per la maggior parte dei carichi di lavoro, offre una densità di archiviazione superiore rispetto alla configurazione consigliata per le macchine Cassandra, che hanno una densità di archiviazione massima pratica inferiore a 2 TB per ciascun nodo. Quando valuti le esigenze di capacità di archiviazione, ricorda che Bigtable conta solo una copia dei dati; in confronto, Cesandra deve tenere conto di tre copie dei dati nella maggior parte delle configurazioni.

Sebbene la scrittura di QPS per SSD sia più o meno uguale a quella dell'HDD, l'SSD offre un valore QPS in lettura molto più elevato rispetto all'HDD. I prezzi per l'archiviazione SSD sono o vicino ai costi dei dischi permanenti SSD sottoposti a provisioning e variano in base all'area geografica.

HDD

Il tipo di archiviazione HDD consente una densità di archiviazione considerevole: 16 TB per ogni nodo. Il compromesso è che le letture casuali sono significativamente più lente, supportando solo 500 righe di lettura al secondo per ogni nodo. HDD è la scelta preferita per i carichi di lavoro che richiedono molta scrittura, nei quali è previsto che i lead siano scansioni di intervalli associate all'elaborazione batch. Il prezzo di archiviazione HDD corrisponde o quasi al costo associato a Cloud Storage e varia in base all'area geografica.

Considerazioni sulle dimensioni dei cluster

Quando dimensioni un'istanza Bigtable per prepararti alla migrazione di un carico di lavoro Cassandra, devi fare delle considerazioni quando confronti i cluster Data center singoli e le istanze Bigtable a cluster singolo e i cluster multi-casandra alle istanze Bigtable a cluster multi-cluster. Le linee guida nelle sezioni seguenti presuppongono che non sia necessario apportare modifiche significative ai modelli di dati e che esista una compressione di archiviazione equivalente tra Cassandra e Bigtable.

Un cluster di data center singolo

Quando confronti un cluster single-data center con un'istanza Bigtable singola, devi prima considerare i requisiti di archiviazione. Puoi stimare le dimensioni non replicate di ogni spazio dei tasti utilizzando il nodetool comando tablestats e dividendo le dimensioni totali dello spazio di archiviazione svuotato per il fattore di replica dello spazio dei tasti. Quindi, dividi la quantità di spazio di archiviazione non replicata di tutti gli spazi chiave per 3,5 TB (5 TB * 0,70) per determinare il numero di nodi SSD da cui gestire lo spazio di archiviazione. Come discusso, Bigtable gestisce la replica e la durabilità dello spazio di archiviazione in un livello separato che sia trasparente per l'utente.

Dovresti poi considerare i requisiti di calcolo del numero di nodi. Puoi consultare le metriche delle applicazioni client e server Cassandra per ottenere un numero approssimativo di letture e scritture sostenute che sono state eseguite. Per stimare il numero minimo di nodi SSD per l'esecuzione del tuo carico di lavoro, dividi la metrica per 10.000. Probabilmente hai bisogno di più nodi per le applicazioni che richiedono risultati di query a bassa latenza. Google consiglia di testare le prestazioni di Bigtable con dati e query rappresentativi per stabilire una metrica per il valore QPS per nodo raggiungibile per il carico di lavoro.

Il numero di nodi richiesto per il cluster deve essere uguale alle maggiori esigenze di archiviazione e calcolo. Se hai dubbi in merito alle esigenze di archiviazione o di velocità effettiva, puoi confrontare il numero di nodi Bigtable con il numero di macchine Cassandra tipiche. Puoi fare lo scale up o lo scale down di un cluster Bigtable per soddisfare le esigenze dei carichi di lavoro con il minimo sforzo e senza tempi di inattività.

Un cluster di più data center

Con i cluster di più data center, è più difficile determinare la configurazione di un'istanza Bigtable. Idealmente, dovresti avere un cluster nell'istanza per ogni data center nella topologia Cassandra. Ogni cluster Bigtable nell'istanza deve archiviare tutti i dati al suo interno e deve essere in grado di gestire la frequenza di inserimento totale nell'intero cluster. È possibile limitare l'istanza a un massimo di quattro cluster, anche se potrebbero essere creati in qualsiasi regione cloud supportata in tutto il mondo.

La tecnica per stimare le esigenze di archiviazione è simile a quella per i cluster di data center singoli. Utilizza nodetool per acquisire le dimensioni di archiviazione di ogni spazio delle chiavi nel cluster Cassandra e quindi dividerle per il numero di repliche. È necessario ricordare che lo spazio chiave di una tabella potrebbe avere fattori di replica diversi per ogni data center.

Il numero di nodi in ogni cluster in un'istanza deve essere in grado di gestire tutte le scritture nel cluster e tutte le letture in almeno due data center per mantenere gli obiettivi del livello di servizio (SLO) durante un'interruzione del cluster. Un approccio comune consiste nel iniziare con tutti i cluster con la capacità di nodi equivalente del data center più trafficato del cluster Cassandra. Puoi fare lo scale up o lo scale down dei cluster Bigtable in un'istanza per soddisfare le esigenze dei carichi di lavoro senza tempi di inattività.

Amministrazione

Bigtable fornisce componenti completamente gestiti per le funzioni di amministrazione comuni eseguite in Cassandra.

Backup e ripristino

Bigtable offre due metodi per soddisfare le esigenze di backup comuni: Backup Bigtable ed esportazioni di dati gestite.

Puoi pensare ai backup di Bigtable come a una versione gestita della funzionalità di snapshot di Cassandra nodetool. I backup di Bigtable creano copie ripristinabili di una tabella, che vengono archiviate come oggetti membri di un cluster. Puoi ripristinare i backup come una nuova tabella nel cluster che ha avviato il backup. I backup sono progettati per creare punti di ripristino in caso di danneggiamento a livello di applicazione. I backup che crei tramite questa utilità non consumano risorse dei nodi e hanno un prezzo di Cloud Storage o simile. Puoi richiamare i backup Bigtable in modo programmatico o tramite la console Google Cloud per Bigtable.

Un altro modo per eseguire il backup di Bigtable consiste nell'utilizzare un'esportazione di dati gestita in Cloud Storage. Puoi esportare i formati dei file della sequenza Avro, Parquet o Hadoop. Rispetto ai backup Bigtable, le esportazioni richiedono più tempo per essere eseguite e comportano costi di calcolo aggiuntivi perché le esportazioni utilizzano Dataflow. Tuttavia, queste esportazioni creano file di dati portatili che puoi eseguire query offline o importare in un altro sistema.

Ridimensionamento

Poiché Bigtable separa l'archiviazione e il calcolo, puoi aggiungere o rimuovere i nodi Bigtable in risposta alla domanda delle query in modo più semplice rispetto a quanto accade in Cassandra. L'architettura omogenea di Cassandra richiede il ribilanciamento dei nodi (o vnodi) tra le macchine nel cluster.

Puoi modificare manualmente le dimensioni del cluster nella console Google Cloud o in modo programmatico utilizzando l'API Bigtable. L'aggiunta di nodi a un cluster può generare miglioramenti significativi delle prestazioni in pochi minuti. Alcuni clienti hanno utilizzato correttamente un gestore della scalabilità automatica open source sviluppato da Spotify.

Manutenzione interna

Il servizio Bigtable gestisce senza problemi le attività di manutenzione interna di Cassandra comuni, come l'applicazione di patch del sistema operativo, il recupero dei nodi, la riparazione dei nodi, il monitoraggio della compattazione dello spazio di archiviazione e la rotazione dei certificati SSL.

Monitoraggio

La connessione di Bigtable alla visualizzazione o agli avvisi delle metriche non richiede attività di amministrazione o sviluppo. La pagina della console Google Cloud Bigtable è dotata di dashboard predefinite per il monitoraggio delle metriche di velocità effettiva e utilizzo a livello di istanza, cluster e tabella. Viste e avvisi personalizzati possono essere creati nelle dashboard di Cloud Monitoring, dove le metriche sono disponibili automaticamente.

Bigtable: Key Visualizer, una funzionalità di monitoraggio della console Google Cloud, ti consente di eseguire ottimizzazione delle prestazioni avanzate.

IAM e sicurezza

In Bigtable, l'autorizzazione è completamente integrata nel framework IAM di Google Cloud e richiede manutenzione e configurazione minime. Le password e gli account utente locali non vengono condivisi con le applicazioni client, ma vengono concessi autorizzazioni e ruoli granulari a utenti e account di servizio a livello di organizzazione.

Bigtable cripta automaticamente tutti i dati at-rest e in transito. Non sono disponibili opzioni per disattivare queste funzionalità. Tutti gli accessi amministrativi vengono completamente registrati. Puoi utilizzare i Controlli di servizio VPC per controllare l'accesso alle istanze Bigtable che non fanno parte delle reti approvate.

Passaggi successivi

• Scopri di più sulla progettazione dello schema Bigtable.
• Prova il codelab su BigQuery per gli utenti di Cassandra.
• Scopri di più sull'emulatore di Bigtable.
• Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.