Questo documento è destinato agli sviluppatori di software e agli amministratori di database che intendono eseguire la migrazione di applicazioni esistenti o progettare nuove applicazioni da utilizzare con Bigtable come datastore. Questo documento applica la tua conoscenza di Apache Cassandra all'utilizzo di Cloud Bigtable.
Bigtable e Cassandra sono database distribuiti. Implementano store chiave-valore multidimensionali in grado di supportare decine di migliaia di query al secondo (QPS), archiviazione che scala fino a petabyte di dati e tolleranza per errori dei nodi.
Sebbene gli insiemi di funzionalità di questi database siano simili a un livello generale, le relative architetture sottostanti e i dettagli delle interazioni differiscono in modo importante. 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. Anche se questo documento fornisce un confronto tra i due database, puoi anche concentrarti sugli argomenti applicabili al tuo caso d'uso o ai tuoi interessi.
Confrontare due database maturi non è un compito semplice. Per raggiungere questo scopo, il documento esegue le seguenti operazioni:
- Confronta la terminologia, che può differire tra i due database.
- Fornisce una panoramica dei due sistemi di database.
- Esaminare come ogni database gestisce la modellazione dei dati per comprendere le diverse considerazioni di progettazione.
- Confronta il percorso seguito dai dati durante le operazioni di scrittura e lettura.
- Esaminare il layout dei dati fisici per comprendere gli aspetti dell'architettura del database.
- Descrive come configurare la replica geografica per soddisfare i requisiti e come affrontare il dimensionamento dei cluster.
- Esamina i dettagli su gestione dei cluster, monitoraggio e sicurezza.
Confronto della terminologia
Sebbene molti dei concetti utilizzati in Bigtable e Cassandra siano simili, ogni database presenta convenzioni di denominazione leggermente diverse e variazioni diverse.
Uno dei componenti di base di entrambi i database è la tabella di stringhe ordinate (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 ottimizzando al contempo carichi di lavoro di lettura/scrittura sequenziali.
La tabella seguente illustra e descrive i concetti condivisi e la terminologia corrispondente utilizzata da ogni prodotto:
| Cassandra | Bigtable |
|---|---|
|
chiave principale: un valore unico o a più campi 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 in base a un hash coerente. colonna di clustering: un valore a singolo campo o a più campi che determina l'ordinamento dei datilessicografici in una partizione. |
chiave di riga: una singola stringa di byte che determina il posizionamento dei dati in base a un ordinamentolessicografico. Le chiavi composite vengono imitate unendo i dati di più colonne utilizzando un delimitatore comune, ad esempio i simboli hash (#) o percentuale (%). |
| node: una macchina responsabile della lettura e della scrittura dei dati associata a una serie di intervalli hash di partizione della chiave primaria. In Cassandra, i dati vengono archiviati nell'archiviazione a livello di blocco collegata al server nodo. | node: una risorsa di calcolo virtuale responsabile della lettura e della scrittura dei dati associati a una serie di intervalli di chiave di riga. In Bigtable, i dati non vengono collocati insieme ai nodi di computing. Viene invece archiviato in Colossus, il file system distribuito di Google. Ai nodi è assegnata temporaneamente una responsabilità per la gestione di vari intervalli di dati in base al carico delle operazioni e all'integrità di altri nodi nel cluster. |
|
data center: simile a un cluster Bigtable, ad eccezione di alcuni aspetti della topologia e della strategia di replica, sono configurabili in Cassandra. rack: un raggruppamento di nodi in un data center che influenza il posizionamento delle repliche. |
cluster: un gruppo di nodi nella stessa zona geografica Google Cloud, posizionato per problemi di latenza e replica. |
| cluster: un deployment Cassandra costituito da una raccolta di data center. | istanza: un gruppo di cluster Bigtable in diverse zone o regioni Google Cloud tra cui si verificano il routing della replica e della connessione. |
| vnode: un intervallo fisso di valori hash assegnati a un nodo fisico specifico. I dati in un vnode vengono archiviati fisicamente sul nodo Cassandra in una serie di SSTables. | tablet: una tabella SSTable contenente tutti i dati per un intervallo contiguo di chiavi di riga ordinate in modoLexicografico. I tablet non vengono archiviati sui nodi di Bigtable, ma sono archiviati in una serie di SSTables su Colossus. |
| fattore di replica: il numero di repliche di un nodo che vengono mantenute su tutti i nodi del data center. Il fattore di replica è configurato in modo indipendente per ogni data center. | replica: il processo di replica dei dati archiviati in Bigtable in tutti i cluster dell'istanza. La replica all'interno di un cluster di zona è gestita dal livello di archiviazione Colossus. |
| tabella (in precedenza famiglia di colonne): un'organizzazione logica di valori indicizzati dalla chiave primaria univoca. | tabella: un'organizzazione logica di valori indicizzati dalla chiave di riga univoca. |
| keyspace: uno spazio dei nomi logico per la tabella che definisce il fattore di replica per le tabelle che contiene. | Non applicabile. Bigtable gestisce i problemi degli spazi chiave in modo trasparente. |
| Non applicabile | qualificatore colonna: un'etichetta per un valore archiviato in una tabella indicizzata dalla chiave di riga univoca. |
| Non applicabile | famiglia di colonne: uno spazio dei nomi specificato dall'utente che raggruppa i qualificatori di colonna per operazioni di lettura e scrittura più efficienti. |
| column: l'etichetta di un valore archiviato in una tabella indicizzata dalla chiave primaria univoca. | column: l'etichetta di un valore archiviato in una tabella indicizzata dalla chiave di riga univoca. Il nome 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 di timestamp in una tabella associato all'intersezione di una chiave di riga con il nome della colonna. È possibile archiviare e recuperare più versioni con timestamp per ogni cella. |
| criterio di bilanciamento del carico: un criterio che configuri nella logica dell'applicazione per instradare le operazioni a un nodo appropriato nel cluster. Il criterio tiene conto degli intervalli di token di nodi e topologia dei data center. | profilo applicazione: impostazioni che indicano a Bigtable come instradare una chiamata API client al cluster appropriato nell'istanza. Puoi anche utilizzare il profilo dell'applicazione come tag per segmentare le metriche. Configura il profilo dell'applicazione nel servizio. |
| CQL: il linguaggio di query CSS, un linguaggio come SQL utilizzato per la creazione delle tabelle, le modifiche allo schema, le mutazioni di riga e le query. | API Bigtable: le librerie client e le API gRPC utilizzate per la creazione di istanze e cluster, la creazione di tabelle di tabelle e colonne, le mutazioni di riga e le query. |
Panoramiche sui 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 nel documento Bigtable: A Distributed Storage System for Structured Data. Bigtable separa i nodi di computing, che gestiscono le richieste del client, dalla gestione dello spazio di archiviazione sottostante. I dati vengono archiviati su Colossus. Il livello di archiviazione replica automaticamente i dati per fornire una durabilità superiore ai livelli forniti dalla replica a tre vie Hadoop Distributed File System (HDFS).
Questa architettura fornisce letture e scritture coerenti all'interno di un cluster, offre scale up e scale down senza alcun costo di ridistribuzione dello spazio di archiviazione e può ribilanciare i carichi di lavoro senza modificare il cluster o lo schema. Se un nodo di elaborazione dati subisce una compromissione, il servizio Bigtable lo sostituisce in modo trasparente. Bigtable supporta anche la replica asincrona tra i cluster distribuiti geograficamente in topologie fino a quattro cluster in diverse zone o regioni Google Cloud in tutto il mondo.
Oltre alle librerie client e gRPC per vari linguaggi di programmazione, Bigtable mantiene la compatibilità con la libreria open source ApacheHBase Libreria client Java, un'implementazione alternativa del motore del database open source della carta 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 che il ribilanciamento dell'assegnazione dell'intervallo è obbligatorio 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 ribilanciamento dell'intervallo di chiavi e un ridimensionamento di un cluster:
L'immagine Rebalancing illustra 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 aver eseguito il ribilanciamento, il nodo centrale, anziché il nodo più a sinistra, è responsabile della gestione 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 di set di dati con un numero maggiore di nodi di elaborazione disponibili. L'immagine Ridimensionamento mostra lo stato del cluster Bigtable dopo aver aggiunto un nodo.
Cassandra
Apache Cassandra è un database open source in parte influenzato dai concetti dell'articolo di Bigtable. Utilizza un'architettura di nodi distribuiti, in cui l'archiviazione viene collocata insieme ai server che rispondono alle operazioni sui dati. Una serie di nodi virtuali (vnodi) viene assegnata in modo casuale a ciascun server per gestire una parte dello spazio delle chiavi del cluster.
I dati vengono archiviati nei vnodi in base alla chiave di partizione. In genere, viene utilizzata una funzione hash coerente per generare un token per determinare il posizionamento dei dati. Come con Bigtable, puoi utilizzare un partizionatore per la conservazione degli ordini per la generazione di token, quindi anche per il posizionamento dei dati. Tuttavia, la documentazione di Cassandra sconsiglia questo approccio perché è probabile che il cluster non venga bilanciato, una condizione difficile da risolvere. Per questo motivo, questo documento presuppone che utilizzi una strategia di hashing coerente per generare token che determinano la distribuzione dei dati tra i nodi.
Cassandra offre tolleranza di errore attraverso livelli di disponibilità correlati al livello di coerenza sintonizzabile, che consentono a un cluster di gestire i client mentre uno o più nodi sono compromessi. Puoi definire la replica geografica tramite una strategia di topologia di replica dei dati configurabile.
Specifica un livello di coerenza per ogni operazione. L'impostazione tipica è QUORUM (o LOCAL_QUORUM in alcune topologie di più data center). Questa
impostazione a livello di coerenza richiede che la maggioranza dei nodi di replica risponda al nodo
coordinatore affinché l'operazione venga considerata riuscita. Il fattore di replica configurato per ogni spazio delle chiavi determina il numero di repliche di dati archiviate in ogni data center nel cluster. Ad esempio, è in genere utilizzare un valore di fattore di replica di 3 per fornire un equilibrio pratico
tra durabilità e volume di archiviazione.
Il seguente diagramma mostra in termini semplificati un cluster di sei nodi con l'intervallo di chiavi di ogni nodo diviso in cinque nodi. In pratica, puoi avere più nodi e probabilmente avrai più nodi.
Nel diagramma precedente puoi vedere il percorso di un'operazione di scrittura, con un livello di coerenza QUORUM, che proviene da un'applicazione o un servizio client (client). Ai fini di questo diagramma, gli intervalli chiave sono mostrati come intervalli alfabetici. In realtà, i token prodotti da un hash della chiave primaria sono numeri interi firmati molto grandi.
In questo esempio, l'hash della chiave è M e i nodi per M sono sui nodi 2, 4 e 6. Il coordinatore deve contattare ogni nodo in cui sono archiviati localmente gli intervalli di chiavi chiave, in modo da poter elaborare la scrittura. Poiché il livello di coerenza è QUORUM, due repliche (la maggior parte) devono rispondere al nodo del coordinatore prima che il client riceva una notifica di completamento della scrittura.
A differenza di Bigtable, lo spostamento o la modifica degli intervalli di chiavi in Cassandra richiede che tu copi fisicamente i dati da un nodo a un altro. Se un nodo è sovraccarico con richieste per un determinato intervallo di hash di token, aggiungere l'elaborazione per quell'intervallo di token non è così semplice in Cassandra quanto lo è in Bigtable.
Replica e coerenza geografica
Bigtable e Cassandra gestiscono la replica e la coerenza geografica (nota anche come più aree geografiche) in modo diverso. Un cluster Cassandra è costituito da nodi di elaborazione raggruppati in rack, che vengono invece raggruppati in data center. Cassandra utilizza una strategia di topologia di rete configurata per determinare il modo in cui le repliche dei nodi vengono 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 ogni data center nel cluster.
Cassandra utilizza configurazioni di data center e rack per migliorare la tolleranza di errore delle repliche di dati. Durante le operazioni di lettura e scrittura, la topologia determina i nodi dei partecipanti necessari per fornire garanzie di coerenza. Devi configurare manualmente i nodi, i rack e i data center quando crei o estendi un cluster. In un ambiente cloud, un tipico deployment di Cassandra considera una zona cloud come un rack e una regione cloud come un data center.
Puoi utilizzare i controlli del quorum di Cassandra per regolare le garanzie di coerenza per ogni operazione di lettura o scrittura. I livelli di resistenza dell'coerenza finale possono variare, comprese 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 un massimo di quattro cluster 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 nell'istanza.
In Bigtable, le scritture vengono eseguite (con coerenza read-your-writes) su un singolo cluster e alla fine saranno coerenti negli altri cluster di istanze. Poiché alle singole celle viene applicato il controllo delle versioni in base al timestamp, ogni scrittura non viene persa e ogni cluster gestisce le celle con i timestamp più recenti disponibili.
Il servizio espone lo stato di coerenza del cluster. L'API Cloud Bigtable offre 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 delle transazioni
Sebbene nessuno dei due database supporti le transazioni multiriga complesse, ciascuna supporta alcune transazioni.
Cassandra utilizza un metodo di transizione leggera (LWT) che fornisce atomicità per gli aggiornamenti ai valori di colonna in una singola partizione. Prima di iniziare una scrittura, Cassandra ha anche la semantica confronta e imposta che completano la lettura delle righe e il confronto dei valori.
Bigtable supporta scritture a riga singola completamente coerenti all'interno di un cluster. Le transazioni per riga singola vengono ulteriormente abilitate tramite le operazioni di lettura, modifica e scrittura e di controllo e modifica. I profili di applicazione di routing a cluster multipli non supportano le transazioni su riga singola.
Modello dati
Bigtable e Cassandra organizzano i dati in tabelle che supportano le ricerche e le scansioni degli 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 che consistono in 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 a conoscenza dei potenziali compromessi tra l'esecuzione di scansioni efficienti all'interno di una singola partizione e i costi di sistema associati alla gestione di partizioni di grandi dimensioni.
In Bigtable, devi solo creare la tabella e definire 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 delle tabelle.
Le chiavi di riga sono ordinate in modo alfabetico nel cluster Bigtable. I nodi all'interno di Bigtable bilanciano automaticamente la responsabilità nodale per gli intervalli di chiavi, spesso chiamati tablet e talvolta come divide. Le chiavi di riga Bigtable sono spesso costituite da diversi valori di campo che sono uniti utilizzando un carattere di separatore di uso comune che scegli (ad esempio un segno percentuale). Se separati, i singoli componenti della stringa sono analoghi ai campi di una chiave primaria Cassandra.
Progettazione di chiavi a riga
In Bigtable, l'identificatore univoco di una riga della tabella è la chiave della riga. La chiave di riga deve essere un singolo valore univoco in un'intera tabella. Puoi creare chiavi composte da più parti concatenando elementi disparati separati da un delimitatore comune. La chiave di riga determina l'ordinamento globale dei dati in una tabella. Il servizio Bigtable determina in modo dinamico gli intervalli di chiavi assegnati a ciascun nodo.
A differenza di Cassandra, dove l'hash della chiave di partizione determina il posizionamento della riga e le colonne di clustering determinano l'ordinamento, la chiave della riga Bigtable fornisce sia l'assegnazione nodale che l'ordinamento. Come in Cessandra, 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 tipi di dati di colonna inviati dal client. Le librerie client forniscono metodi di supporto per scrivere i valori delle celle sotto forma di byte, stringhe con codifica UTF-8 e numeri interi a 64 bit big-endian (sono richiesti numeri interi con codifica big-endian per 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 deve avere almeno una famiglia di colonne, anche se spesso ne sono dotate (il limite è di 100 famiglie di colonne per ogni tabella). Devi creare esplicitamente le famiglie di colonne prima che un'applicazione possa utilizzarle in un'operazione.
Qualificatori della colonna
Ogni valore archiviato in una tabella all'interno di 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 dell'applicazione.
Cellule
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 delle celle precedenti vengono recuperati in base a un criterio di garbage collection configurato a livello di famiglia di colonne.
Indici secondari
Bigtable non supporta gli indici secondari. Se è richiesto un indice, consigliamo di utilizzare una progettazione della tabella che utilizzi una seconda tabella con una chiave di riga diversa.
Bilanciamento del carico e failover del carico dei client
In Cassandra, il client controlla il bilanciamento del carico delle richieste. Il driver client imposta un criterio specificato come parte della configurazione o a livello di programmazione durante la creazione della sessione. Il cluster definisce il criterio relativo ai data center più vicini all'applicazione e il client identifica i nodi di questi data center allo scopo di 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) che viene fornito con ogni operazione. I profili di applicazione vengono gestiti all'interno del servizio Bigtable; le operazioni del client che non selezionano un profilo utilizzano un profilo predefinito.
Bigtable ha due tipi di criteri di routing dei profili di applicazioni: cluster singolo e multi-cluster. Un profilo multi-cluster instrada le operazioni al cluster più vicino disponibile. I cluster nella stessa area geografica sono considerati equidistanti dal punto di vista del router 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 fornisce i vantaggi del failover di un criterio di bilanciamento del carico che sia a conoscenza dei 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 è necessario eseguire manualmente il failover dei profili di routing a cluster singolo interessati.
Routing dell'operazione
Cassandra e Bigtable utilizzano metodi diversi per selezionare il nodo di elaborazione per le operazioni di lettura e scrittura. In Cassandra viene identificata la chiave di partizione, mentre in Bigtable viene utilizzata la chiave di riga.
In Cassandra, il client controlla prima il criterio di bilanciamento del carico. Questo oggetto lato client determina il data center al quale viene instradata l'operazione.
Dopo aver identificato il data center, Cassandra contatta un nodo coordinatore per gestire l'operazione. Se il criterio riconosce i token, il coordinatore è un nodo che serve i dati dalla partizione vnode di destinazione; in caso contrario, il coordinatore è un nodo casuale. Il nodo del coordinatore identifica i nodi in cui si trovano le repliche dei dati per la chiave di partizione dell'operazione, quindi indica ai nodi di eseguire l'operazione.
In Bigtable, come discusso in precedenza, ogni operazione include un identificatore del profilo di applicazione. Il profilo di applicazione è 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 per l'operazione per raggiungere i nodi di elaborazione corretti utilizzando la chiave di riga dell'operazione.
Processo di scrittura dati
Entrambi i database sono ottimizzati per le scritture veloci e utilizzano un processo simile per completare la scrittura. Tuttavia, i passaggi seguiti dai database sono leggermente diversi, soprattutto per Cassandra, dove, a seconda del livello di coerenza operativa, potrebbe essere necessaria la comunicazione con nodi nodo aggiuntivi.
Dopo che la richiesta di scrittura è stata instradata ai nodi appropriati (Cassandra) o al nodo (Bigtable), le scritture vengono prima archiviate sul disco in sequenza in un log di commit (Cassandra) o in un log condiviso (Bigtable). In seguito, le scritture vengono inserite in una tabella in memoria (nota anche come memtable) ordinata come le SSTables.
Dopo questi due passaggi, il nodo risponde per indicare che la scrittura è stata completata. In Cassandra, molte 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 un determinato momento, una risposta del nodo è sufficiente per confermare che una scrittura è riuscita.
Se necessario, in un secondo momento puoi svuotare il memoriale su disco sotto forma di una nuova SSTable. In Cassandra, lo svuotamento si verifica quando il log di commit raggiunge una dimensione massima o quando la memtable supera una soglia che hai configurato. In Bigtable, viene avviato un flush per creare nuove SSTable immutabili quando la 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 dati
Entrambi i database gestiscono gli aggiornamenti dei dati in modo simile. Tuttavia, Cassandra consente un solo valore per cella, mentre Bigtable può mantenere un numero elevato di valori sottoposti a controllo delle versioni per ogni cella.
Quando il valore all'intersezione di un identificatore di riga e di una colonna unici viene modificato, l'aggiornamento viene mantenuto come descritto in precedenza nella sezione Procedura di scrittura dei dati. Il timestamp di scrittura viene archiviato insieme al valore nella struttura SSTable.
Se non hai scaricato una cella aggiornata in una SSTable, puoi memorizzare solo il valore della cella nella memtable, ma i database variano in base ai contenuti archiviati. Cassandra salva solo il valore più recente nella memtable, mentre Bigtable salva tutte le versioni al suo interno.
In alternativa, se hai scaricato almeno una versione di un valore di cella su un disco in SSTable separate, i database gestiscono le richieste in modo diverso. Quando viene richiesta la cella a Cassandra, viene restituito solo il valore più recente in base al timestamp; in altre parole, vince l'ultima scrittura. In Bigtable, puoi utilizzare i filtri per controllare quali versioni delle celle vengono restituite da una richiesta di lettura.
Eliminazioni di righe
Poiché entrambi i database utilizzano file SSTable immutabili per salvare i dati su disco, non è possibile eliminare una riga immediatamente. 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 a Cassandra) viene aggiunto per primo alla memoria. Alla fine, una nuova tabella SSTable contiene un indicatore con timestamp che indica che l'identificatore di riga univoco viene eliminato e non deve essere restituito nei risultati della query.
Durata
Le funzionalità di durata (TTL) nei due database sono simili, ad eccezione di una disparità. In Cassandra puoi impostare il TTL per una colonna o una tabella, mentre in Bigtable puoi impostare solo TTL 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 SSSS immutabili, come detto in precedenza, la garbage collection si verifica 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 viene inclusa nella SSTable risultante. Entrambi i database possono escludere una cella dall'SSTable 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 dati
Quando un'operazione di lettura raggiunge il nodo di elaborazione appropriato, la procedura di lettura per ottenere i dati per soddisfare il risultato di una query è la stessa per entrambi i database.
Per ogni SSTable su disco che potrebbe contenere risultati di query, viene controllato un filtro Fioritura 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 da includere nell'ulteriore elaborazione dei risultati di lettura.
L'operazione di lettura viene eseguita utilizzando una vista unita creata dalla memtable e le SSTables candidati su disco. Poiché tutte le chiavi sono ordinate in base letterale, è efficiente ottenere una vista unita che venga analizzata per ottenere i risultati delle query.
In Cassandra deve partecipare 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 del calcolo perché è probabile che più nodi elaboreranno 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 delle colonne incluse in un indice secondario potrebbero essere utilizzate per limitare i risultati.
Bigtable offre un assortimento di filtri avanzati che interessano le righe o le celle recuperate da una query di lettura.
Esistono tre categorie di filtri:
- Limitazione dei filtri, che controllano le righe o le celle incluse nella risposta.
- Modificare i filtri, che interessano i dati o i metadati per le singole celle.
- Filtri che permettono di combinare più filtri in un unico filtro.
I filtri limitati sono quelli più comunemente utilizzati, ad esempio l'espressione regolare della famiglia di colonne e l'espressione regolare del qualificatore di colonna.
Archiviazione dati fisici
Bigtable e Cassandra archiviano i dati in SSTables, che vengono uniti regolarmente durante una fase di compattazione. La compressione dei dati SSTable offre vantaggi simili per ridurre 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 comprendere in che modo ciascun database archivia fisicamente i dati in modo diverso nei seguenti aspetti:
- Strategia di distribuzione dei dati
- Il numero di versioni di cella disponibili
- Il tipo di disco di archiviazione
- Meccanismo di replica e durabilità dei dati
Distribuzione dei dati
In Cassandra, un hash coerente delle colonne di partizione della chiave primaria è il metodo consigliato per determinare la distribuzione dei dati tra le varie SSTable gestite dai nodi del cluster.
Bigtable utilizza un prefisso di variabile per la chiave di riga intera al fine di posizionare i dati in stileLexicografico in SSTables.
Versioni della cella
Cassandra conserva una sola versione attiva del valore di una cella. Se vengono effettuate due scritture in 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 dimensioni delle righe. Se non viene impostato dalla richiesta client, il timestamp è 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 ogni famiglia di colonne di una tabella oppure essere filtrate da un set di risultati di query tramite l'API.
Archiviazione su disco
Cassandra archivia gli oggetti SSTable su dischi collegati a ogni nodo del cluster. Per ribilanciare i dati in Cassandra, i file devono essere fisicamente copiati tra i server.
Bigtable utilizza Colossus per archiviare le tabelle SSTable. Poiché Bigtable utilizza questo file system distribuito, è possibile che il servizio Bigtable riassegni quasi istantaneamente le SSTable a nodi diversi.
Durabilità e replica dei dati
Cassandra garantisce la durabilità dei dati tramite l'impostazione del fattore di replica. Il fattore di replica determina il numero di copie di SSTable che sono archiviate su nodi diversi nel cluster. Un'impostazione tipica del fattore di replica è 3, che consente comunque garanzie di coerenza più elevata con QUORUM o LOCAL_QUORUM anche se si verifica un errore del nodo.
Con Bigtable, vengono fornite garanzie di elevata durabilità tramite la replica fornita da Colossus.
Il seguente diagramma illustra il layout dei dati fisici, i nodi di elaborazione di calcolo e il livello di routing per Bigtable:
Nel livello di archiviazione Colossus, ogni nodo viene assegnato per gestire i dati archiviati in una serie di SSTables. Le tabelle SSTab contengono i dati per gli intervalli di chiave di riga assegnati dinamicamente a ciascun nodo. Mentre il diagramma mostra tre SSTable per ogni nodo, è probabile che ce ne siano di più perché le tabelle SS vengono create continuamente man mano che i nodi ricevono nuove modifiche ai dati.
Ogni nodo ha un log condiviso. Le scritture elaborate da ogni nodo vengono trasferite immediatamente al log condiviso prima che il client riceva una conferma di scrittura. Poiché una scrittura in Colossus viene replicata più volte, la durabilità è garantita anche se si verifica un guasto hardware nodale prima che i dati vengano mantenuti in una SSTable per l'intervallo di righe.
Interfacce delle applicazioni
In origine, l'accesso al database di Cassandra veniva esposto tramite un'API Thrift, ma questo metodo di accesso era deprecato. L'interazione consigliata con il client è tramite CQL.
Analogamente all'API Thrift originale di Cassandra, l'accesso al database Bigtable è 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 interfaccia a riga di comando, sia librerie client che supportano molti comuni linguaggi di programmazione. Queste librerie si basano sulle API gRPC e REST. Le applicazioni scritte per Hadoop e che si basano sulla libreria open source Apache HAP per Java possono connettersi senza modifiche significative a Bigtable. Per le applicazioni che non richiedono la compatibilità HBase, ti consigliamo di utilizzare il client Java Bigtable Bigtable.
I controlli di Identity and Access Management (IAM) di Bigtable sono completamente integrati con Google Cloud e le tabelle possono essere utilizzate anche come origine dati esterna da BigQuery.
Configurazione del database
Quando configuri un cluster Cassandra, devi prendere varie decisioni di configurazione e i passaggi da completare. Innanzitutto, devi configurare i nodi del server per fornire la capacità di calcolo ed eseguire il provisioning dell'archiviazione locale. Quando utilizzi un fattore di replica tre, l'impostazione consigliata e più comune, devi eseguire il provisioning dello spazio di archiviazione per archiviare tre volte la quantità di dati prevista nel cluster. Devi inoltre determinare e impostare le configurazioni per nodi, rack e replica.
La separazione del computing dall'archiviazione in Bigtable semplifica la scalabilità dei cluster verso l'alto e verso il basso rispetto a Cassandra. In un cluster normalmente in esecuzione, di solito devi gestire solo lo spazio di archiviazione totale utilizzato dalle tabelle gestite, che determina il numero minimo di nodi e la quantità di nodi sufficiente a mantenere il valore QPS attuale.
Puoi regolare rapidamente le dimensioni del cluster Bigtable se il cluster è in overprovisioning o sottoprovisioning in base al carico di produzione.
Archiviazione Bigtable
A parte la località geografica del cluster iniziale, l'unica scelta che devi effettuare quando crei la tua 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 in un'istanza devono condividere lo stesso tipo di archiviazione.
Quando prendi in considerazione le esigenze di archiviazione con Bigtable, non è necessario tenere conto delle repliche di archiviazione come faresti per le dimensioni di un cluster Cassandra. La densità di archiviazione non subisce perdite per raggiungere la tolleranza agli errori come si vede in Cassandra. Inoltre, poiché non è necessario eseguire esplicitamente il provisioning dello spazio di archiviazione, ti verrà addebitato solo lo spazio di archiviazione in uso.
SSD
La capacità del nodo SSD di 5 TB, preferita per la maggior parte dei carichi di lavoro, offre una densità di archiviazione più elevata rispetto alla configurazione consigliata per le macchine Cassandra, che hanno una densità massima di archiviazione pratica inferiore a 2 TB per ciascun 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 la scrittura di QPS per SSD sia più o meno uguale a quella dell'HDD, l'SSD fornisce un valore QPS molto più alto rispetto all'HDD. I prezzi dell'archiviazione SSD vengono addebitati ai prezzi dei dischi permanenti SSD e ne variano il costo e variano in base all'area geografica.
HDD
Il tipo di archiviazione HDD consente una notevole densità di archiviazione, ovvero 16 TB per ogni nodo. Da un lato, la lettura casuale è più lenta, supportando solo 500 righe lette al secondo per ogni nodo. HDD è la scelta preferita per i carichi di lavoro che richiedono un'attività di scrittura elevata, in cui le letture dovrebbero essere analisi di intervalli associate all'elaborazione batch. I prezzi di archiviazione HDD variano o sono simili al costo associato a Cloud Storage e variano in base all'area geografica.
Considerazioni sulle dimensioni del cluster
Quando dimensioni un'istanza Bigtable per prepararti alla migrazione di un carico di lavoro Cassandandra, ci sono alcune considerazioni da confrontare quando confronti i cluster Bigtable di data center e le istanze Bigtable a cluster singolo e i cluster di data center multipli di Colab con istanze di Bigtable multi-cluster. Le linee guida nelle sezioni seguenti presuppongono che non siano necessarie modifiche significative del modello dei dati e che esista una compressione equivalente per lo spazio di archiviazione tra Cassandra e Bigtable.
Un cluster di data center
Quando confronti un cluster di un singolo data center e un'istanza Bigtable a cluster singolo, devi prima considerare i requisiti di archiviazione. Puoi stimare le dimensioni non replicate di ogni spazio chiavi utilizzando il comando nodetoolstats di tabella e dividendo le dimensioni totali dell'archiviazione con svuotamento per il fattore di replica dello spazio dei tasti. Quindi, dividi la quantità di spazio di archiviazione non replicato di tutti gli spazi chiave per 3,5 TB (5 TB * 0,70) per determinare il numero di nodi SSD da gestire per la sola archiviazione. Come discusso, Bigtable gestisce la replica e la durabilità dello spazio di archiviazione in un livello separato trasparente per l'utente.
Ora devi prendere in considerazione i requisiti di calcolo per il numero di nodi. Puoi consultare le metriche del server e delle applicazioni client di Cassandra per ottenere un numero approssimativo di letture e scritture sostenute che sono state eseguite. Per stimare il numero minimo di nodi SSD per l'esecuzione del carico di lavoro, dividi la metrica per 10.000. Probabilmente hai 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 carico di lavoro.
Il numero di nodi necessario per il cluster deve essere uguale al più grande delle esigenze di archiviazione e calcolo. Se hai dubbi in merito alle esigenze di archiviazione o di velocità effettiva, puoi confrontare il numero di nodi Bigtable con il numero di macchine Cassandra tipiche. Puoi fare lo scale up o lo scale down di un cluster Bigtable in base alle esigenze del carico di lavoro con il minimo sforzo e senza tempi di inattività.
Un cluster di più data center
Con i cluster multi-data center, è più difficile determinare la configurazione di un'istanza Bigtable. Idealmente, dovresti avere un cluster nell'istanza per ogni data center nella topologia di Cassandra. Ogni cluster Bigtable nell'istanza deve archiviare tutti i dati all'interno dell'istanza e deve essere in grado di gestire la frequenza di inserimento totale nell'intero cluster. Un'istanza è limitata a quattro cluster anche se questi potrebbero 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 di data center singoli. Puoi utilizzare nodetool per acquisire le dimensioni di archiviazione di ogni spazio dei tasti nel cluster Cassandra, quindi dividerle per il numero di repliche. Occorre ricordare che lo spazio delle chiavi di una tabella potrebbe avere fattori di replica diversi per ciascun data center.
Il numero di nodi in ogni cluster in un'istanza deve essere in grado di gestire tutte le scritture nel cluster e di tutte le operazioni di lettura in almeno due data center per mantenere obiettivi di livello di servizio (SLO) durante un'interruzione del cluster. Un approccio comune è iniziare con tutti i cluster con la capacità di nodo equivalente del data center più trafficato nel cluster Cassandra. Puoi fare lo scale up o lo scale down individuale dei cluster Bigtable in un'istanza, per soddisfare le esigenze dei carichi di lavoro senza tempi di inattività.
Amministrazione
Bigtable fornisce componenti completamente gestiti per le funzioni di amministrazione comuni eseguite in Cassandra.
Backup e ripristino
Bigtable offre due metodi per soddisfare le esigenze di backup più comuni: Backup Bigtable ed esportazioni di dati gestite.
Puoi pensare ai backup di Bigtable come a una versione
gestita della funzionalità di snapshot nodetool di Cassandra.
I backup di Bigtable creano copie ripristinabili di una tabella, che vengono 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 creati tramite questa utilità non consumano risorse dei nodi e hanno un prezzo pari o vicino ai prezzi 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 esportare i formati di file nel formato 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 che puoi eseguire offline o importare in un altro sistema.
Ridimensionamento
Poiché Bigtable separa l'archiviazione e il calcolo, puoi aggiungere o rimuovere i nodi Bigtable in risposta alla domanda in modo più semplice rispetto a Cassandra. L'architettura omogenea di Cassandra richiede il ribilanciamento dei nodi (o nodi) tra le macchine nel cluster.
Puoi modificare manualmente le dimensioni del cluster nella console Google Cloud o in modo programmatico utilizzando l'API Bigtable. L'aggiunta di nodi a un cluster può produrre miglioramenti significativi delle prestazioni in pochi minuti. Alcuni clienti hanno utilizzato correttamente un gestore della scalabilità automatica open source sviluppato da Spotify.
Manutenzione interna
Il servizio Bigtable gestisce senza problemi le attività di manutenzione interna più comuni di Cassandra, come l'applicazione di patch del sistema operativo, il recupero dei nodi, la riparazione dei nodi, il monitoraggio della compazione dello spazio di archiviazione e la rotazione dei certificati SSL.
Monitoraggio
La connessione di Bigtable a visualizzazioni o avvisi delle metriche non richiede attività di amministrazione o sviluppo. La pagina della console Google Cloud Bigtable include dashboard predefinite per il monitoraggio delle metriche di velocità effettiva e di 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.
Il Key Visualizer di Bigtable, una funzionalità di monitoraggio nella console Google Cloud, ti consente di eseguire prestazioni avanzate di ottimizzazione.
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 utente e le password locali non vengono condivisi con le applicazioni client, ma vengono concesse autorizzazioni e ruoli granulari a utenti e account di servizio a livello di organizzazione.
Bigtable cripta automaticamente tutti i dati at-rest e in transito. Non sono disponibili opzioni per disattivare queste funzionalità. Tutti gli accessi amministrativi sono completamente registrati. 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 Bigtable.
- Prova il codelab per gli utenti di Cassandra.
- Scopri di più sull'emulatore di Bigtable.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Centro di architettura cloud.