Panoramica di Bigtable

Bigtable è una tabella con pochi dati che può scalare fino a miliardi di righe e migliaia di colonne, consentendoti di archiviare terabyte o anche petabyte di dati. Viene indicizzato un singolo valore in ogni riga; questo valore è noto come chiave di 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, tra cui un'estensione supportata della libreria Apache HBase per Java. Di conseguenza, si integra con l'ecosistema Apache esistente di 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 viene scalato in proporzione diretta al numero di macchine nel cluster. Un'installazione di HBase autogestita presenta un collo di bottiglia di progettazione che limita le prestazioni dopo il raggiungimento di una determinata soglia. Bigtable non presenta questo collo di bottiglia, quindi puoi scalare il cluster per gestire più letture e scritture.
  • Amministrazione semplice. 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 inizia automaticamente. Non dovrai più gestire repliche o regioni: ti basterà progettare 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 bastano pochi minuti sotto carico per Bigtable per bilanciare le prestazioni su tutti i nodi del cluster.
  • Scalabilità automatica. Puoi configurare Bigtable in modo che monitori continuamente la capacità della CPU del cluster e regoli automaticamente il numero di nodi in un cluster quando necessario.
  • Archiviazione a livelli (anteprima). Puoi archiviare i dati a cui si accede raramente in un livello di archiviazione separato e a costo inferiore. L'archiviazione a livelli ti consente di scegliere il livello di archiviazione più adatto alle tue esigenze di accesso ai dati Bigtable.

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, elaborazione/analisi di 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 l'utilizzo di CPU e memoria nel tempo per più server.
  • Dati di marketing,come cronologia degli acquisti e preferenze dei clienti.
  • Dati finanziari, come cronologia delle transazioni, prezzi delle azioni e tassi di cambio delle valute.
  • Dati dell'Internet of Things,come report sull'utilizzo di contatori di energia e elettrodomestici.
  • Dati del grafico,ad esempio 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 ciascuna riga. Ogni riga è indicizzata con una singola chiave di riga e le colonne correlate tra loro 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

Alcuni aspetti da notare in questa illustrazione:

  • Le colonne possono non essere utilizzate in una riga.
  • Ogni cella di 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:

Architettura generale di Bigtable.

Come illustrato nel diagramma, tutte le richieste client passano attraverso un server frontend prima di essere inviate a un nodo Bigtable. Nell'articolo originale su Bigtable, questi nodi sono chiamati "tablet server". I nodi sono organizzati in un cluster Bigtable, che appartiene a un'istanza Bigtable, un container 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 abiliti la replica aggiungendo altri cluster, puoi anche inviare diversi tipi di traffico a cluster diversi. In questo modo, 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 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 riconosciute da Bigtable, garantendo una maggiore durabilità.

È importante sottolineare che i dati non vengono mai archiviati nei nodi Bigtable stessi; ogni nodo ha 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 puntatori per ogni nodo.
  • Il ripristino in seguito all'errore di un nodo Bigtable è rapido perché nel nodo sostitutivo devono essere migrati solo i metadati.
  • Quando un nodo Bigtable non funziona, non vengono persi dati.

