Panoramica di Bigtable

Bigtable è una tabella con poche righe che può scalare fino a miliardi di righe e migliaia di colonne, consentendoti di archiviare terabyte o addirittura petabyte di dati. Viene indicizzato un singolo valore in ogni riga; questo valore è noto come chiave riga. Bigtable è ideale per archiviare grandi quantità di dati con una sola chiave a 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, inclusa un'estensione supportata della libreria Apache HBase per Java. Di conseguenza, si integra con l'ecosistema Apache esistente di software per big data open source.

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

  • Scalabilità incredibile. Bigtable si espande in proporzione diretta al numero di macchine nel cluster. Un'installazione HBase autogestita presenta un collo di bottiglia di progettazione che limita le prestazioni dopo il raggiungimento di una determinata soglia. Bigtable non ha questo bottleneck, quindi puoi scalare il cluster per gestire più letture e scritture.
  • Amministrazione semplificata. Bigtable gestisce gli upgrade e i riavvii in modo trasparente e mantiene automaticamente un'elevata durabilità dei dati. Per replicare i dati, aggiungi un secondo cluster all'istanza e la replica inizierà automaticamente. Non dovrai più gestire repliche o regioni. Progetta gli schemi delle tabelle e Bigtable si occuperà del resto.
  • Ridimensionamento del cluster senza tempi di inattività. Puoi aumentare le dimensioni di un cluster Bigtable per alcune ore per gestire un carico elevato, quindi ridurre di nuovo le dimensioni del cluster, il tutto senza tempi di inattività. Dopo aver modificato le dimensioni di un cluster, in genere sono necessari solo pochi minuti sotto carico per bilanciare il rendimento su tutti i nodi del cluster.

A cosa serve

Bigtable è ideale per applicazioni che richiedono velocità effettiva e scalabilità elevate per dati chiave-valore in cui ogni valore, di solito, non è più grande di 10 MB. Bigtable eccelle anche come motore di archiviazione per operazioni MapReduce batch, analisi/elaborazione di stream 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 l'utilizzo della CPU e della memoria nel tempo per più server.
  • Dati di marketing,come cronologia acquisti e preferenze dei clienti.
  • Dati finanziari, come cronologia delle transazioni, prezzi delle azioni e tassi di cambio delle valute.
  • Dati IoT,come report sull'utilizzo di contatori energetici ed elettrodomestici.
  • Dati grafici,ad esempio informazioni su come gli utenti sono collegati 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 ciascuna riga. Ciascuna riga è indicizzata con una singola chiave di riga e le colonne correlate una all'altra sono generalmente raggruppate in una famiglia di colonne. Ciascuna colonna è identificata da una combinazione della famiglia di colonne e di un qualificatore di colonna, che è un nome univoco all'interno della famiglia di colonne.

Ogni intersezione di una riga e 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 ai dati archiviati per quella riga e colonna nel tempo. Le tabelle Bigtable sono sparse; se una colonna non viene utilizzata in una determinata riga, non occupa spazio.

Diagramma del modello di archiviazione Bigtable

Ecco alcuni aspetti da notare in questa illustrazione:

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

Architettura di Bigtable

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

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 su Bigtable, questi nodi sono chiamati "server tablet". I node sono organizzati in un cluster Bigtable, che appartiene a un'istanza Bigtable, un contenitore per il cluster.

Ogni nodo del cluster gestisce un sottoinsieme delle richieste al cluster. Aggiungendo nodi a un cluster, puoi aumentare il numero di richieste simultanee che il cluster può gestire. L'aggiunta di nodi aumenta anche la velocità effettiva massima per il cluster. Se attivi la replica aggiungendo altri cluster, puoi anche inviare diversi tipi di traffico a cluster diversi. In questo modo, se un cluster non è 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 regioni di 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 delle chiavi ai valori, in cui sia le chiavi che i valori sono stringhe di byte arbitrarie. Ogni tablet è associato a un nodo Bigtable specifico. Oltre ai file SSTable, tutte le scritture vengono archiviate nel log condiviso di Colossus non appena vengono confermate da Bigtable, garantendo una maggiore durabilità.

È importante sottolineare che i dati non vengono mai archiviati nei nodi Bigtable stessi; ogni nodo contiene puntatori a un insieme 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 cursori per ogni nodo.
  • Il recupero da un errore di un nodo Bigtable è rapido, perché solo i metadati devono essere migrati al nodo sostitutivo.
  • Quando un nodo Bigtable si arresta in modo anomalo, nessun dato viene perso.

Per ulteriori informazioni su come utilizzare questi elementi fondamentali, consulta Istanze, cluster e nodi.

Bilanciamento del carico

Ogni zona Bigtable è gestita da un processo principale, che bilancia il carico di lavoro e il volume di dati all'interno dei cluster. Questa procedura suddivide i tablet più grandi o più utilizzati a metà e unisce i tablet meno utilizzati/più piccoli, ridistribuendoli tra i nodi in base alle esigenze. Se un determinato tablet riceve un picco di traffico, Bigtable lo suddivide in due e sposta uno dei nuovi tablet su un altro nodo. Bigtable gestisce automaticamente la suddivisione, la combinazione e il riequilibrio, evitandoti di dover amministrare manualmente i tablet. Informazioni sul rendimento fornisce maggiori dettagli su questa procedura.

Per ottenere le migliori prestazioni di scrittura da Bigtable, è importante distribuire le scritture in modo il 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 l'inclusione di un nome utente all'inizio della chiave di riga tenderà a distribuire le scritture uniformemente.

