Panoramica di Bigtable

Bigtable è una tabella sparsa che può scalare fino a miliardi di righe e migliaia di colonne, consentendoti di archiviare terabyte o perfino petabyte di dati. Viene indicizzato un singolo valore in ogni riga, noto come chiave di riga. Bigtable è ideale per archiviare grandi quantità di dati a chiave singola con bassa latenza. Supporta un'elevata velocità effettiva di lettura e scrittura a bassa latenza ed è un'origine dati ideale per le operazioni MapReduce.

Bigtable è esposto alle applicazioni tramite più librerie client, tra cui un'estensione supportata per la libreria Apache HBase per Java. Di conseguenza, si integra con l'ecosistema Apache esistente del software open source per big data.

I potenti server di backend di Bigtable offrono diversi vantaggi chiave rispetto a un'installazione HBase autogestita:

  • Scalabilità incredibile. Bigtable scala in proporzione diretta al numero di macchine nel tuo cluster. Un'installazione HBase autogestita ha un collo di bottiglia di progettazione che limita le prestazioni al raggiungimento di una determinata soglia. Bigtable non ha questo collo di bottiglia, quindi puoi fare lo scale up del tuo cluster per gestire un maggior numero di operazioni di lettura e scrittura.
  • Amministrazione semplice. Bigtable gestisce gli upgrade e si riavvia in modo trasparente, oltre a mantenere automaticamente un'elevata durabilità dei dati. Per replicare i dati, aggiungi un secondo cluster all'istanza. La replica verrà avviata automaticamente. Non dovrai più gestire repliche o regioni: dovrai solo progettare gli schemi delle tabelle e Bigtable si occuperà del resto al posto tuo.
  • Ridimensionamento dei cluster senza tempi di inattività. Puoi aumentare le dimensioni di un cluster Bigtable per alcune ore per gestire un carico di grandi dimensioni, quindi ridurre nuovamente le dimensioni del cluster, il tutto senza tempi di inattività. Dopo aver modificato le dimensioni di un cluster, in genere bastano pochi minuti sotto carico affinché Bigtable bilancia le prestazioni su tutti i nodi del tuo cluster.

Per cosa è utile

Bigtable è ideale per le applicazioni che necessitano di scalabilità e velocità effettiva elevate per dati chiave-valore, dove ogni valore in genere non è superiore a 10 MB. Bigtable eccelle anche come motore di archiviazione per operazioni MapReduce in batch, elaborazione/analisi dei flussi e applicazioni di machine learning.

Puoi utilizzare Bigtable per archiviare ed eseguire query su tutti i seguenti tipi di dati:

  • Dati di serie temporali,ad esempio utilizzo di CPU e memoria nel tempo per più server.
  • Dati di marketing,ad esempio cronologie degli acquisti e preferenze dei clienti.
  • Dati finanziari, ad esempio cronologie delle transazioni, prezzi delle azioni e tassi di cambio delle valute.
  • Dati di Internet of Things, ad esempio report sull'utilizzo di misuratori di energia ed elettrodomestici.
  • Dati grafici,come informazioni su come gli utenti sono connessi tra loro.

Modello di archiviazione Bigtable

Bigtable archivia i dati in tabelle ad altissima scalabilità, ciascuna delle quali è una mappa chiave-valore ordinata. La tabella è composta da righe, ciascuna delle quali generalmente descrive una singola entità, e colonne, che contengono singoli valori per ogni riga. Ogni riga è indicizzata da una singola chiave di riga e le colonne correlate una all'altra sono in genere raggruppate in una famiglia di colonne. Ogni colonna è identificata da una combinazione della famiglia di colonne e di un qualificatore colonna, che è un nome univoco all'interno della famiglia di colonne.

Ogni intersezione di una riga e di una colonna può contenere più celle. Ogni cella contiene una versione univoca con timestamp dei dati per quella riga e colonna. L'archiviazione di più celle in una colonna fornisce un record delle modifiche apportate nel tempo ai dati archiviati per quella riga e colonna. Le tabelle Bigtable sono sparse; se una colonna non viene utilizzata in una determinata riga, non occupa alcuno spazio.

Diagramma del modello di archiviazione Bigtable

Alcuni aspetti da notare in questa illustrazione:

  • Le colonne possono non essere utilizzate in una riga.
  • Ogni cella in una determinata riga e colonna ha un timestamp univoco (t).