Per ulteriori informazioni su come utilizzare questi elementi costitutivi 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. Questo processo divide a metà i tablet più occupati o più grandi e unisce quelli più piccoli o meno accessibili, ridistribuendoli tra i nodi in base alle necessità. Se un determinato tablet riceve un picco di traffico, Bigtable lo divide in due, quindi sposta uno dei nuovi tablet in un altro nodo. Bigtable gestisce automaticamente la suddivisione, l'unione e il ribilanciamento, risparmiandoti la fatica di amministrare manualmente i tablet. Comprendere il rendimento fornisce maggiori dettagli su questa procedura.

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 in tutto l'alfabeto, quindi l'inclusione di un nome utente all'inizio della chiave di riga tende a distribuire le scritture in modo uniforme.

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 meteo nel tempo, la chiave di riga potrebbe essere la località in cui sono stati raccolti i dati, seguita da un timestamp (ad esempio, WashingtonDC#201803061617). Questo tipo di chiave di riga raggrupperebbe tutti i dati di una località in un intervallo contiguo di righe. Per altre posizioni, la riga inizierebbe con un identificatore diverso; con molte posizioni che raccolgono dati alla stessa velocità, le scritture sarebbero comunque distribuite uniformemente sui tablet.

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

Computing

Per impostazione predefinita, Bigtable utilizza i nodi del cluster sia per l'archiviazione sia per il calcolo. Per i job di lettura con throughput elevato, puoi utilizzare Data Boost per Bigtable per il calcolo. Data Boost ti consente di inviare query e job di lettura di grandi dimensioni utilizzando il serverless computing, mentre l'applicazione principale continua a utilizzare i nodi del cluster per il computing. Per saperne di più, vedi la panoramica di Data Boost.

Tipi di dati supportati

Bigtable tratta tutti i dati come stringhe di byte non elaborate per la maggior parte degli scopi. Bigtable tenta di determinare il tipo solo per le operazioni di incremento, in cui la destinazione deve essere un numero intero a 64 bit codificato come 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 di memoria e disco per la tua istanza.

Colonne inutilizzate

Le colonne non utilizzate in una riga Bigtable non occupano spazio in quella riga. Ogni riga è essenzialmente una raccolta di voci chiave-valore, dove 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 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 la sezione Colonne.

Compattazioni

Bigtable riscrive periodicamente le tabelle per rimuovere le voci eliminate, riorganizzare i dati in modo che le operazioni di lettura e scrittura siano più efficienti e spostare i dati nell'ambito dell'archiviazione a livelli. Questa procedura è nota come compattazione. Non esistono impostazioni di configurazione per le compressioni. Bigtable comprime automaticamente i dati. In media, una compattazione richiede una settimana per essere completata ed eseguire attività come l'eliminazione dei dati o lo spostamento dei dati nell'archiviazione a livelli.

La compattazione esegue le eliminazioni identificate dal processo di garbage collection. Per ulteriori informazioni, vedi Garbage collection. Per saperne di più sulla compattazione nell'archiviazione a livelli, vedi Come funziona l'archiviazione a livelli.

Mutazioni ed eliminazioni

Le mutazioni, o modifiche, a una riga occupano spazio di archiviazione aggiuntivo perché Bigtable le archivia 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 quello nuovo verranno archiviati su disco per un determinato periodo di tempo finché i dati non vengono compattati.

Anche le eliminazioni occupano spazio di archiviazione aggiuntivo, almeno nel breve termine, perché le eliminazioni sono in realtà un tipo specializzato di mutazione. Finché 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 strutturati. I dati con pattern includono 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 adiacenti, i dati possono essere compressi in modo efficiente.
  • Bigtable comprime i valori fino a 1 MiB. Se memorizzi valori superiori a 1 MiB, comprimili prima di scriverli in 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 di Google altamente durevole, 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 proprietari per ottenere una durabilità dei dati superiore a quella fornita dalla replica a tre vie HDFS standard.

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

Modello di coerenza

Le istanze Bigtable a cluster singolo offrono una 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 proprie 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 tuo progetto Google Cloude dai ruoli Identity and Access Management (IAM) che assegni agli utenti. Ad esempio, puoi assegnare ruoli IAM che impediscono a singoli utenti di leggere o scrivere nelle tabelle o di 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 delle tabelle creando una vista autorizzata di una tabella che rappresenta un sottoinsieme dei dati della tabella. In questo modo, puoi concedere autorizzazioni di visualizzazione autorizzate ad alcuni utenti senza concedere loro autorizzazioni a livello di tabella.

Puoi gestire la sicurezza a livello di progetto, istanza, tabella o vista autorizzata. Bigtable non supporta 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, sono criptati in modalità non attiva utilizzando gli stessi sistemi avanzati di gestione delle chiavi che utilizziamo per i nostri dati criptati.

Se vuoi avere 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 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 dalla posizione della tabella di origine.

Change Data Capture (CDC)

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

Routing delle richieste con i profili delle app

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

  • Routing a un cluster singolo: invia tutte le richieste a un singolo cluster.
  • Routing multicluster 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 query interattive in un sistema di elaborazione analitica online (OLAP), prendi in considerazione 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 Firebase Realtime Database.

Per saperne di più su altre opzioni di database, consulta la panoramica dei servizi di database. Google Cloud offre anche varie opzioni di archiviazione.

Passaggi successivi