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 Bigtable.
Bigtable e Cassandra sono database distribuiti. Implementano archivi chiave-valore multidimensionali in grado di supportare decine di migliaia di query al secondo (QPS), spazio di archiviazione in grado di scalare fino a petabyte di dati e tolleranza agli errori dei nodi.
Sebbene i set di funzionalità di questi database siano simili a livello generale, le architetture sottostanti e i dettagli di interazione differiscono in modo importante da comprendere. 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 su argomenti applicabili al tuo caso d'uso o ai tuoi interessi.
Confrontare due database maturi non è un compito semplice. A questo scopo, il presente 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 capire le diverse considerazioni di progettazione.
- Confronta il percorso dei dati durante le scritture e le letture.
- Esamina il layout fisico dei dati per comprendere aspetti dell'architettura del database.
- Descrive come configurare la replica geografica per soddisfare i tuoi requisiti e come affrontare le dimensioni del cluster.
- Esamina i dettagli della gestione, del monitoraggio e della sicurezza dei cluster.
Confronto terminologico
Sebbene molti dei concetti utilizzati in Bigtable e Cassandra siano simili, ogni database ha convenzioni di denominazione leggermente diverse e sottili differenze.
Uno dei componenti di base di entrambi i database è la tabella di stringhe ordinata (SSTable). In entrambe le architetture, le tabelle SSTable 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 mediante l'ottimizzazione per carichi di lavoro di velocità effettiva elevata e di lettura o scrittura sequenziale".
La seguente tabella descrive e descrive i concetti condivisi e la terminologia corrispondente utilizzata da ogni prodotto:
| Cassandra | Bigtable |
|---|---|
|
chiave primaria: un valore univoco a campo singolo o multicampo che determina il posizionamento e l'ordinamento dei dati. partition key: un valore a campo singolo o a più campi che determina il posizionamento dei dati tramite un hash coerente. colonna di clustering: un valore a campo singolo o multicampo che determina l'ordinamento lessicografico dei dati all'interno di una partizione. |
chiave di riga: una stringa di byte univoca che determina il posizionamento dei dati in base a un ordinamento lessicografico. Le chiavi composte vengono imitate unendo i dati di più colonne utilizzando un delimitatore comune, ad esempio il cancelletto (#) o i simboli di percentuale (%). |
| node: una macchina responsabile della lettura e della scrittura di dati associati a una serie di intervalli hash di partizioni di chiave primaria. In Casssandra, i dati vengono archiviati nell'archiviazione a livello di blocco collegata al server nodo. | node: una risorsa di computing virtuale responsabile della lettura e della scrittura di dati associati a una serie di intervalli di chiave di riga. In Bigtable, i dati non vengono collocati nei nodi di computing. Vengono invece archiviati in Colossus, il file system distribuito di Google. Ai nodi viene assegnata la responsabilità temporanea di fornire vari intervalli di dati in base al carico delle operazioni e all'integrità degli altri nodi nel cluster. |
|
data center: simile a un cluster Bigtable, ad eccezione di alcuni aspetti della topologia e della strategia di replica che sono configurabili in Cassandra. rack: un raggruppamento di nodi in un data center che influenza il posizionamento della replica. |
cluster: un gruppo di nodi nella stessa zona geografica di Google Cloud, colocata per problemi di latenza e replica. |
| cluster: un deployment Cassandra costituito da una raccolta di data center. | instance: un gruppo di cluster Bigtable in diverse zone o regioni Google Cloud tra cui avviene la replica e il routing delle connessioni. |
| vnode: un intervallo fisso di valori hash assegnati a un nodo fisico specifico. I dati in un nodo sono fisicamente archiviati nel nodo Cassandra in una serie di SSTable. | tablet: una SSTable contenente tutti i dati per un intervallo contiguo di chiavi di riga ordinate lessicograficamente. I tablet non vengono archiviati sui nodi in Bigtable, ma sono archiviati in una serie di SSTables su Colossus. |
| fattore di replica: il numero di repliche di un vnode che vengono mantenute in tutti i nodi nel data center. Il fattore di replica è configurato in modo indipendente per ogni data center. | replica: il processo di replica dei dati archiviati in Bigtable a tutti i cluster nell'istanza. La replica all'interno di un cluster di zona è gestita dal livello di archiviazione Colossus. |
| tabella (in precedenza famiglia di colonne): un'organizzazione logica di valori indicizzati dalla chiave primaria univoca. | table: un'organizzazione logica di valori indicizzati dalla chiave di riga univoca. |
| keyspace: uno spazio dei nomi di tabella logico che definisce il fattore di replica per le tabelle che contiene. | Non applicabile. Bigtable gestisce i problemi degli spazi delle chiavi 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 letture e scritture più efficienti. |
| colonna: l'etichetta di un valore memorizzato in una tabella indicizzato dalla chiave primaria univoca. | colonna: l'etichetta di un valore archiviato in una tabella che viene indicizzata dalla chiave di riga univoca. Il nome della colonna viene creato combinando la famiglia di colonne con 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 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 di bilanciamento del carico: un criterio da configurare nella logica dell'applicazione per instradare le operazioni a un nodo appropriato nel cluster. Il criterio tiene conto della topologia dei data center e degli intervalli di token vnode. | profilo di applicazione: impostazioni che indicano a Bigtable come instradare una chiamata API client al cluster appropriato nell'istanza. Puoi usare il profilo dell'applicazione anche come tag per segmentare le metriche. Puoi configurare il profilo dell'applicazione nel servizio. |
| CQL: il Cassandra Query Language, un linguaggio come SQL utilizzato per creare tabelle, modifiche allo schema, modifiche alle righe e query. | API Bigtable: le librerie client e le API gRPC utilizzate per la creazione di istanze e cluster, per la creazione di famiglie di tabelle e colonne, per le modifiche alle righe e per le query. |
Panoramiche dei prodotti
Le seguenti sezioni forniscono una panoramica della filosofia di progettazione e degli attributi chiave di Bigtable e Cassandra.
Bigtable
Bigtable offre molte delle funzionalità principali descritte nell'articolo Bigtable: A Distributed Storage System for Structured Data. Bigtable separa i nodi di computing, che gestiscono le richieste dei client, dalla gestione dell'archiviazione sottostante. I dati vengono archiviati su Colossus. Il livello di archiviazione replica automaticamente i dati per fornire una durabilità superiore ai livelli della replica a tre vie standard Hadoop Distributed File System (HDFS).
Questa architettura fornisce letture e scritture coerenti all'interno di un cluster, esegue 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 dati ha problemi, il servizio Bigtable lo sostituisce in modo trasparente. Bigtable supporta anche la replica asincrona.
Oltre a gRPC e librerie client per vari linguaggi di programmazione, Bigtable mantiene la compatibilità con la libreria client Java open source Apache HBase, un'implementazione alternativa del motore del database open source dell'articolo 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 gestione delle richieste di dati per il set di dati C nel livello di archiviazione. Se Bigtable identifica la necessità di un ribilanciamento dell'assegnazione dell'intervallo per un set di dati, gli intervalli di dati per un nodo di elaborazione sono semplici da modificare poiché il livello di archiviazione è separato da quello di elaborazione.
Il seguente diagramma mostra, in termini semplificati, un ribilanciamento dell'intervallo di chiavi e un ridimensionamento del cluster:
L'immagine Ribilanciamento 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 ribilanciamento, il nodo centrale, anziché quello più a sinistra, è responsabile della gestione delle richieste di dati per il set di dati B. Il nodo più a sinistra continua a inviare le richieste di servizio per il set di dati A.
Bigtable può riorganizzare gli intervalli di chiave di riga per bilanciare gli intervalli di set di dati in un numero maggiore di nodi di elaborazione disponibili. L'immagine Ridimensionamento mostra lo stato del cluster Bigtable dopo l'aggiunta di un nodo.
Cassandra
Apache Cassandra è un database open source in parte influenzato dai concetti del white paper Bigtable. Utilizza un'architettura dei nodi distribuiti, in cui l'archiviazione viene colocata con i server che rispondono alle operazioni sui dati. A ciascun server viene assegnata in modo casuale una serie di nodi virtuali (vnode) per gestire una parte dello spazio delle chiavi del cluster.
I dati vengono archiviati nei vnode in base alla chiave di partizione. In genere, una funzione hash coerente viene utilizzata per generare un token e determinare il posizionamento dei dati. Come con Bigtable, puoi utilizzare uno partizionatore con protezione dell'ordine per la generazione di token e quindi anche per il posizionamento dei dati. Tuttavia, la documentazione di Cassandra scoraggia questo approccio perché è probabile che il cluster diventi sbilanciato, una condizione difficile da risolvere. Per questo motivo, questo documento presuppone l'utilizzo di una strategia di hashing coerente per generare token che portino alla distribuzione dei dati tra i nodi.
Cassandra fornisce la tolleranza di errore attraverso i livelli di disponibilità correlati al livello di coerenza ottimizzabile, 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.
Devi specificare un livello di coerenza per ogni operazione. L'impostazione tipica è QUORUM (o LOCAL_QUORUM in alcune topologie a più data center). Questa impostazione del livello di coerenza richiede che la maggior parte dei nodi di replica risponda al nodo coordinatore affinché l'operazione venga considerata riuscita. Il fattore di replica, che configuri per ogni spazio delle chiavi, determina il numero di repliche dei dati archiviate in ciascun data center nel cluster. Ad esempio, di solito viene utilizzato un valore del fattore di replica 3 per ottenere 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 vnode. In pratica, puoi avere più nodi e probabilmente avere più vnodi.
Nel diagramma precedente, puoi vedere il percorso di un'operazione di scrittura, con un livello di coerenza QUORUM, che ha origine da un'applicazione client o da un servizio (Client). Ai fini di questo diagramma, gli intervalli di chiavi sono
mostrati sotto forma di 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 vnode per M si trovano sui nodi 2, 4 e 6. Il coordinatore deve contattare ogni nodo in cui gli intervalli hash delle chiavi sono archiviati localmente, in modo che la scrittura possa essere elaborata. Poiché il livello di coerenza è QUORUM, due repliche (la maggior parte) devono rispondere al nodo coordinatore prima che il client riceva la notifica del completamento della scrittura.
A differenza di Bigtable, lo spostamento o la modifica di intervalli di chiavi in Cassandra richiede la copia fisica dei dati da un nodo all'altro. Se un nodo è sovraccarico di richieste per un determinato intervallo di hash di token, l'aggiunta dell'elaborazione per quell'intervallo di token è più complessa in Cassandra rispetto a Bigtable.
Replica geografica e coerenza
Bigtable e Cassandra gestiscono la replica geografica (nota anche come più regioni) e la coerenza in modo diverso. Un cluster Cassandra è costituito da nodi di elaborazione raggruppati in rack, mentre questi ultimi sono raggruppati in data center. Cassandra utilizza una strategia di topologia di rete che puoi configurare per determinare in che modo le repliche di nodi sono distribuite tra gli host in un data center. Questa strategia rivela le radici di Cassandra come database originariamente distribuito in data center fisici on-premise. Questa configurazione specifica anche il fattore di replica per ciascun data center nel cluster.
Cassandra utilizza 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 fornire garanzie di coerenza. Devi configurare manualmente nodi, rack e data center quando crei o estendi un cluster. In un ambiente cloud, un tipico deployment 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 regolare le garanzie di coerenza per ogni operazione di lettura o scrittura. I livelli di efficacia della coerenza finale possono variare, tra cui 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 di cluster replicati completamente. Puoi inserire i cluster di istanza in qualsiasi combinazione di zone all'interno di qualsiasi regione offerta da Google Cloud. Puoi aggiungere e rimuovere cluster da un'istanza con un impatto minimo su altri cluster nell'istanza.
In Bigtable, le scritture vengono eseguite (con coerenza lettura/scrittura) su un singolo cluster e alla fine saranno coerenti negli altri cluster di istanza. Poiché le singole celle vengono sottoposte al controllo delle versioni in base al timestamp, le operazioni di scrittura non vanno perse 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.
Assistenza per le transazioni
Sebbene nessuno dei due database supporti transazioni complesse su più righe, ciascuno supporta alcune transazioni.
Cassandra dispone di un metodo transazione leggera (LWT) che fornisce l'atomicità per gli aggiornamenti dei valori delle colonne in un'unica partizione. Cassandra ha anche una semantica confronta e imposta che completa l'operazione di lettura delle righe e il confronto dei valori prima dell'avvio di una scrittura.
Bigtable supporta scritture a riga singola completamente coerente all'interno di un cluster. Le transazioni su riga singola vengono ulteriormente abilitate tramite le operazioni di lettura, modifica, scrittura e check-and-mutate. I profili di applicazione di routing a cluster multipli non supportano le transazioni su riga singola.
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 sono classificati come archivi a colonna larga NoSQL.
In Cassandra, devi utilizzare CQL per creare in anticipo lo schema completo della tabella, inclusa la definizione della chiave primaria, i nomi delle colonne e i relativi tipi. Le chiavi primarie in Cassandra sono valori composti univoci composti da una chiave di partizione obbligatoria e una chiave del cluster facoltativa. La chiave di partizione determina il posizionamento dei nodi di una riga, mentre la chiave del cluster determina l'ordinamento all'interno di una partizione. Quando crei schemi, devi conoscere i potenziali compromessi tra l'esecuzione di analisi efficienti all'interno di una singola partizione e i costi di sistema associati al mantenimento di partizioni di grandi dimensioni.
In Bigtable, è necessario creare la tabella e definire in anticipo le famiglie di colonne. Le colonne non vengono dichiarate quando vengono create le tabelle, ma vengono create quando le chiamate API dell'applicazione aggiungono celle alle righe della tabella.
Le chiavi di riga sono ordinate lessicograficamente nel cluster Bigtable. I nodi all'interno di Bigtable bilanciano automaticamente la responsabilità per gli intervalli chiave, spesso indicati come tablet e talvolta come split. Le chiavi di riga Bigtable sono spesso composte da diversi valori di campo che vengono uniti utilizzando un carattere separatore di uso comune e scelto da te (ad esempio il segno di percentuale). Se separati, i singoli componenti delle stringhe 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 nell'intera tabella. Puoi creare chiavi multiparte 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 di riga 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 siano archiviate 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 di colonna inviati dal client. Le librerie client forniscono metodi di supporto per scrivere i valori delle celle come byte, stringhe con codifica UTF-8 e numeri interi a 64 bit con codifica Big Endian (i numeri interi codificati in big-endian sono obbligatori per le operazioni di incremento atomico).
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, anche se le tabelle spesso ne hanno di più (il limite è di 100 famiglie di colonne per tabella). Devi creare famiglie di colonne in modo esplicito prima che un'applicazione possa utilizzarle in un'operazione.
Qualificatori di colonna
Ogni valore archiviato in una tabella in una chiave di riga è associato a un'etichetta denominata 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.
Celle
In Bigtable, una cella è l'intersezione tra la chiave di riga e il 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 precedenti 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 è necessario un indice, ti consigliamo di utilizzare una struttura di tabella che utilizzi una seconda tabella con una chiave di riga diversa.
Bilanciamento del carico e failover client
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 informa i criteri sui data center più vicini all'applicazione e il client identifica i nodi di questi 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 di applicazione) fornito con ogni operazione. I profili di applicazione vengono gestiti all'interno del servizio Bigtable; le operazioni client che non selezionano un profilo utilizzano un profilo predefinito.
Bigtable ha due tipi di criteri di routing dei profili di applicazione: a cluster singolo e multi-cluster. Un profilo multi-cluster instrada le operazioni al cluster più vicino disponibile. I cluster nella stessa regione sono considerati equidistanti dal punto di vista del router dell'operazione. 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.
In termini di Cassandra, un criterio multi-cluster offre i vantaggi di failover di un criterio di bilanciamento del carico che riconosce i data center.
Un profilo di applicazione con routing a cluster singolo indirizza tutto il traffico a un singolo 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 usata la chiave di riga.
In Cassandra, il client prima controlla 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 gestisce i dati dalla partizione vnode di destinazione; in caso contrario, il coordinatore è un nodo casuale. Il nodo coordinatore identifica i nodi in cui si trovano le repliche dei dati per la chiave di partizione dell'operazione e fornisce loro istruzioni per eseguire l'operazione.
In Bigtable, come discusso in precedenza, ogni operazione include un identificatore del profilo di applicazione. Il profilo dell'applicazione viene definito a livello di servizio. Il livello di routing di Bigtable esamina il profilo per scegliere il cluster di destinazione appropriato per l'operazione. Il livello di routing fornisce quindi un percorso che consente all'operazione di raggiungere i nodi di elaborazione corretti utilizzando la chiave di riga dell'operazione.
Processo di scrittura dati
Entrambi i database sono ottimizzati per scritture rapide e utilizzano un processo simile per completarne una. Tuttavia, i passaggi eseguiti dai database variano leggermente, in particolare per Cassandra dove, a seconda del livello di coerenza dell'operazione, potrebbe essere necessaria la comunicazione con altri nodi partecipanti.
Dopo che la richiesta di scrittura viene instradata ai nodi appropriati (Cassandra) o al nodo (Bigtable), le scritture vengono prima rese persistenti su disco in sequenza in un log del 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 è completa. In Cassandra, diverse repliche (a seconda del livello di coerenza specificato per ogni operazione) devono rispondere prima che il coordinatore comunichi al client che la scrittura è stata completata. In Bigtable, poiché ogni chiave di riga è assegnata a un solo nodo in qualsiasi momento, è sufficiente una risposta dal nodo per confermare l'esito positivo di una scrittura.
Successivamente, se necessario, puoi svuotare il file memtable su disco sotto forma di una nuova tabella SSTable. In Cassandra, lo svuotamento si verifica quando il log di commit raggiunge una dimensione massima o quando la variabile supera una soglia da te configurata. In Bigtable, viene avviato uno svuotamento per creare nuove tabelle SSTable immutabili quando la tabella memtable raggiunge la dimensione massima specificata dal servizio. Periodicamente, un processo di compattazione unisce le SSTable per un dato 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 ogni 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 di riga univoco e di una colonna viene modificato, l'aggiornamento viene mantenuto come descritto in precedenza nella sezione Processo di scrittura dati. Il timestamp di scrittura viene archiviato insieme al valore nella struttura SSTable.
Se non hai svuotato una cella aggiornata in una SSTable, puoi archiviare solo il valore della cella nella tabella memtable, ma i database differiscono in base a ciò che viene archiviato. Cassandra salva solo il valore più recente nella tabella condivisibile, mentre Bigtable salva tutte le versioni nella tabella condivisibile.
In alternativa, se hai svuotato almeno una versione di un valore di cella su disco in SSTable separate, i database gestiscono le richieste per quei 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, vince l'ultima scrittura. In Bigtable, vengono utilizzati filtri per controllare quali versioni delle celle vengono restituite da una richiesta di lettura.
Operazioni di eliminazione righe
Poiché entrambi i database utilizzano file SSTable immutabili per rendere i dati persistenti su 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 tomba tombale in Cassandra) viene aggiunto prima al memtable. Alla fine, una tabella SSTable appena scritta conterrà un indicatore con timestamp che indica che l'identificatore di 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 solo per una colonna o per una tabella, mentre in Bigtable puoi impostare solo i TTL per la famiglia di colonne. Per Bigtable esiste un metodo in grado di simulare il TTL a livello di cella.
Garbage collection
Poiché gli aggiornamenti o le eliminazioni immediate dei dati non sono possibili con le tabelle SSTable immutabili, come discusso in precedenza, la garbage collection avviene durante un processo chiamato compazione. Il processo rimuove le celle o le righe che non devono essere pubblicate nei risultati della 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 riga non è inclusa nella SSTable risultante. Entrambi i database possono escludere una cella dalla tabella SSTable unita. Se il timestamp della cella supera un'idoneità 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, il processo di lettura per ottenere i dati per soddisfare il risultato di una query è lo stesso per entrambi i database.
Per ogni SSTable su disco che potrebbe contenere risultati della query, viene controllato un filtro Bloom per determinare se ogni file contiene righe da restituire. Poiché i filtri Bloom non forniscono mai un falso negativo, tutte le SSTable idonee vengono aggiunte a un elenco di candidati per essere incluse in un'ulteriore elaborazione dei risultati di lettura.
L'operazione di lettura viene eseguita utilizzando una vista unita creata dal database e dalle SSTables candidate su disco. Poiché tutte le chiavi sono ordinate lessicograficamente, è efficiente ottenere una vista unita che viene analizzata per ottenere i risultati delle query.
In Cassandra, deve partecipare all'operazione un insieme di nodi di elaborazione determinati dal livello di coerenza dell'operazione. In Bigtable, è necessario consultare solo il nodo responsabile dell'intervallo di chiavi. Per Cassandra, devi considerare le implicazioni per il dimensionamento di calcolo, perché è 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 prevede che le colonne nella chiave primaria o le colonne incluse in un indice secondario possano essere utilizzate per limitare i risultati.
Bigtable offre un assortimento variegato di filtri che interessano le righe o le celle recuperate da una query di lettura.
Esistono tre categorie di filtri:
- Filtri di limitazione, che controllano le righe o le celle che la risposta include.
- Modificare i filtri, che influiscono sui dati o sui metadati di singole celle.
- Combinare più filtri in un unico filtro.
I filtri di limitazione 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 durante una fase di compattazione. La compressione dei dati SSTable offre vantaggi simili in quanto riduce le 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, dovresti capire in che modo ogni database archivia 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
- La durabilità dei dati e il meccanismo di replica
Distribuzione dei dati
In Cassandra, un hash coerente delle colonne di partizione della chiave primaria è il metodo consigliato per determinare la distribuzione dei dati nelle varie SSTables servite dai nodi del cluster.
Bigtable utilizza un prefisso variabile alla chiave di riga completa per inserire i dati in SSTables in modo lessicografico.
Versioni cella
Cassandra conserva una sola versione attiva del valore della cella. Se vengono effettuate due scritture su una cella, un criterio last-write-wins 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 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 può essere filtrato in un set di risultati di query tramite l'API.
Spazio di archiviazione su disco
Cassandra archivia le tabelle SSTable sui dischi collegati a ciascun nodo cluster. Per riequilibrare i dati in Cassandra, i file devono essere fisicamente copiati tra i server.
Bigtable utilizza Colossus per archiviare le SSTable. Poiché Bigtable utilizza questo file system distribuito, il servizio può riassegnare quasi istantaneamente SSTables a nodi diversi.
Durabilità e replica dei dati
Cassandra fornisce la durabilità dei dati tramite l'impostazione del fattore di replica. Il fattore di replica determina il numero di copie SSTable archiviate su nodi diversi nel cluster. Un'impostazione tipica del fattore di replica è 3, che consente comunque di garantire una maggiore coerenza con QUORUM o LOCAL_QUORUM anche in caso di errore del nodo.
Con Bigtable, la replica fornita da Colossus garantisce un'elevata durabilità dei dati.
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, ogni nodo è assegnato per gestire i dati archiviati in una serie di SSTable. Queste SSTable contengono i dati per gli intervalli di chiave di riga assegnati dinamicamente a ciascun nodo. Mentre il diagramma mostra tre SSTable per ciascun nodo, è probabile che ce ne siano di più perché le 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 immediatamente rese persistenti 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 siano resi persistenti in una SSTable per l'intervallo di righe.
Interfacce dell'applicazione
In origine, l'accesso al database Cassandra era esposto tramite un'API Thrift, ma questo metodo di accesso è deprecato. L'interazione del client consigliata è tramite CQL.
Analogamente all'API Thrift originale di Cassandra, l'accesso al database Bigtable è 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 CLI
, sia librerie client che supportano molti linguaggi di programmazione
comuni. Queste librerie sono basate sulle API REST e gRPC. Le applicazioni scritte per Hadoop e si basano sulla libreria open source Apache HBase per Java possono connettersi senza cambiamenti significativi a Bigtable. Per le applicazioni che non richiedono la compatibilità con HBase, consigliamo di utilizzare il client Java integrato Bigtable.
I controlli di gestione di identità e accessi (IAM) di Bigtable sono completamente integrati con Google Cloud e le tabelle possono essere utilizzate anche come origine dati esterna di BigQuery.
Configurazione del database
Quando configuri un cluster Cassandra, devi prendere diverse decisioni di configurazione e devi completare i passaggi da completare. Innanzitutto, devi configurare i nodi del server per fornire capacità di calcolo ed eseguire il provisioning dello spazio di archiviazione locale. Quando utilizzi un fattore di replica pari a 3, che è l'impostazione consigliata e più comune, devi eseguire il provisioning dello spazio di archiviazione in modo da archiviare tre volte la quantità di dati che prevedi di conservare nel cluster. Devi inoltre determinare e impostare le configurazioni per vnode, rack e replica.
La separazione del calcolo dall'archiviazione in Bigtable semplifica la scalabilità dei cluster verso l'alto e verso il basso rispetto a Cassandra. In un cluster in esecuzione normalmente, in genere ti interessa 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 le dimensioni del cluster Bigtable in caso di sovra o sottoprovisioning in base al carico di produzione.
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 l'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 tieni conto delle esigenze di archiviazione con Bigtable, non devi tenere conto delle repliche di archiviazione come faresti per le dimensioni di un cluster Cassandra. Non comporta alcuna perdita di densità dello spazio 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à di 5 TB del nodo SSD, preferita per la maggior parte dei carichi di lavoro, fornisce una densità di archiviazione maggiore 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 solo una copia dei dati; in confronto, Cassandra deve tenere conto di tre copie dei dati nella maggior parte delle configurazioni.
Sebbene il valore QPS di scrittura per SSD sia più o meno uguale a quello per HDD, SSD fornisce un valore QPS di lettura notevolmente più elevato rispetto all'HDD. Il prezzo dell'archiviazione SSD è simile o prossimo ai costi dei dischi permanenti SSD di cui è stato eseguito il provisioning e varia in base alla regione.
HDD
Il tipo di archiviazione HDD consente una notevole densità di archiviazione: 16 TB per ogni nodo. Tuttavia, le letture casuali sono molto più lente, in quanto supportano solo 500 righe lette al secondo per ogni nodo. HDD è l'ideale per carichi di lavoro ad alta intensità di scrittura, in cui le letture dovrebbero essere analisi di intervalli associate all'elaborazione batch. L'archiviazione HDD ha un costo pari o prossimo al costo associato a Cloud Storage e varia a seconda della regione.
Considerazioni sulle dimensioni del cluster
Quando definisci le dimensioni di un'istanza Bigtable per prepararti alla migrazione di un carico di lavoro Casssandra, devi tenere conto di alcuni aspetti quando confronti i cluster Casssandra a un singolo data center con le istanze Bigtable a cluster singolo e i cluster a più data center Cassandra a istanze Bigtable multi-cluster. Le linee guida nelle sezioni seguenti presuppongono che non siano necessarie modifiche significative al modello dei dati per eseguire la migrazione e che esista una compressione dello spazio di archiviazione equivalente tra Cassandra e Bigtable.
un cluster con un singolo data center
Quando confronti un cluster di un singolo data center con un'istanza Bigtable a cluster singolo, devi prima considerare i requisiti di archiviazione. È possibile stimare la dimensione non replicata di ogni spazio delle chiavi utilizzando il comando nodetool tablestats e dividendo le dimensioni totali dello spazio di archiviazione svuotato per il fattore di replica dello spazio delle chiavi. Quindi, dividi la quantità di archiviazione non replicata di tutti gli spazi delle chiavi per 3,5 TB (5 TB * 0,70) per determinare il numero suggerito di nodi SSD per gestire l'archiviazione da sola. Come discusso, Bigtable gestisce la replica e la durabilità dello spazio di archiviazione all'interno di un livello separato trasparente per l'utente.
Poi devi considerare i requisiti di calcolo per il numero di nodi. Puoi consultare le metriche del server e delle applicazioni client Cassandra 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 carico di lavoro, dividi questa metrica per 10.000. Probabilmente avrai bisogno di più nodi per le applicazioni che richiedono risultati delle 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 tuo carico di lavoro.
Il numero di nodi richiesto per il cluster deve essere uguale al maggiore tra le esigenze di archiviazione e calcolo. Se hai dubbi sulle tue esigenze di archiviazione o velocità effettiva, puoi abbinare il numero di nodi Bigtable al numero di tipiche macchine Cassandra. 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 con più data center
Con cluster con più data center, è più difficile determinare la configurazione di un'istanza Bigtable. Idealmente, dovresti avere un cluster nell'istanza per ogni data center della 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 creare cluster in un'istanza in qualsiasi regione cloud supportata in tutto il mondo.
La tecnica per stimare le esigenze di archiviazione è simile all'approccio per i cluster di un singolo data center. Utilizzerai nodetool per acquisire le dimensioni di archiviazione di ogni spazio delle chiavi nel cluster Cassandra, quindi le dividerai per il numero di repliche. Tieni presente che lo spazio delle chiavi 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 sul 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 nell'iniziare con tutti i cluster che hanno la capacità di nodi equivalente del data center più trafficato nel cluster Cassandra. È possibile 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 più comuni eseguite in Cassandra.
Backup e ripristino
Bigtable offre due metodi per soddisfare le esigenze di backup più comuni: backup di Bigtable ed esportazioni dei dati gestite.
I backup di Bigtable sono analoghi a una versione gestita della funzionalità snapshot nodetool di Cassandra.
I backup di Bigtable creano copie ripristinabili di una tabella, archiviate come oggetti membri 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 che crei tramite questa utilità non consumano risorse dei nodi e hanno un prezzo simile o uguale a quello di Cloud Storage. Puoi richiamare i backup di Bigtable
a livello di programmazione 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 esportarli nei formati di file Avro, Parquet o Sequenza Hadoop. Rispetto ai backup di Bigtable, le esportazioni richiedono più tempo per essere eseguite e comportano costi di calcolo aggiuntivi perché 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 archiviazione e computing, puoi aggiungere o rimuovere nodi Bigtable in risposta alla domanda di query in modo più semplice rispetto a Cassandra. L'architettura omogenea di Cassandra richiede di ribilanciare i nodi (o vnodi) tra le macchine nel cluster.
Puoi modificare le dimensioni del cluster manualmente nella console Google Cloud o in modo programmatico utilizzando l'API Cloud Bigtable. L'aggiunta di nodi a un cluster può ottenere miglioramenti significativi delle prestazioni in pochi minuti. Alcuni clienti hanno utilizzato con successo un gestore della scalabilità automatica open source sviluppato da Spotify.
Manutenzione interna
Il servizio Bigtable gestisce perfettamente le attività di manutenzione interna comuni di Cassandra, come l'applicazione di patch al 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 delle metriche o agli avvisi non richiede attività di amministrazione o sviluppo. La pagina della console Google Cloud di Bigtable include 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.
Key Visualizer di Bigtable, una funzionalità di monitoraggio della console Google Cloud, consente di eseguire l'ottimizzazione avanzata delle prestazioni.
IAM e sicurezza
In Bigtable, l'autorizzazione è completamente integrata nel framework IAM di Google Cloud e richiede configurazione e manutenzione minime. Gli account utente e le password locali non vengono condivisi con le applicazioni client. Al contrario, vengono concessi autorizzazioni e ruoli granulari 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 amministratori 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 di Bigtable per gli utenti Cassandra.
- Scopri di più sull'emulatore di Bigtable.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.