Architettura di Bigtable

Il seguente diagramma mostra una versione semplificata dell'architettura complessiva di Bigtable:

dell'architettura complessiva di Bigtable.

Come illustrato nel diagramma, tutte le richieste del client passano attraverso un server frontend prima di essere inviate a un nodo Bigtable. (Nell'articolo originale di Bigtable, questi nodi sono chiamati "server tablet"). I nodi sono organizzati in un cluster Bigtable, che appartiene a un'istanza Bigtable, un container per il cluster.

Ogni nodo nel cluster gestisce un sottoinsieme delle richieste al cluster. Aggiungendo nodi a un cluster, puoi aumentare il numero di richieste simultanee che il cluster è in grado di gestire. L'aggiunta di nodi aumenta anche la velocità effettiva massima per il cluster. Se abiliti la replica aggiungendo altri cluster, puoi anche inviare diversi tipi di traffico a cluster diversi. Quindi, se un cluster non è più disponibile, puoi eseguire il failover su un altro cluster.

Una tabella Bigtable viene partizionata orizzontalmente in blocchi di righe contigue, denominati tablet, per consentire il bilanciamento del carico di lavoro delle query. I tablet sono simili alle aree geografiche HBase. I tablet vengono archiviati su Colossus, il file system di Google, in formato SSTable. Una tabella SSTable fornisce un mapping permanente, ordinato e immutabile dalle chiavi ai valori, in cui sia le chiavi che i valori sono stringhe di byte arbitrarie. Ogni tablet è associato a uno specifico nodo Bigtable. Oltre ai file SSD, tutte le scritture vengono archiviate nel log condiviso di Colossus non appena vengono confermate da Bigtable, offrendo una maggiore durabilità.

È importante sottolineare che i dati non vengono mai archiviati nei nodi Bigtable. Ogni nodo ha puntatori a un set di tablet archiviati su Colossus. Di conseguenza:

  • Il ribilanciamento dei tablet da un nodo all'altro avviene rapidamente, perché i dati effettivi non vengono copiati. Bigtable aggiorna i puntatori per ciascun nodo.
  • Il ripristino dall'errore di un nodo Bigtable è rapido, poiché è necessario eseguire la migrazione solo dei metadati nel nodo sostitutivo.
  • In caso di errore di un nodo Bigtable, non viene perso nessun dato.

Consulta Istanze, cluster e nodi per ulteriori informazioni su come utilizzare questi componenti di base di base.

Bilanciamento del carico

Ogni zona Bigtable è gestita da un processo principale che bilancia il carico di lavoro e il volume dei dati all'interno dei cluster. Questo processo divide a metà i tablet più occupati o più grandi e unisce i tablet con minore accesso/più piccoli, ridistribuendoli tra i nodi in base alle esigenze. Se un determinato tablet riceve un picco di traffico, Bigtable divide il tablet in due, quindi sposta uno dei nuovi tablet su un altro nodo. Bigtable gestisce automaticamente la suddivisione, l'unione e il ribilanciamento, evitandoti il tempo di amministrare manualmente i tablet. Comprendi le prestazioni fornisce maggiori dettagli su questo processo.

Per ottenere le migliori prestazioni di scrittura da Bigtable, è importante distribuire le scritture nel modo più uniforme possibile tra i nodi. Un modo per raggiungere questo obiettivo è utilizzare chiavi di riga che non seguono un ordine prevedibile. Ad esempio, i nomi utente tendono a essere distribuiti in modo più o meno uniforme nell'alfabeto, quindi includere un nome utente all'inizio della chiave di riga tenderà a distribuire le scritture in modo uniforme.

Allo stesso tempo, è utile raggruppare le righe correlate in modo che siano vicine tra loro, in modo da rendere molto più efficiente la lettura di più righe contemporaneamente. Ad esempio, se stai archiviando diversi tipi di dati meteorologici nel tempo, la chiave di riga potrebbe essere la posizione in cui sono stati raccolti i dati, seguita da un timestamp (ad esempio, WashingtonDC#201803061617). Questo tipo di chiave di riga raggruppa tutti i dati da una posizione in un intervallo contiguo di righe. Per altre località, la riga inizia con un identificatore diverso. Con molte località che raccolgono dati alla stessa frequenza, le scritture vengono comunque distribuite uniformemente tra i tablet.

Consulta Scelta di una chiave di riga per ulteriori dettagli sulla scelta di una chiave di riga appropriata per i tuoi dati.

Tipi di dati supportati

Bigtable tratta tutti i dati come stringhe di byte non elaborati per la maggior parte degli scopi. L'unica volta in cui Bigtable tenta di determinare il tipo è per le operazioni di incremento, in cui il target deve essere un numero intero a 64 bit codificato come un valore big-endian a 8 byte.

Utilizzo di memoria e disco

Le sezioni seguenti descrivono in che modo diversi componenti di Bigtable influiscono sull'utilizzo della memoria e del disco nell'istanza.

Colonne non utilizzate

Le colonne che non vengono utilizzate in una riga di Bigtable non occupano uno spazio in quella riga. Ogni riga è essenzialmente una raccolta di voci di coppie chiave-valore, in cui la chiave è una combinazione di famiglia di colonne, qualificatore di colonna e timestamp. Se una riga non include un valore per una colonna specifica, la voce della coppia chiave-valore non è presente.

Qualificatori di colonna

I qualificatori di colonna occupano spazio in una riga, poiché ogni qualificatore di colonna utilizzato in una riga è archiviato in questa riga. Di conseguenza, spesso è efficiente utilizzare i qualificatori di colonna come dati.

Per ulteriori informazioni sui qualificatori di colonna, consulta Colonne.

Compattazioni

Bigtable riscrive periodicamente le tabelle per rimuovere le voci eliminate e per riorganizzare i dati in modo che le operazioni di lettura e scrittura siano più efficienti. Questo processo è noto come compattazione. Non esistono impostazioni di configurazione per le compattazioni: Bigtable compatta i dati automaticamente.

Mutazioni ed eliminazioni

Le mutazioni, o modifiche, in una riga occupano spazio di archiviazione aggiuntivo, perché Bigtable archivia le mutazioni in sequenza e le compatta solo in modo periodico. Quando Bigtable compatta una tabella, rimuove i valori che non sono più necessari. Se aggiorni il valore in una cella, sia il valore originale che quello nuovo vengono archiviati su disco per un certo periodo di tempo fino alla compattazione dei dati.

Le eliminazioni occupano anche spazio di archiviazione aggiuntivo, almeno nel breve periodo, perché le eliminazioni sono in realtà un tipo specializzato di mutazione. Fino a quando la tabella non è compatta, un'eliminazione utilizza spazio di archiviazione aggiuntivo anziché liberare spazio.

Compressione dati

Bigtable comprime i dati automaticamente utilizzando un algoritmo intelligente. Non puoi configurare le impostazioni di compressione per la tabella. Tuttavia, è utile sapere come archiviare i dati in modo che possano essere compressi in modo efficiente:

  • I dati casuali non possono essere compressi con la stessa efficienza dei dati con pattern. I dati creati con pattern includono testo, ad esempio la pagina che stai leggendo in questo momento.
  • La compressione funziona meglio se ci sono valori identici vicini tra loro, nella stessa riga o in righe adiacenti. Se disponi le chiavi di riga in modo che le righe con blocchi di dati identici siano una accanto all'altra, i dati possono essere compressi in modo efficiente.
  • Bigtable comprime valori che raggiungono una dimensione massima di 1 MiB. Se archivi valori superiori a 1 MiB, comprimili prima di scriverli su Bigtable, in modo da risparmiare cicli di CPU, memoria del server e larghezza di banda di rete.

Durabilità dei dati

Quando utilizzi Bigtable, i tuoi dati vengono archiviati su Colossus, il file system interno a elevata durabilità di Google, che utilizza dispositivi di archiviazione nei data center di Google. Non è necessario eseguire un cluster HDFS o qualsiasi altro file system per utilizzare Bigtable. Dietro le quinte, Google utilizza metodi di archiviazione di proprietà per ottenere una durabilità dei dati ben superiore a quella offerta dalla replica a tre vie HDFS standard.

La durabilità viene ulteriormente migliorata quando si utilizza la replica. Bigtable conserva una copia separata dei tuoi dati nella località selezionata per ciascun cluster di un'istanza replicata.

Modello di coerenza

Le istanze Bigtable a cluster singolo offrono elevata coerenza. Per impostazione predefinita, le istanze che hanno più di un cluster forniscono coerenza finale, ma per alcuni casi d'uso possono essere configurate per fornire coerenza in operazioni di lettura dei dati o elevata coerenza, a seconda del carico di lavoro e delle impostazioni del profilo dell'app.

Sicurezza

L'accesso alle tabelle Bigtable è controllato dal progetto Google Cloud e dai ruoli IAM (Identity and Access Management) che assegni agli utenti. Ad esempio, puoi assegnare ruoli IAM che impediscono ai singoli utenti di leggere dalle tabelle, scrivere nelle tabelle o creare nuove istanze. Se qualcuno non ha accesso al tuo progetto o non ha un ruolo IAM con le autorizzazioni appropriate per Bigtable, non può accedere a nessuna delle tue tabelle.

Puoi anche controllare l'accesso ai dati della tabella creando una vista autorizzata di una tabella che rappresenta un sottoinsieme di dati della tabella. Quindi puoi concedere autorizzazioni a livello di vista ad alcuni utenti senza concedere loro autorizzazioni a livello di tabella.

Puoi gestire la sicurezza a livello di progetto, istanza, tabella o visualizzazione autorizzata. Bigtable non supporta le limitazioni di sicurezza a livello di riga, colonna o cella.

Crittografia

Per impostazione predefinita, tutti i dati archiviati in Google Cloud, inclusi quelli nelle tabelle Bigtable, vengono criptati at-rest tramite gli stessi sistemi di gestione delle chiavi protetti che utilizziamo per i nostri dati criptati.

Se vuoi un maggiore controllo sulle chiavi utilizzate per criptare i dati at-rest di Bigtable, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK).

Backup

I backup di Bigtable consentono di salvare una copia dello schema e dei dati di una tabella e quindi di ripristinarli in una nuova tabella in un secondo momento. Utilizzando i backup e le copie di backup, puoi eseguire il ripristino in una nuova tabella in qualsiasi regione o progetto in cui disponi di un'istanza Bigtable, indipendentemente da dove si trova la tabella di origine.

Change Data Capture (CDC)

Bigtable offre Change Data Capture (CDC) sotto forma di flussi di modifiche. Le modifiche in tempo reale consentono di acquisire e trasferire le modifiche ai dati in una tabella man mano che vengono apportate. Puoi leggere un flusso di modifiche utilizzando un servizio come Dataflow per supportare casi d'uso tra cui analisi dei dati, controlli, requisiti di archiviazione e l'attivazione di logica dell'applicazione downstream. Per ulteriori informazioni, consulta la Panoramica dei flussi di modifiche.

Routing delle richieste con i profili delle app

I criteri di routing dei profili di app consentono di controllare quali cluster gestiscono le richieste in entrata dalle tue applicazioni. Le opzioni per i criteri di routing includono quanto segue:

  • Routing a cluster singolo: invia tutte le richieste a un singolo cluster.
  • Routing multi-cluster a qualsiasi cluster: invia richieste al cluster più vicino disponibile in un'istanza, incluse le opzioni seguenti:
    • Qualsiasi cluster: qualsiasi cluster nell'istanza può ricevere richieste.
    • Routing dei gruppi di cluster: un gruppo specificato di cluster nell'istanza può ricevere richieste.

Altre opzioni di archiviazione e database

Bigtable non è un database relazionale. Non supporta query SQL, join o transazioni multiriga.

  • Se hai bisogno del supporto SQL completo per un sistema di elaborazione delle transazioni online (OLTP), valuta Spanner o Cloud SQL.
  • Se hai bisogno di eseguire query interattive in un sistema di elaborazione analitica online (OLAP), valuta BigQuery.
  • Se devi archiviare oggetti altamente strutturati in un database di documenti con supporto per le transazioni ACID e le query di tipo SQL, prendi in considerazione Firestore.
  • Per l'archiviazione di dati in memoria con bassa latenza, prendi in considerazione Memorystore.
  • Per sincronizzare dati tra utenti in tempo reale, prendi in considerazione il Firebase Realtime Database.

Per ulteriori informazioni sulle altre opzioni di database, consulta la panoramica dei servizi di database. Google Cloud offre anche varie opzioni di archiviazione.

Passaggi successivi