Questo documento è rivolto a sviluppatori software e amministratori di database che vogliono eseguire la migrazione di applicazioni esistenti o progettare nuove applicazioni da utilizzare con Bigtable come data store. Questo documento applica le tue conoscenze di Apache Cassandra all'utilizzo di Bigtable.
Bigtable e Cassandra sono database distribuiti. Implementano archivi chiave-valore multidimensionali che possono supportare decine di migliaia di query al secondo (QPS), archiviazione che si espande fino a petabyte di dati e tolleranza per i guasti dei nodi.
Sebbene gli insiemi di funzionalità di questi database siano simili a un livello elevato, le loro architetture di base e i dettagli di interazione differiscono in modi importanti da comprendere. Questo documento mette in evidenza le somiglianze e le differenze tra i due sistemi di database.
Quando Bigtable è una buona destinazione per i carichi di lavoro Cassandra
Il miglior servizio Google Cloud per il tuo carico di lavoro Cassandra dipende dai tuoi scopi di migrazione e dalle funzionalità di Cassandra di cui hai bisogno dopo la migrazione.
Bigtable è ottimale quando la velocità effettiva e la latenza sono importanti tanto per le scritture quanto per le letture. La coerenza finale di Bigtable, le scritture locali rapide, la possibilità di utilizzare timestamp personalizzati, lo schema flessibile (ad esempio i tipi di raccolte aggiornabili) e la varietà di topologie di cluster consentono a Bigtable di supportare le applicazioni in evoluzione e di offrire latenze ridotte in modo economicamente conveniente.
Per eseguire la migrazione delle applicazioni senza modificare il codice, puoi scegliere di gestire autonomamente Cassandra su GKE o utilizzare un partner Google Cloud come DataStax o ScyllaDB. Se la tua applicazione è incentrata sulle letture e sei disposto a eseguire il refactoring del codice per ottenere funzionalità di database relazionali e un'elevata coerenza, potresti prendere in considerazione Spanner.
Questo documento fornisce suggerimenti su cosa considerare durante il refactoring dell'applicazione, se scegli Bigtable come destinazione di migrazione per i carichi di lavoro Cassandra.
Come utilizzare questo documento
Non è necessario leggere questo documento dall'inizio alla fine. Anche se questo documento fornisce un confronto tra i due database, puoi anche concentrarti su argomenti che si applicano al tuo caso d'uso o ai tuoi interessi.
Confrontare due database maturi non è un'operazione semplice. Per raggiungere questo scopo, questo documento:
- Confronta la terminologia, che può essere diversa nei due database.
- Fornisce una panoramica dei due sistemi di database.
- Esamina il modo in cui ogni database gestisce la definizione del modello di dati per comprendere diverse considerazioni di progettazione.
- Confronta il percorso seguito dai dati durante le scritture e le letture.
- Esamina il layout dei dati fisici per comprendere aspetti dell'architettura del database.
- Descrive come configurare la replica geografica per soddisfare i tuoi requisiti e come approcciarti al dimensionamento del cluster.
- Esamina i dettagli relativi alla gestione, al monitoraggio e alla sicurezza del cluster.
Confronto della terminologia
Anche se molti dei concetti utilizzati in Bigtable e Cassandra sono simili, ogni database ha convenzioni di denominazione leggermente diverse e differenze sottili.
Uno dei componenti di base di entrambi i database è la tabella di stringhe ordinate (SSTable). In entrambe le architetture, le SSTable vengono create per mantenere i dati utilizzati per rispondere alle query di lettura.
In un post del blog (2012), Ilya Grigorik scrive quanto segue: "Un SSTable è un'astrazione semplice per memorizzare in modo efficiente un gran numero di coppie chiave-valore, ottimizzando al contempo per carichi di lavoro di lettura o scrittura sequenziali ad alta produttività".
La seguente tabella illustra e descrive i concetti condivisi e la terminologia corrispondente utilizzata da ciascun prodotto:
| Cassandra | Bigtable |
|---|---|
|
chiave primaria: un valore univoco a un campo o a più campi che determina il posizionamento e l'ordinamento dei dati. partition key: un valore a un campo o a più campi che determina il posizionamento dei dati tramite hash coerente. colonna di raggruppamento: un valore singolo o con più campi che determina l'ordinamento dei dati lessicografici all'interno di una partizione. |
chiave di riga: una singola stringa di byte univoca che determina il posizionamento dei dati in base a un ordinamento alfabetico. Le chiavi composite vengono imitate unendo i dati di più colonne utilizzando un delimitatore comune, ad esempio i simboli di hash (#) o percentuale (%). |
| node: una macchina responsabile della lettura e della scrittura dei dati associata a una serie di intervalli di hash della partizione della chiave primaria. In Cassandra, i dati vengono archiviati in un spazio di archiviazione a livello di blocco collegato al server del nodo. | node: una risorsa di calcolo virtuale responsabile della lettura e della scrittura dei dati associati a una serie di intervalli di chiave di riga. In Bigtable, i dati non sono colocalizzati con i nodi di calcolo. ma in Colossus, il file system distribuito di Google. Ai nodi viene assegnata la responsabilità temporanea di pubblicare vari intervalli di dati in base al carico delle operazioni e allo stato di salute degli altri nodi del cluster. |
|
Data center: simile a un cluster Bigtable, tranne per alcuni aspetti della topologia e della strategia di replica che sono configurabili in Cassandra. rack: un raggruppamento di nodi in un data center che influisce sul posizionamento delle repliche. |
cluster: un gruppo di nodi nella stessa zona geografica di Google Cloud, co-localizzati per problemi di latenza e replica. |
| cluster: un deployment di Cassandra costituito da una raccolta di data center. | Istanza: un gruppo di cluster Bigtable in diverse regioni o zone Google Cloud tra cui si verificano la replica e il routing delle connessioni. |
| vnode: un intervallo fisso di valori hash assegnati a un determinato node fisico. I dati in un vnode vengono archiviati fisicamente sul nodo Cassandra in una serie di SSTables. | tablet: un'SSTable contenente tutti i dati per un intervallo contigüe di chiavi di riga ordinate in ordine alfabetico. I tablet non vengono archiviati su nodi in Bigtable, ma in una serie di SSTable su Colossus. |
| Fattore di replica: il numero di repliche di un vnode gestite 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 zonale è gestita dal livello di archiviazione Colossus. |
| tabella (in precedenza famiglia di colonne): un'organizzazione logica dei valori indicizzata dalla chiave primaria univoca. | tabella: un'organizzazione logica dei valori indicizzata dalla chiave di riga univoca. |
| keyspace: uno spazio dei nomi delle tabelle logiche che definisce il fattore di replica per le tabelle che contiene. | Non applicabile. Bigtable gestisce i problemi relativi allo spazio chiavi in modo trasparente. |
| map: un tipo di raccolta Cassandra che contiene coppie chiave-valore. | famiglia di colonne: uno spazio dei nomi specificato dall'utente che raggruppa i qualificatori di colonna per letture e scritture più efficienti. Quando esegui query su Bigtable utilizzando SQL, le famiglie di colonne vengono trattate come le mappe di Cassandra. |
| chiave mappa: chiave che identifica in modo univoco una voce chiave-valore in una mappa Cassandra | Qualificatore colonna: un'etichetta per un valore archiviato in una tabella indicizzata dalla chiave di riga univoca. Quando esegui query su Bigtable utilizzando SQL, le colonne vengono trattate come chiavi di una mappa. |
| 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 con il qualificatore di colonna. |
| cell: un valore timestamp in una tabella associato all'intersezione di una chiave primaria con la colonna. | cell: un valore 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. |
| counter: un tipo di campo incrementabile ottimizzato per le operazioni di somma di interi. | Contatori: celle che utilizzano tipi di dati specializzati per operazioni di somma di interi. Per ulteriori informazioni, consulta Creare e aggiornare contatori. |
| Criterio di bilanciamento del carico: un criterio configurato nella logica dell'applicazione per instradare le operazioni a un nodo appropriato del cluster. Il criterio tiene conto della topologia del data center e degli intervalli di token vnode. | profilo dell'applicazione: impostazioni che indicano a Bigtable come indirizzare una chiamata API client al cluster appropriato nell'istanza. Puoi anche utilizzare il profilo dell'applicazione come tag per segmentare le metriche. Configura il profilo dell'applicazione nel servizio. |
| CQL: il Cassandra Query Language, un linguaggio simile a SQL utilizzato per la creazione di tabelle, le modifiche dello schema, le mutazioni delle righe e le query. | API Bigtable: le librerie client e le API gRPC utilizzate per la creazione di istanze e cluster, la creazione di tabelle e famiglia di colonne, le mutazioni delle righe e le query. L'API SQL di Bigtable è familiare agli utenti CQL. |
Panoramiche dei prodotti
Le sezioni seguenti forniscono una panoramica della filosofia di progettazione e degli attributi chiave di Bigtable e Cassandra.
Bigtable
Bigtable fornisce molte delle funzionalità di base descritte nel documento Bigtable: A Distributed Storage System for Structured Data. Bigtable separa i nodi di calcolo, che gestiscono le richieste dei clienti, dalla gestione dell'archiviazione sottostante. I dati vengono archiviati su Colossus. Il livello di archiviazione esegue automaticamente la replica dei dati per garantire una durabilità superiore ai livelli forniti dalla replica trilaterale standard di Hadoop Distributed File System (HDFS).
Questa architettura fornisce letture e scritture coerenti all'interno di un cluster, consente di eseguire lo scale up e lo scale down senza costi di ridistribuzione dello spazio di archiviazione e può riequilibrare i carichi di lavoro senza modificare il cluster o lo schema. Se un nodo di elaborazione dei dati viene compromesso, il servizio Bigtable lo sostituisce in modo trasparente. Bigtable supporta anche la replica asincrona.
Oltre a gRPC e alle librerie client per vari linguaggi di programmazione, Bigtable mantiene la compatibilità con la libreria client Java di Apache HBase open source, un'implementazione alternativa del motore del database open source del documento Bigtable.
Il seguente diagramma mostra come Bigtable separa fisicamente i nodi di elaborazione dal livello di archiviazione:
Nel diagramma precedente, il nodo di elaborazione intermedio è responsabile solo della gestione delle richieste di dati per il set di dati C nel livello di archiviazione. Se Bigtable identifica che è necessario un nuovo bilanciamento dell'assegnazione degli intervalli per un set di dati, gli intervalli di dati per un nodo di elaborazione sono facili da modificare perché il livello di archiviazione è separato dal livello di elaborazione.
Il seguente diagramma mostra, in termini semplificati, un riequilibrio dell'intervallo di chiavi e un ridimensionamento del cluster:
L'immagine Riequilibrio mostra lo stato del cluster Bigtable dopo che il nodo di elaborazione più a sinistra riceve un numero maggiore di richieste per il set di dati A. Dopo il riequilibrio, il nodo mediano, anziché il nodo più a sinistra, è responsabile dell'erogazione 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ò riorganizzare gli intervalli di chiave di riga per bilanciare gli intervalli dei 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 parzialmente influenzato dai concetti del documento Bigtable. Utilizza un'architettura a nodi distribuiti, in cui lo spazio di archiviazione è co-allocato con i server che rispondono alle operazioni sui dati. A ogni server viene assegnata in modo casuale una serie di nodi virtuali (vnode) per gestire una parte dello spazio chiavi del cluster.
I dati vengono archiviati nei vnode in base alla chiave di partizione. In genere, viene utilizzata una funzione di hashing coerente per generare un token che determina il posizionamento dei dati. Come in Bigtable, puoi utilizzare un partizionatore che mantiene l'ordine per la generazione di token e quindi anche per il posizionamento dei dati. Tuttavia, la documentazione di Cassandra sconsiglia questo approccio perché il cluster diventerà probabilmente sbilanciato, una condizione a cui è difficile porre rimedio. Per questo motivo, questo documento presuppone che tu utilizzi una strategia di hashing coerente per generare token che consentano la distribuzione dei dati tra i nodi.
Cassandra offre tolleranza di errore tramite livelli di disponibilità correlati al livello di coerenza regolabile, consentendo a un cluster di servire i client anche quando uno o più nodi sono inattivi. Definisci la replica geografica tramite una strategia di topologia di replica dei dati configurabile.
Devi specificare un livello di coerenza per ogni operazione. L'impostazione tipica è
QUORUM (o LOCAL_QUORUM in alcune topologie con più data center). Affinché l'operazione venga considerata riuscita, questa
impostazione del livello di coerenza richiede che la maggior parte dei nodi di replica risponda al
nodo di coordinamento. Il fattore di replica, che configuri per ogni spazio chiavi, determina il numero di repliche dei dati memorizzate in ogni data center del cluster. Ad esempio, è tipico 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 ciascun nodo diviso in cinque vnode. In pratica, puoi avere più nodi e probabilmente avrai più vnode.
Nel diagramma precedente, puoi vedere il percorso di un'operazione di scrittura, con un livello di coerenza QUORUM, che ha origine da un servizio o un'applicazione client (Client). Ai fini di questo diagramma, gli intervalli di chiavi sono mostrati come intervalli alfabetici. In realtà, i token prodotti da un hash della chiave primaria sono interi con segno molto grandi.
In questo esempio, l'hash della chiave è M e i vnode per M si trovano sui nodi 2,
4 e 6. Il coordinatore deve contattare ogni nodo in cui gli intervalli di hash delle chiavi sono memorizzati localmente in modo che la scrittura possa essere elaborata. Poiché il livello di coerenza è QUORUM, due repliche (la maggioranza) devono rispondere al nodo di coordinamento prima che al cliente venga inviata una notifica di completamento della scrittura.
A differenza di Bigtable, per spostare o modificare gli intervalli di chiavi in Cassandra è necessario copiare fisicamente i dati da un nodo all'altro. Se un nodo è sovraccaricato di richieste per un determinato intervallo di hash dei token, l'aggiunta dell'elaborazione per quell'intervallo di token è più complessa in Cassandra rispetto a Bigtable.
Coerenza e replica geografica
Bigtable e Cassandra gestiscono la replica e la coerenza geografica (nota anche come multi-regione) in modo diverso. Un cluster Cassandra è costituito da nodi di elaborazione raggruppati in rack, che a loro volta sono raggruppati in data center. Cassandra utilizza una strategia di topologia di rete che configuri per determinare in che modo le repliche dei vnode vengono distribuite tra gli host in un data center. Questa strategia rivela le origini di Cassandra come database inizialmente implementato su data center fisici on-premise. Questa configurazione specifica anche il coefficiente di replica per ogni data center del cluster.
Cassandra utilizza configurazioni di data center e rack per migliorare la tolleranza ai guasti delle repliche dei dati. Durante le operazioni di lettura e scrittura, la topologia determina i nodi partecipanti necessari per fornire garanzie di coerenza. Devi configurare manualmente i nodi, i rack e i data center quando crei o espandi un cluster. In un ambiente cloud, un tipico deployment di Cassandra tratta una zona cloud come un rack e una regione cloud come un data center.
Puoi utilizzare i controlli del quorum di Cassandra per modificare le garanzie di coerenza per ogni operazione di lettura o scrittura. I livelli di robustezza della coerenza finale possono variare, incluse le opzioni che richiedono un singolo nodo replica (ONE), la maggioranza dei nodi replica di un singolo data center (LOCAL_QUORUM) o la maggioranza di tutti i nodi replica di tutti i data center (QUORUM).
In Bigtable, i cluster sono risorse a livello di zona. Un'istanza Bigtable può contenere un singolo cluster o essere un gruppo di cluster completamente replicati. Puoi posizionare i cluster di istanze in qualsiasi combinazione di zone in tutte le regioni offerte da Google Cloud. Puoi aggiungere e rimuovere cluster da un'istanza con un impatto minimo sugli altri cluster dell'istanza.
In Bigtable, le scritture vengono eseguite (con coerenza delle letture delle tue scritture) su un singolo cluster e alla fine saranno coerenti negli altri cluster di istanze. Poiché le singole celle sono sottoposte a controllo della versione in base al timestamp, non vengono perse le scritture e ogni cluster pubblica le celle con i timestamp più recenti disponibili.
Il servizio espone lo stato di 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.
Supporto per le transazioni
Sebbene nessuno dei due database supporti transazioni multiriga complesse, ciascuno offre un certo supporto per le transazioni.
Cassandra dispone di un metodo di transazione leggera (LWT) che garantisce l'atomicità per gli aggiornamenti dei valori delle colonne in un'unica partizione. Cassandra dispone anche della semantica confronta e imposta che completa l'operazione di lettura delle righe e il confronto dei valori prima dell'avvio di un'operazione di scrittura.
Bigtable supporta scritture di righe singole completamente coerenti all'interno di un cluster. Le transazioni su riga singola vengono ulteriormente attivate tramite le operazioni di lettura, modifica e scrittura e di controllo e modifica. I profili dell'applicazione di routing multi-cluster non supportano le transazioni con una sola riga.
Modello dati
Sia Bigtable che Cassandra organizzano i dati in tabelle che supportano le ricerche e le scansioni di intervalli utilizzando l'identificatore univoco della riga. Entrambi i sistemi vengono classificati come spazi di archiviazione NoSQL a colonne larghe.
In Cassandra, devi utilizzare CQL per creare in anticipo lo schema completo della tabella, incluso la definizione della chiave primaria, i nomi delle colonne e i relativi tipi. Le chiavi primarie in Cassandra sono valori compositi univoci costituiti da una chiave di partizione obbligatoria e una chiave di cluster facoltativa. La chiave di partizione determina il posizionamento del nodo di una riga e la chiave del cluster determina l'ordinamento all'interno di una partizione. Quando crei gli schemi, devi essere consapevole 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 in anticipo le relative famiglie di colonne. Le colonne non vengono dichiarate quando vengono create le tabelle, ma vengono create quando le chiamate dell'API dell'applicazione aggiungono celle alle righe della tabella.
Le chiavi di riga sono ordinate in ordine lessicografico nel cluster Bigtable. I nodi di Bigtable bilanciano automaticamente la responsabilità per gli intervalli di chiavi, spesso indicati come tablet e a volte come split. Le chiavi di riga di Bigtable sono spesso costituite da diversi valori di campo che vengono uniti utilizzando un carattere separatore di uso comune scelto da te (ad esempio il segno di percentuale). Se separati, i singoli componenti della stringa sono analoghi ai campi di una chiave primaria Cassandra.
Progettazione delle chiavi di riga
In Bigtable, l'identificatore univoco di una riga di tabella è la chiave di riga. La chiave di riga deve essere un singolo valore univoco in un'intera tabella. Puoi creare chiavi con più parti concatenando elementi diversi 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, in cui l'hash della chiave di partizione determina il posizionamento delle righe e le colonne di clustering determinano l'ordinamento, la chiave di riga di Bigtable fornisce sia l'assegnazione dei nodi sia l'ordinamento. Come per Cassandra, devi progettare una chiave di riga in Bigtable in modo che le righe che vuoi recuperare insieme vengano memorizzate insieme. Tuttavia, in Bigtable non è necessario progettare la chiave di riga per il posizionamento e l'ordinamento prima di utilizzare una tabella.
Tipi di dati
Il servizio Bigtable non applica i tipi di dati delle colonne inviati dal client. Le librerie client forniscono metodi di assistenza per scrivere i valori delle celle come byte, stringhe codificate UTF-8 e interi a 64 bit codificati in big endian (gli interi codificati in big endian sono richiesti per le operazioni di incremento atomico).
Famiglia di colonne
In Bigtable, una famiglia di colonne determina quali colonne di una tabella vengono memorizzate e recuperate insieme. Ogni tabella ha bisogno di almeno una famiglia di colonne, anche se spesso le tabelle ne hanno di più (il limite è 100 famiglie di colonne per ogni tabella). Devi creare esplicitamente le famiglie di colonne prima che un'applicazione possa utilizzarle in un'operazione.
Qualificatori di colonna
Ogni valore memorizzato in una tabella in 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 dell'applicazione.
Celle
In Bigtable, una cella è l'intersezione della chiave di 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 vecchi valori delle celle 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 è obbligatorio un indice, ti consigliamo di utilizzare un design di tabella che utilizzi una seconda tabella con una chiave di riga diversa.
Bilanciamento del carico e failover dei client
In Cassandra, il client controlla il bilanciamento del carico delle richieste. Il driver del client imposta un criterio che viene specificato durante la configurazione o in modo programmatico durante la creazione della sessione. Il cluster informa il criterio sui data center più vicini all'applicazione e il client identifica i nodi di questi data center per eseguire 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 dell'applicazione vengono gestiti all'interno del servizio Bigtable; le operazioni client che non selezionano un profilo utilizzano un profilo predefinito.
Bigtable dispone di due tipi di criteri di routing dei profili dell'applicazione: a cluster singolo e a cluster multipli. Un profilo multi-cluster instrada le operazioni al cluster disponibile più vicino. I cluster nella stessa regione sono considerati equidistanti dal punto di vista del router di operazioni. Se il nodo responsabile dell'intervallo di chiavi richiesto è sovraccaricato o temporaneamente non disponibile in un cluster, questo tipo di profilo fornisce il failover automatico.
In termini di Cassandra, un criterio multicluster offre i vantaggi del failover di un criterio di bilanciamento del carico che tiene conto dei data center.
Un profilo dell'applicazione con routing a un cluster singolo indirizza tutto il traffico a un singolo cluster. La coerenza delle righe e le transazioni su riga singola sono disponibili solo nei profili con routing a un cluster singolo.
Lo svantaggio di un approccio a cluster singolo è che, in caso di failover, l'applicazione deve essere in grado di riprovare utilizzando un identificatore di 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 node 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 ispeziona prima il criterio di bilanciamento del carico. Questo oggetto lato client determina il data center a cui viene indirizzata l'operazione.
Una volta identificato il data center, Cassandra contatta un nodo di coordinamento per gestire l'operazione. Se il criterio riconosce i token, il coordinatore è un nodo che serve i dati della partizione del vnode di destinazione; in caso contrario, il coordinatore è un nodo casuale. Il nodo di coordinamento identifica i nodi in cui si trovano le repliche dei dati per la chiave di partizione dell'operazione e poi li istruisce a eseguire l'operazione.
In Bigtable, come discusso in precedenza, ogni operazione include un identificativo del profilo dell'applicazione. Il profilo dell'applicazione è definito a livello di servizio. Il livello di routing di Bigtable ispeziona il profilo per scegliere il cluster di destinazione appropriato per l'operazione. Il livello di routing fornisce quindi un percorso per consentire all'operazione di 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 una scrittura. Tuttavia, i passaggi eseguiti dai database variano leggermente, soprattutto per Cassandra, dove, a seconda del livello di coerenza dell'operazione, potrebbe essere necessaria la comunicazione con nodi partecipanti aggiuntivi.
Dopo che la richiesta di scrittura è stata indirizzata ai nodi (Cassandra) o al nodo appropriato (Bigtable), le scritture vengono prima memorizzate in modo sequenziale sul disco 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 SSTable.
Dopo questi due passaggi, il nodo risponde per indicare che la scrittura è 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 è completata. In Bigtable, poiché ogni chiave di riga viene assegnata a un solo nodo in qualsiasi momento, è sufficiente una risposta del nodo per confermare che una scrittura è andata a buon fine.
In un secondo momento, se necessario, puoi svuotare la memtable sul disco sotto forma di nuova tabella SS. In Cassandra, lo svuotamento si verifica quando il log dei commit raggiunge una dimensione massima o quando la memtable supera una soglia configurata. In Bigtable viene avviato uno svuotamento per creare nuove tabella SS immutable quando la tabella memtable raggiunge una dimensione massima specificata dal servizio. Periodicamente, un processo di compattazione unisce le SSTable 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 solo un valore per ogni cella, mentre Bigtable può conservare un numero elevato di valori con versione per ogni cella.
Quando il valore all'intersezione di un identificatore di riga univoco e di una colonna viene modificato, l'aggiornamento viene mantenuto come descritto in precedenza nella sezione sulla procedura di scrittura dei dati. Il timestamp di scrittura viene memorizzato insieme al valore nella struttura SSTable.
Se non hai svuotato una cella aggiornata in una SSTable, puoi memorizzare solo il valore della cella nella memtable, ma i database differiscono in base a ciò che viene memorizzato. Cassandra salva solo il valore più recente nella memtable, mentre Bigtable salva tutte le versioni nella memtable.
In alternativa, se hai eseguito lo svuotamento di almeno una versione del valore di una cella su disco in SSTable separate, i database gestiscono le richieste per questi dati in modo diverso. Quando la cella viene richiesta da Cassandra, viene restituito solo il valore più recente in base al timestamp. In altre parole, l'ultima scrittura ha la precedenza. In Bigtable, utilizzi filtri per controllare le versioni delle celle restituite da una richiesta di lettura.
Eliminazioni di righe
Poiché entrambi i database utilizzano file SSTable immutabili per mantenere i dati sul disco, non è possibile eliminare immediatamente una riga. Per garantire che le query restituiscano i risultati corretti dopo l'eliminazione di una riga, entrambi i database gestiscono le eliminazioni utilizzando lo stesso meccanismo. Un indicatore (chiamato tombstone in Cassandra) viene aggiunto prima alla tabella memorizzata nella memoria. Alla fine, 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 tranne per una disparità. In Cassandra, puoi impostare il TTL per una colonna o una tabella, mentre in Bigtable puoi impostare i TTL solo per la famiglia di colonne. Esiste un metodo per Bigtable che può simulare il TTL a livello di cella.
Garbage collection
Poiché gli aggiornamenti o le eliminazioni immediate dei dati non sono possibili con le SSTable immutabili, come discusso in precedenza, la garbage collection avviene durante un processo chiamato compaction. Il processo rimuove le celle o le righe che non devono essere visualizzate nei risultati della query.
Il processo di garbage collection esclude una riga o una cella quando si verifica un'unione di SSTable. Se esiste un indicatore o un indicatore di eliminazione per una riga, questa riga non è inclusa nella tabella SSTable risultante. Entrambi i database possono escludere una cella dalla tabella SS 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 unita.
Percorso di lettura dei dati
Quando un'operazione di lettura raggiunge il nodo di elaborazione appropriato, la procedura di lettura per ottenere i dati per soddisfare un risultato di query è la stessa per entrambi i database.
Per ogni SSTable su disco che potrebbe contenere i risultati di query, viene controllato un filtro Bloom per determinare se ogni file contiene righe da restituire. Poiché i filtri Bloom garantiscono di non fornire mai un falso negativo, tutte le SSTable idonee vengono aggiunte a un elenco di candidati da includere nell'ulteriore elaborazione del risultato di lettura.
L'operazione di lettura viene eseguita utilizzando una vista unita creata dalla tabella memorizzata nella memoria e dalle SSTable candidate su disco. Poiché tutte le chiavi sono alfabeticamente ordinate, è efficiente ottenere una visualizzazione unita che viene analizzata per ottenere risultati delle query.
In Cassandra, un insieme di nodi di elaborazione determinati dal livello di coerenza dell'operazione deve partecipare all'operazione. In Bigtable, deve essere consultato solo il nodo responsabile dell'intervallo di chiavi. Per Cassandra, devi considerare le implicazioni per la dimensione dell'elaborazione, in quanto è probabile che più nodi elaborino ogni lettura.
I risultati di lettura possono essere limitati nel 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 della chiave primaria o le colonne incluse in un indice secondario potrebbero essere utilizzate per limitare i risultati.
Bigtable offre un ampio assortimento di filtri che influiscono sulle righe o sulle celle recuperate da una query di lettura.
Esistono tre categorie di filtri:
- Filtri limitanti, che controllano le righe o le celle incluse nella risposta.
- Modifica dei filtri, che influiscono sui dati o sui metadati delle singole celle.
- Filtri composti, che ti consentono di combinare più filtri in un unico filtro.
I filtri limitanti sono i più utilizzati, ad esempio l'espressione regolare della famiglia di colonne e l'espressione regolare del qualificatore della colonna.
Archiviazione fisica dei dati
Sia Bigtable che Cassandra archiviano i dati in SSTables, che vengono regolarmente unite durante una 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 capire in che modo ciascun database memorizza fisicamente i dati in modo diverso nei seguenti aspetti:
- La strategia di distribuzione dei dati
- Il numero di versioni di celle disponibili
- Il tipo di disco di archiviazione
- Il 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 SSTable servite dai nodi del cluster.
Bigtable utilizza un prefisso variabile per la chiave di riga completa per collocare i dati in modo alfabetico nelle SSTable.
Versioni delle celle
Cassandra mantiene una sola versione del valore della cella attiva. Se vengono eseguite due scritture in una cellula, un criterio di ultima scrittura valida 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 dimensione delle righe. Se non viene impostato dalla richiesta del 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 possono essere filtrate da un insieme di risultati di query tramite l'API.
Spazio di archiviazione su disco
Cassandra archivia le SSTables sui dischi collegati a ciascun nodo del cluster. Per riequilibrare i dati in Cassandra, i file devono essere copiati fisicamente tra i server.
Bigtable utilizza Colossus per archiviare le SSTable. Poiché Bigtable utilizza questo file system distribuito, è possibile per il servizio Bigtable riassegnare quasi istantaneamente le SSTable a nodi diversi.
Durata e replica dei dati
Cassandra garantisce la durabilità dei dati tramite l'impostazione del fattore di replica. Il
coefficiente di replica determina il numero di copie delle SSTable archiviate su
diversi nodi del cluster. Un'impostazione tipica per il fattore di replica è
3, che consente comunque garanzie di coerenza più elevate con QUORUM o
LOCAL_QUORUM anche in caso di guasto di un nodo.
Con Bigtable, vengono fornite garanzie elevate di durabilità dei dati tramite la replica offerta da Colossus.
Il seguente diagramma illustra il layout dei dati fisici, i nodi di elaborazione del calcolo e il livello di routing per Bigtable:
Nel livello di archiviazione Colossus, a ogni nodo viene assegnato il servizio dei dati archiviati in una serie di SSTable. Queste SSTable contengono i dati per gli intervalli di chiave di riga assegnati dinamicamente a ciascun nodo. Sebbene il diagramma mostri tre tabelle SSTable per ogni nodo, è probabile che ce ne siano di più perché le tabelle SSTable vengono create continuamente man mano che i nodi ricevono nuove modifiche ai dati.
Ogni nodo ha un log condiviso. Le scritture elaborate da ciascun nodo vengono conservate immediatamente nel log condiviso prima che il client riceva un conferma della scrittura. Poiché una scrittura in Colossus viene replicata più volte, la durabilità è garantita anche se si verifica un guasto hardware del nodo prima che i dati vengano mantenuti in un'SSTable per l'intervallo di righe.
Interfacce di applicazione
In origine, l'accesso al database Cassandra era esposto tramite un'API Thrift, ma questo metodo di accesso è deprecato. L'interazione con il client consigliata avviene 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 dispone sia di un'interfaccia a riga di comando, chiamata cbtCLI
, sia di librerie client che supportano molti linguaggi di programmazione comuni. Queste librerie sono basate sulle API gRPC e REST. Le applicazioni scritte per Hadoop e basate sulla libreria Apache HBase open source per Java possono connettersi
senza modifiche significative
a Bigtable. Per le applicazioni che non richiedono la compatibilità con HBase, ti consigliamo di utilizzare il client Java Bigtable integrato.
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 e completare diversi passaggi. Innanzitutto, devi configurare i nodi del server per fornire capacità di calcolo e eseguire il provisioning dello spazio di archiviazione locale. Quando utilizzi un coefficiente di replica pari a tre, l'impostazione consigliata e più comune, devi eseguire il provisioning dello spazio di archiviazione per memorizzare tre volte la quantità di dati che prevedi di memorizzare nel tuo cluster. Devi anche determinare e impostare le configurazioni per vnode, rack e replica.
La separazione dell'elaborazione dallo spazio di archiviazione in Bigtable semplifica la scalabilità dei cluster rispetto a Cassandra. In un cluster in esecuzione normale, in genere devi preoccuparti solo dello spazio di archiviazione totale utilizzato dalle tabelle gestite, che determina il numero minimo di nodi e la presenza di un numero sufficiente di nodi per mantenere il QPS corrente.
Puoi modificare rapidamente le dimensioni del cluster Bigtable se il cluster è sovra o sottodimensionato in base al carico di produzione.
Spazio di archiviazione Bigtable
A parte la posizione geografica del cluster iniziale, l'unica scelta che devi fare quando crei l'istanza Bigtable è il tipo di archiviazione. Bigtable offre due opzioni per lo spazio di archiviazione: unità a stato solido (SSD) o unità disco rigido (HDD). Tutti i cluster di 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 determinare le dimensioni di un cluster Cassandra. Non si verifica alcuna perdita di densità di archiviazione per ottenere la tolleranza di errore, come accade 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, che è 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 ogni nodo. Quando valuti le esigenze di capacità di archiviazione, ricorda che Bigtable conteggia una sola copia dei dati; in confronto, Cassandra deve tenere conto di tre copie dei dati nella maggior parte delle configurazioni.
Sebbene i QPS di scrittura per l'SSD siano circa gli stessi dell'HDD, l'SSD offre QPS di lettura notevolmente superiori rispetto all'HDD. Lo spazio di archiviazione SSD ha un prezzo pari o simile ai costi dei dischi permanenti SSD provisionati e varia in base alla regione.
HDD
Il tipo di archiviazione HDD consente una densità di archiviazione considerevole: 16 TB per ogni nodo. Il compromesso è che le letture casuali sono molto più lente, supportando solo 500 righe lette al secondo per ogni nodo. L'HDD è preferibile per i carichi di lavoro con uso intensivo di scrittura in cui si prevede che le letture siano scansioni di intervalli associate all'elaborazione batch. L'archiviazione su HDD ha un prezzo pari o simile al costo associato a Cloud Storage e varia in base alla regione.
Considerazioni sulle dimensioni del cluster
Quando scegli le dimensioni di un'istanza Bigtable per prepararti alla migrazione di un carico di lavoro Cassandra, devi tenere conto di alcune considerazioni quando confronti i cluster Cassandra a un solo data center con le istanze Bigtable a un solo cluster e i cluster Cassandra a più data center con le istanze Bigtable a più cluster. Le linee guida riportate nelle sezioni seguenti presuppongono che non siano necessarie modifiche significative al modello dei dati per la migrazione e che esista una compressione dello spazio di archiviazione equivalente tra Cassandra e Bigtable.
Un cluster con un solo data center
Quando confronti un cluster di un singolo data center con un'istanza Bigtable a un cluster, devi prima considerare i requisiti di archiviazione. Puoi stimare le dimensioni non replicate di ogni spazio chiavi utilizzando il
nodetool comando tablestats
e dividendo le dimensioni totali dello spazio di archiviazione svuotato per il
factor di replica dello spazio chiavi. Poi, dividi lo spazio di archiviazione non replicato di tutti gli spazi chiavi per
3,5 TB
(5 TB * 0,70)
per determinare il numero suggerito di nodi SSD per gestire solo lo spazio di archiviazione. Come discusso, Bigtable gestisce la replica e la durabilità dello spazio di archiviazione all'interno di un livello separato trasparente per l'utente.
Successivamente, devi considerare i requisiti di calcolo per il numero di nodi. Puoi consultare le metriche del server Cassandra e dell'applicazione client per ottenere un numero approssimativo di letture e scritture sostenute che sono state eseguite. Per stimare il numero minimo di nodi SSD per eseguire il 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 query e dati rappresentativi per stabilire una metrica per il QPS per nodo che sia raggiungibile per il tuo carico di lavoro.
Il numero di nodi necessari per il cluster deve essere uguale al valore maggiore tra le esigenze di archiviazione e di calcolo. In caso di dubbi sulle tue esigenze di archiviazione o throughput, puoi associare il numero di nodi Bigtable al numero di macchine Cassandra standard. Puoi eseguire lo scale up o lo scale down di un cluster Bigtable in base alle esigenze del carico di lavoro con il minimo sforzo e senza tempi di inattività.
Un cluster con 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. I cluster di un'istanza possono essere creati in qualsiasi regione cloud supportata in tutto il mondo.
La tecnica per stimare le esigenze di archiviazione è simile all'approccio per i cluster con un unico data center. Utilizza nodetool per acquisire le dimensioni dello spazio di archiviazione di ogni spazio chiavi nel cluster Cassandra e poi dividi queste dimensioni per il numero di repliche. Devi ricordare che lo spazio chiavi di una tabella potrebbe avere fattori di replica diversi per ogni data center.
Il numero di nodi in ogni cluster di 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 di livello del servizio (SLO) durante un'interruzione del cluster. Un approccio comune è iniziare con tutti i cluster che hanno la capacità di nodi equivalente del data center più trafficato nel cluster Cassandra. I cluster Bigtable in un'istanza possono essere scalati singolarmente in base alle esigenze del carico 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 fornisce due metodi per soddisfare le esigenze di backup comuni: backup di Bigtable ed esportazioni di dati gestite.
Puoi considerare i backup Bigtable come analoghi a una versione gestita della funzionalità di snapshot nodetool di Cassandra.
I backup di Bigtable creano copie ripristinabili di una tabella, che vengono memorizzate come oggetti membro di un cluster. Puoi ripristinare i backup come 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 creati tramite questa utility non consumano risorse del nodo e hanno un prezzo uguale o simile a quello di Cloud Storage. Puoi richiamare i backup di Bigtable
programmaticamente o tramite la console Google Cloud per Bigtable.
Un altro modo per eseguire il backup di Bigtable è utilizzare un'esportazione di dati gestita in Cloud Storage. Puoi esportare nei formati file Avro, Parquet o Hadoop Sequence. Rispetto ai backup di 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 su cui puoi eseguire query offline o importarli in un altro sistema.
Ridimensionamento
Poiché Bigtable separa l'archiviazione e il calcolo, puoi aggiungere o rimuovere i nodi Bigtable in risposta alla domanda di query in modo più semplice rispetto a Cassandra. L'architettura omogenea di Cassandra richiede di riequilibrare i nodi (o vnode) tra le macchine del cluster.
Puoi modificare la dimensione del cluster manualmente nella console Google Cloud o tramite codice utilizzando l'API Cloud Bigtable. L'aggiunta di nodi a un cluster può generare miglioramenti significativi delle prestazioni in pochi minuti. Alcuni clienti hanno utilizzato con successo un autoscalatore open source sviluppato da Spotify.
Manutenzione interna
Il servizio Bigtable gestisce senza problemi le attività di manutenzione interna 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
Il collegamento di Bigtable alla visualizzazione delle metriche o agli avvisi non richiede attività di amministrazione o sviluppo. La pagina della console Google Cloud Bigtable contiene dashboard predefinite per monitorare le metriche di throughput e utilizzo a livello di istanza, cluster e tabella. È possibile creare visualizzazioni e avvisi personalizzati nelle dashboard di Cloud Monitoring, dove le metriche sono disponibili automaticamente.
Key Visualizer di Bigtable, una funzionalità di monitoraggio nella console Google Cloud, ti consente di eseguire ottimizzazioni avanzate delle prestazioni.
IAM e sicurezza
In Bigtable, l'autorizzazione è completamente integrata nel framework IAM di Google Cloud e richiede una configurazione e una manutenzione minime. Gli account e le password degli utenti locali non vengono condivisi con le applicazioni client. Al contrario, autorizzazioni e ruoli granulari vengono concessi agli utenti e agli 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 registrati completamente. Puoi utilizzare Controlli di servizio VPC per controllare l'accesso alle istanze Bigtable dall'esterno delle reti approvate.
Passaggi successivi
- Scopri di più sulla progettazione dello schema di Bigtable.
- Prova il codelab Bigtable per gli utenti Cassandra.
- Scopri di più sull'emulatore Bigtable.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.