Allo stesso tempo, è utile raggruppare le righe correlate in modo che siano una accanto all'altra, il che rende molto più efficiente la lettura di più righe contemporaneamente. Ad esempio, se memorizzi 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 di una posizione in un intervallo contiguo di righe. Per altre località, la riga inizierà con un identificatore diverso. Con molte località che raccolgono i dati alla stessa velocità, le scritture verranno comunque distribuite uniformemente tra i tablet.

Per ulteriori dettagli sulla scelta di una chiave di riga appropriata per i tuoi dati, consulta Scegliere una chiave di riga.

Tipi di dati supportati

Bigtable tratta tutti i dati come stringhe di byte non elaborate per la maggior parte delle finalità. L'unica volta che 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 valore big endian di 8 byte.

Utilizzo della memoria e del disco

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

Colonne inutilizzate

Le colonne non utilizzate in una riga di Bigtable non occupano alcun spazio in quella riga. Ogni riga è essenzialmente una raccolta di voci chiave-valore, dove la chiave è una combinazione della famiglia di colonne, del qualificatore di colonna e del timestamp. Se una riga non include un valore per una colonna specifica, la voce 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 viene memorizzato in quella riga. Di conseguenza, è spesso efficiente utilizzare i qualificatori di colonna come dati.

Per ulteriori informazioni sui qualificatori di colonna, consulta Colonne.

Compazioni

Bigtable riscrive periodicamente le tabelle per rimuovere le voci eliminate e riorganizzare i dati in modo che le operazioni di lettura e scrittura siano più efficienti. Questa procedura è nota come compaction. Non sono presenti impostazioni di configurazione per le compattazioni: Bigtable comprime automaticamente i dati.

Mutazioni ed eliminazioni

Le mutazioni, o modifiche, a una riga occupano spazio di archiviazione aggiuntivo, perché Bigtable archivia le mutazioni in sequenza e le comprime solo periodicamente. Quando Bigtable compatta una tabella, rimuove i valori che non sono più necessari. Se aggiorni il valore in una cella, sia il valore originale sia il nuovo valore verranno archiviati sul disco per un determinato periodo di tempo fino al completamento del compattamento dei dati.

Inoltre, le eliminazioni occupano spazio di archiviazione aggiuntivo, almeno a breve termine, perché in realtà sono un tipo specializzato di mutazione. Fino a quando la tabella non viene compressa, un'eliminazione utilizza spazio di archiviazione aggiuntivo anziché liberare spazio.

Compressione dei dati

Bigtable comprime automaticamente i dati 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 con pattern includono il testo, ad esempio la pagina che stai leggendo in questo momento.
  • La compressione funziona meglio se i valori identici sono 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 i valori di dimensioni fino a 1 MiB. Se memorizzi valori superiori a 1 MiB, comprimili prima di scriverli in Bigtable, in modo da risparmiare cicli della CPU, memoria del server e larghezza di banda della rete.

Durabilità dei dati

Quando utilizzi Bigtable, i tuoi dati vengono archiviati su Colossus, il file system interno di Google estremamente duraturo, utilizzando dispositivi di archiviazione nei data center di Google. Per utilizzare Bigtable non è necessario eseguire un cluster HDFS o qualsiasi altro file system. Dietro le quinte, Google utilizza metodi di archiviazione di proprietà per garantire la durabilità dei dati oltre a quanto offerto dalla replica trilaterale HDFS standard.

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

Modello di coerenza

Le istanze Bigtable a cluster singolo offrono un'elevata coerenza. Per impostazione predefinita, le istanze con più di un cluster forniscono coerenza finale, ma per alcuni casi d'uso possono essere configurate per fornire coerenza di lettura delle tue scritture 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 di Identity and Access Management (IAM) che assegni agli utenti. Ad esempio, puoi assegnare ruoli IAM che impediscono ai singoli utenti di leggere da tabelle, scrivere in tabelle o creare nuove istanze. Se un utente non ha accesso al tuo progetto o non dispone di un ruolo IAM con 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 dei dati della tabella. In questo modo, puoi concedere alcune autorizzazioni a livello di vista a determinati utenti senza dover concedere 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 delle tabelle Bigtable, sono criptati in stato inattivo utilizzando gli stessi sistemi di gestione delle chiavi avanzati che utilizziamo per i nostri dati criptati.

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

Backup

I backup di Bigtable ti consentono di salvare una copia dello schema e dei dati di una tabella e 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 hai un'istanza Bigtable, indipendentemente da dove si trova la tabella di origine.

Change Data Capture (CDC)

Bigtable fornisce il Change Data Capture (CDC) sotto forma di stream di modifiche. I flussi di modifiche ti consentono di acquisire e trasmettere le modifiche ai dati in una tabella man mano che si verificano. Puoi leggere uno stream di modifiche utilizzando un servizio come Dataflow per supportare casi d'uso quali analisi dei dati, controlli, requisiti di archiviazione e attivazione della logica dell'applicazione a valle. Per ulteriori informazioni, consulta la Panoramica degli stream di modifiche.

Routing delle richieste con i profili dell'app

I criteri di routing del profilo dell'app ti consentono di controllare quali cluster devono gestire le richieste in entrata delle tue applicazioni. Le opzioni per i criteri di routing includono:

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

Altre opzioni di archiviazione e database

Bigtable non è un database relazionale tradizionale. Sebbene supporti le query SQL, alcuni casi d'uso potrebbero essere più adatti a un'altra opzione di database.

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

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

Passaggi successivi