Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice di progettazione dello schema

Questa pagina contiene informazioni sulla progettazione dello schema Bigtable. Prima di leggi questa pagina, dovresti conoscere la panoramica delle Bigtable. Verranno trattati i seguenti argomenti pagina:

Concetti generali: concetti di base da tenere presenti quando progetta il tuo schema.
Best practice: linee guida per la progettazione applicabili alla maggior parte degli usi di Compute Engine, suddivisi per componente della tabella.
Casi d'uso speciali: consigli per alcuni casi d'uso specifici e modelli di dati.

Concetti generali

La progettazione di uno schema Bigtable è diversa dalla progettazione di uno schema per un database relazionale. Uno schema Bigtable è definito dalla logica dell'applicazione anziché da un oggetto o un file di definizione di schema. Puoi aggiungere famiglie di colonne a una tabella quando crei o aggiorni la tabella, ma le colonne e i pattern chiave di riga sono definiti dai dati scritti nella tabella.

In Bigtable, uno schema è un progetto modello di una tabella, compresa la struttura dei seguenti componenti:

Chiavi di riga
Famiglie di colonne, inclusi i relativi criteri di garbage collection
Colonne

In Bigtable, la progettazione dello schema si basa principalmente sulle query, o richieste di lettura, che prevedi di inviare alla tabella. Poiché la lettura di una riga intervallo è il modo più veloce per leggere Dati Bigtable, i suggerimenti in questa pagina sono pensati per per ottimizzare le letture dell'intervallo di righe. Nella maggior parte dei casi, ciò significa inviare una query in base ai prefissi delle chiave di riga.

Una considerazione secondaria è quella di evitarli, per prevenirli. devi considerare i pattern di scrittura e come evitare di accedere a una piccola chiave in poco tempo.

I seguenti concetti generali si applicano alla progettazione dello schema Bigtable:

Bigtable è un archivio chiave/valore, non un archivio relazionale. it non supporta i join e le transazioni sono supportate solo all'interno di una singola riga.
Ogni tabella ha un solo indice, la chiave di riga. Non esistono indici di appartenenza. Ogni chiave di riga deve essere univoca.
Le righe sono ordinate lessicograficamente per chiave di riga,dalla più bassa alla più stringa con il valore più alto di byte. Le chiavi di riga sono ordinate in ordine di byte big-endian (a volte chiamato ordine byte di rete), l'equivalente binario in ordine alfabetico.
Le famiglie di colonne non vengono archiviate in nessun ordine specifico.
Le colonne sono raggruppate per famiglia di colonne e ordinate in ordine grammaticale all'interno della famiglia di colonne. Ad esempio, in una famiglia di colonne chiamata SysMonitor con qualificatori di colonna di ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, Bigtable archivia le colonne in questo ordine:

			SysMonitor
%CPU	DiskRead	ID	Memoria	Priorità	ProcessName	Utente

L'intersezione di una riga e di una colonna può contenere più timestamp celle. Ogni cella contiene una versione univoca dei dati con timestamp per la riga e la colonna.
Le famiglie di colonne aggregate contengono celle aggregate. Puoi creare famiglie di colonne che contengono solo celle aggregate. I dati aggregati ti consentono di unire i nuovi dati con quelli già presenti nella cella.
Tutte le operazioni sono atomiche a livello di riga. Un'operazione influisce su un'intera riga o nessuna della riga.
Idealmente, sia le letture sia le scritture dovrebbero essere distribuite uniformemente spazio tra le righe di una tabella.
Le tabelle Bigtable sono sparse. Una colonna non occupa nessuna spazio in una riga che non utilizza la colonna.

Best practice

Uno schema buono si traduce in prestazioni e scalabilità eccellenti e una scarsa progettato può portare a un sistema con prestazioni scadenti. Ogni caso d'uso diverse e richiede una struttura specifica, ma le seguenti best practice si applicano nella maggior parte dei casi d'uso. Sono previste eccezioni.

A partire dal livello di tabella e fino al livello della chiave di riga, quanto segue sezioni descrivono le best practice per la progettazione dello schema:

Tabelle
Famiglie di colonne
Colonne
Righe
Celle
Chiavi di riga

Tutti gli elementi della tabella, in particolare le chiavi di riga, devono essere progettati con di lettura dei dati. Controlla quote e limiti per le metriche e limiti di dimensione rigidi per tutti gli elementi della tabella.

Poiché tutte le tabelle di un'istanza sono archiviate nella tablet, uno schema che genera gli hotspot in una tabella possono influire sulla latenza di altre tabelle nello stesso in esecuzione in un'istanza Compute Engine. Gli hotspot sono causati dall'accesso frequente a una parte della tabella in un per un breve periodo di tempo.

Tabelle

Archivia set di dati con schemi simili nella stessa tabella, anziché in e tabelle separate.

In altri sistemi di database, potresti scegliere di archiviare i dati in più tabelle in base all'oggetto e al numero di colonne. In Bigtable, invece, di solito è meglio archiviare tutti i dati in un'unica tabella. Puoi assegnare un ID univoco prefisso della chiave di riga da usare per ogni set di dati, in modo che Archivia i dati correlati in un intervallo contiguo di righe su cui puoi eseguire query prefisso della chiave di riga.

Bigtable ha un limite di 1000 tabelle per ma consigliamo di evitare di creare un numero elevato di tabelle per i seguenti motivi:

L'invio di richieste a molte tabelle diverse può aumentare la connessione di backend con conseguente aumento della latenza di coda.
La creazione di più tabelle non migliora il bilanciamento del carico e può aumentare l'overhead per la gestione.

Potresti voler creare una tabella separata per un altro caso d'uso che richiede uno schema diverso, ma non è consigliabile utilizzare tabelle separate per e i dati di Google Cloud. Ad esempio, non devi creare una nuova tabella perché è un nuovo anno un nuovo cliente.

Famiglie di colonne

Inserisci le colonne correlate nella stessa famiglia di colonne. Quando una riga contiene più correlati tra loro, è buona norma raggruppare le colonne contenenti quei valori nella stessa famiglia di colonne. Raggruppa i dati come il più possibile per evitare di dover progettare filtri complessi e di ottenere solo le informazioni di cui hai bisogno, ma niente più, nelle operazioni di lettura più frequenti richieste.

Crea fino a circa 100 famiglie di colonne per tabella. La creazione di più di 100 famiglie di colonne può causare un peggioramento delle prestazioni.

Scegli nomi brevi per le famiglie di colonne. I nomi sono inclusi nei dati che viene trasferito per ogni richiesta.

Inserisci colonne per diverse esigenze di conservazione dei dati in colonne diverse famiglie. Questa pratica è importante se vuoi limitare i costi di archiviazione. I criteri di garbage collection vengono impostati a livello di famiglia di colonne, non a livello a livello di colonna. Ad esempio, se devi mantenere solo la versione più recente di un dati specifici, non devono essere archiviati in una famiglia di colonne impostata per archiviare 1000 versioni di qualcos'altro. Altrimenti, paghi per archiviare 999 celle di i dati non necessari.

Colonne

Crea tutte le colonne che vuoi nella tabella. Bigtable sono sparse e non c'è alcuna penalità di spazio per una colonna che non viene utilizzata una riga. Una tabella può contenere milioni di colonne, purché nessuna riga superi il limite massimo di 256 MB per riga.

Evita di utilizzare troppe colonne in una singola riga. Anche se una tabella può avere milioni di colonne, al contrario di una riga. Alcuni fattori contribuiscono a questo risultato best practice:

Bigtable impiega tempo per elaborare ogni cella in una riga.
Ogni cella aggiunge un overhead alla quantità di dati archiviati nel e inviate tramite la rete. Ad esempio, se stai archiviando 1 kB (1024 byte) di dati, archiviarli in un container è molto più efficiente in termini di spazio singola cella, invece di distribuire i dati in 1024 celle che contengono 1 byte.

Se il set di dati richiede logicamente più colonne per riga rispetto Bigtable può essere elaborato in modo efficiente. Considera l'archiviazione dei dati come protobuf in una singola colonna.

Facoltativamente, puoi trattare i qualificatori di colonna come dati. Dato che devi archiviare un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando un nome alla colonna con un valore. Consideriamo, ad esempio, una tabella in cui vengano memorizzati i dati sulle amicizie in una famiglia di colonne Friends. Ogni riga rappresenta una persona e tutte le sue amicizie. Ogni qualificatore di colonna può essere l'ID di un amico. Quindi il valore di ogni colonna di questa riga può essere la cerchia sociale di cui fa parte l'amico. In questo Ad esempio, le righe potrebbero avere il seguente aspetto:

Chiave di riga	Federico	Gabriele	Hiroshi	Seo Yoon	Giacomo
Jose	club del libro	lavoro	tennis
Sofia			lavoro	scuola	club degli scacchi

Confronta questo schema con uno per gli stessi dati che non trattano la colonna qualificatori come dati e ha invece le stesse colonne in ogni riga:

Chiave di riga	Amico	Galleria
Giuseppe 1	Federico	club del libro
Giuseppe 2	Gabriele	lavoro
Giuseppe 3	Hiroshi	tennis
Sofia n. 1	Hiroshi	lavoro
Sofia n. 2	Seo Yoon	scuola
Sofia n. 3	Giacomo	club degli scacchi

La seconda progettazione dello schema fa sì che la tabella cresca molto più velocemente.

Se utilizzi qualificatori di colonna per archiviare i dati, assegnare ai qualificatori di colonna nomi brevi ma significativi. Questo approccio ti consente ridurre la quantità di dati trasferiti per ogni richiesta. La dimensione massima è di 16 kB.

Righe

Mantieni la dimensione di tutti i valori in una singola riga sotto 100 MB Assicurati che i dati di una singola riga non superare i 256 MB. Le righe che superano questo limite possono comportare riduzione delle prestazioni di lettura.

Conserva tutte le informazioni relative a un'entità in un'unica riga. Per la maggior parte dei casi d'uso, evitare di archiviare dati che devono essere letti atomicamente o tutti in una volta, in più di di una riga per evitare incoerenze. Ad esempio, se aggiorni due righe in una tabella, è possibile che una riga venga aggiornata correttamente e l'altra l'aggiornamento non andrà a buon fine. Assicurati che lo schema non richieda più di una riga aggiornati contemporaneamente per garantire l'accuratezza dei dati correlati. Questa prassi garantisce che se una parte di una richiesta di scrittura non va a buon fine o deve essere inviata nuovamente, non è temporaneamente incompleto.

Eccezione: se mantenere un'entità in una singola riga genera righe che risultano centinaia di MB, devi suddividere i dati su più righe.

Archivia le entità correlate in righe adiacenti per rendere più efficienti le letture.

Celle

Non archiviare più di 10 MB di dati in una singola cellulare. Ricorda che una cella rappresenta i dati archiviati per una data riga e colonna con univoco e che è possibile memorizzare più celle all'intersezione di per la riga e la colonna. Il numero di celle conservate in una colonna è regolato dal criterio di garbage collection impostato per la colonna famiglia che contiene quella colonna.

Utilizza le celle aggregate per archiviare e aggiornare i dati aggregati. Se ti interessa solo sul valore aggregato degli eventi per un'entità, ad esempio la somma mensile vendite per dipendente in un negozio al dettaglio, puoi utilizzare i dati aggregati. Per ulteriori informazioni informazioni, consulta Valori aggregati al momento della scrittura (anteprima).

Chiavi di riga

Progetta la chiave di riga in base alle query che utilizzerai per recuperare i dati. I tasti di riga ben progettati ottengono le migliori prestazioni da Bigtable. Le query Bigtable più efficienti recuperano i dati utilizzando uno dei seguenti:

Chiave di riga
Prefisso chiave di riga
Intervallo di righe definito dalle chiavi di riga iniziale e finale

Altri tipi di query attivano una scansione completa della tabella, che è molto meno efficiente. Se scegli ora la chiave di riga corretta, puoi evitare una complessa migrazione dei dati in un secondo momento.

Mantieni le chiavi di riga brevi. Una chiave di riga deve avere dimensioni massime pari a 4 kB. I tasti di riga lunga richiedono liberare memoria e spazio di archiviazione aggiuntivi e aumentare il tempo necessario per ricevere risposte dal server Bigtable.

Archivia più valori delimitati in ogni chiave di riga. Poiché il modo migliore per su Bigtable in modo efficiente è basato sulla chiave di riga, Includere più identificatori nella chiave di riga. Se la chiave di riga include valori multipli, è particolarmente importante avere una chiara comprensione di come per utilizzare i tuoi dati.

I segmenti chiave di riga sono generalmente separati da un delimitatore, ad esempio due punti, una barra o il simbolo di hashing. Il primo segmento o insieme di segmenti contigui è la chiave di riga e l'ultimo segmento o insieme di segmenti contigui è la chiave di riga suffisso.

Chiave di riga di esempio

Prefissi delle chiave di riga ben pianificati consentono di Bigtable un ordinamento integrato per archiviare i dati correlati in righe contigue. Archiviazione correlata i dati in righe contigue consentono di accedere ai dati correlati come un intervallo di righe, rispetto all'esecuzione di scansioni inefficienti delle tabelle.

Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, riempire i numeri interi con zeri iniziali. Bigtable archivia i dati lessicograficamente. Ad esempio, dal punto di vista didattico, 3 > 20 ma 20 > 03. Se si aggiunge uno zero iniziale al 3, si garantisce che i numeri vengano ordinate numericamente. Questa tattica è importante per i timestamp in cui le query SQL.

È importante creare una chiave di riga che permetta di recuperare una un intervallo di righe ben definito. In caso contrario, la query richiede una scansione della tabella, è molto più lento rispetto al recupero di righe specifiche.

Ad esempio, se la tua applicazione monitora i dati dei dispositivi mobili, puoi avere una riga che include il tipo di dispositivo, l'ID dispositivo e il giorno in cui i dati sono stati registrati. Le chiavi di riga per questi dati potrebbero avere il seguente aspetto:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Questa struttura della chiave di riga consente di recuperare i dati con una singola richiesta di:

Un tipo di dispositivo
Una combinazione di tipo e ID dispositivo

Questa struttura della chiave di riga non sarebbe ottimale se vuoi recuperare tutti i dati per un dato giorno. Poiché il giorno è archiviato nel terzo segmento o nella chiave di riga non è possibile richiedere semplicemente un intervallo di righe in base al suffisso o a una riga centrale segmento della chiave di riga. Devi inviare una richiesta di lettura con un filtro che analizza l'intera tabella cercando il valore giorno.

Se possibile, utilizza valori di stringa leggibili nelle chiavi di riga. Questo semplifica l'utilizzo dello strumento Key Visualizer per risolvere i problemi relativi a Bigtable.

Spesso è bene progettare chiavi di riga che inizino con un valore comune e terminino con un valore granulare. Ad esempio, se la chiave di riga include un continente, un paese e città, puoi creare chiavi di riga simili alla seguente, in modo che ordinare automaticamente prima in base ai valori con cardinalità più bassa:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Chiavi di riga da evitare

Alcuni tipi di chiavi di riga possono rendere difficile l'esecuzione di query sui dati e alcuni in uno scarso rendimento. Questa sezione descrive alcuni tipi di chiavi di riga che non dovresti usare Bigtable.

Chiavi di riga che iniziano con un timestamp. Questo pattern causa scritture sequenziali per il push su un singolo nodo, creando un hotspot. Se inserisci un timestamp in una chiave di riga, anteponi un valore ad alta cardinalità come un ID utente per evitare gli hotspot.

Chiavi di riga che impediscono il raggruppamento dei dati correlati. Evita chiavi di riga che fanno sì che i dati correlati vengano archiviati in intervalli di righe non contigui, inefficienti da leggere insieme.

ID numerici sequenziali. Supponiamo che il tuo sistema assegni un ID numerico a per ciascuno degli utenti della tua applicazione. Potresti essere tentato di usare il valore numerico dell'utente ID come chiave di riga per la tabella. Tuttavia, poiché è più probabile che i nuovi utenti utenti attivi, è probabile che questo approccio indirizzi la maggior parte del traffico a un di nodi.

Un approccio più sicuro consiste nell'utilizzare una versione invertita dell'ID numerico dell'utente, che distribuisce il traffico in modo più uniforme tra tutti i nodi per Bigtable.

Identificatori aggiornati di frequente. Evita di utilizzare una singola chiave di riga per identificare un che deve essere aggiornato di frequente. Ad esempio, se archivi l'utilizzo della memoria relativi a un certo numero di dispositivi una volta al secondo, non utilizzare una singola chiave di riga per ogni dispositivo costituito dall'ID dispositivo e dalla metrica da memorizzare, come 4c410523#memusage e aggiorna la riga ripetutamente. Questo tipo di operazione sovraccarica il tablet in cui è archiviata la riga usata di frequente. Può anche causare riga per superare il limite di dimensione, perché i valori precedenti di una colonna occupano spazio fino a quando le celle non vengono rimosse durante la garbage collection.

Archivia invece ogni nuova lettura in una nuova riga. Utilizzando l'esempio di utilizzo della memoria, ogni chiave di riga può contenere l'ID dispositivo, il tipo di metrica e un timestamp, Le chiavi di riga sono simili a 4c410523#memusage#1423523569918. Questa strategia è efficiente perché in Bigtable, la creazione di una nuova riga non richiede anziché creare una nuova cella. Inoltre, questa strategia consente di velocizzare leggere i dati di un determinato intervallo di date calcolando i valori di inizio di fine chiave.

Per i valori che cambiano di frequente, ad esempio un contatore che viene aggiornato centinaia di volte al minuto, è meglio conservare i dati in memoria, a livello di applicazione e scrivere nuove righe in Bigtable periodicamente.

Valori con hash. L'hashing di una chiave di riga ti impedisce di sfruttare L'ordinamento naturale di Bigtable, che rende impossibile l'archiviazione di righe in un modo ottimale per l'esecuzione di query. Per lo stesso motivo, l'hashing dei valori complica l'utilizzo dello strumento Key Visualizer per risolvere i problemi relativi Bigtable. Utilizza valori leggibili anziché valori sottoposti ad hashing.

Valori espressi come byte non elaborati anziché stringhe leggibili da una persona. Byte non elaborati vanno bene per i valori delle colonne, ma per la leggibilità e la risoluzione dei problemi, usa la stringa nelle chiavi di riga.

Casi d'uso speciali

Potresti avere un set di dati univoco che richiede una particolare attenzione durante la progettazione uno schema per archiviarli in Bigtable. Questa sezione ne descrive alcune, non tutti, i diversi tipi di dati Bigtable e alcuni tattiche per archiviarli nel modo ottimale.

Dati basati sul tempo

Includi un timestamp nella chiave di riga se recuperi spesso i dati in base nel momento in cui è stata registrata.

Ad esempio, la tua applicazione potrebbe registrare dati relativi alle prestazioni, come la CPU una volta al secondo per molte macchine. La tua chiave di riga per questi dati puoi combinare un identificatore della macchina con un timestamp per i dati (ad ad esempio machine_4223421#1425330757685). Tieni presente che le chiavi di riga ordinate lessicograficamente.

Non utilizzare un timestamp da solo o all'inizio di una chiave di riga, perché questo causa il push delle scritture sequenziali su un singolo nodo, creando un hotspot. In questo caso, devi considerare i pattern di scrittura e leggere pattern.

Se di solito recuperi i record più recenti per primi, puoi utilizzare un timestamp nella chiave di riga sottraendo il timestamp dalla tua programmazione valore massimo del linguaggio per i numeri interi lunghi (in Java, java.lang.Long.MAX_VALUE). Con il timestamp invertito, i record vengono ordinati dal più recente al meno recente recenti.

Per informazioni specifiche sull'utilizzo dei dati delle serie temporali, consulta la sezione Schema per i dati delle serie temporali.

Multitenancy

I prefissi delle chiavi di riga forniscono una soluzione scalabile per una "multi-tenancy" un caso d'uso, scenario in cui si archiviano dati simili, utilizzando lo stesso modello dei dati, per conto di più clienti. Utilizzare un'unica tabella per tutti i tenant è il modo più efficiente per archiviare e accedere ai dati multi-tenant.

Ad esempio, supponiamo che tu memorizzi e monitori le cronologie di acquisto per conto di molti aziende. Puoi utilizzare il tuo ID univoco per ogni azienda come prefisso della chiave di riga. Tutti per un tenant sono archiviati in righe contigue nella stessa tabella e puoi o filtrare utilizzando il prefisso della chiave di riga. Quindi, quando un'azienda non è più del cliente e dovrai eliminare i dati della cronologia acquisti che stavi archiviando azienda, puoi eliminare l'intervallo di righe che utilizzano tale prefisso della chiave di riga del cliente.

Ad esempio, se archivi i dati dei dispositivi mobili dei clienti altostrat e examplepetstore, puoi creare chiavi di riga come la seguente. Quindi, se altostrat non è più il tuo cliente, elimini tutte le righe con la chiave di riga prefisso altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Al contrario, se archivi i dati per conto di ciascuna azienda in una propria tabella, si possono verificare problemi di prestazioni e scalabilità. È inoltre più probabile che raggiungere inavvertitamente il limite di 1000 tabelle per istanza di Bigtable. Quando un'istanza raggiunge questo limite, Bigtable ti impedisce creando altre tabelle nell'istanza.

Privacy

Evita di usare informazioni che consentono l'identificazione personale, a meno che il tuo caso d'uso non lo richieda (PII) o dati utente nelle chiavi di riga o negli ID famiglia di colonne. I valori nelle chiavi di riga e le famiglie di colonne sono sia dati dei clienti che dati di servizio, nonché applicazioni che come la crittografia o il logging, potrebbero esporli inavvertitamente agli utenti che non devono avere accesso a dati privati.

Per ulteriori informazioni su come vengono gestiti i dati dei servizi, consulta la sezione Google Cloud privacy Avviso.

Nomi di dominio

Puoi archiviare i nomi di dominio come dati Bigtable.

Ampia gamma di nomi di dominio

Se archivi dati su entità che possono essere rappresentate come nomi di dominio, valuta la possibilità di utilizzare un nome di dominio inverso (ad es. com.company.product) come chiave di riga. L'utilizzo di un nome di dominio inverso è una buona idea se il nome di ogni riga i dati tendono a sovrapporsi a righe adiacenti. In questo caso, Bigtable può comprimere i dati in modo più efficiente.

Al contrario, nomi di dominio standard che non vengono invertiti possono causare la visualizzazione di righe ordinati in modo tale che i dati correlati non vengano raggruppati in un'unica posizione, il che può comportare una compressione meno efficiente e letture meno efficienti.

Questo approccio funziona al meglio quando i dati sono distribuiti su più nomi di dominio.

Per spiegare questo punto, consideriamo i seguenti nomi di dominio, ordinati in ordine lessicografico in base a Bigtable:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Ciò non è consigliabile per il caso d'uso in cui vuoi eseguire query su tutte le righe per google.com. Al contrario, considera le stesse righe in cui i nomi di dominio contengono invertito:

      com.google.drive
      com.google.maps
      org.wikipedia.en

Nel secondo esempio, le righe correlate vengono ordinate automaticamente in modo da semplifica il recupero come intervallo di righe.

Pochi nomi di dominio

Se prevedi di archiviare molti dati solo per un dominio o per un numero ridotto di domini di riga di comando, considera altri valori per la chiave di riga. In caso contrario, potresti eseguire il push delle scritture a un singolo nodo nel tuo cluster, generando hotspot oppure le tue righe potrebbero aumentare troppo grande.

Query modificate o incerte

Se non esegui sempre le stesse query sui tuoi dati o non sai le tue query, un'opzione è archiviare tutti i dati di una riga anziché più colonne. Con questo approccio, utilizzi un formato rende meno difficile estrarre i singoli valori in un secondo momento, come il protocollo formato binario del buffer o un file JSON.

La chiave di riga è ancora progettata appositamente per garantire il recupero dei dati necessarie, ma in genere ogni riga contiene una sola colonna che contiene tutti i dati per la riga in un singolo protobuf.

Archiviazione dei dati come messaggio protobuf in una colonna anziché diffondere i dati in più colonne presenta vantaggi e svantaggi. I vantaggi includono seguenti:

I dati occupano meno spazio e quindi costa meno archiviarli.
Manterrai un certo livello di flessibilità se non ti impegni a utilizzare la colonna le famiglie e i qualificatori di colonna.
La tua applicazione di lettura non ha bisogno di "sapere" qual è lo schema della tabella.

Ecco alcuni svantaggi:

Devi deserializzare i messaggi protobuf dopo che sono stati letti Bigtable.
Perdi l'opzione di eseguire query sui dati nei messaggi protobuf utilizzando i filtri.
Non puoi utilizzare BigQuery per eseguire query federate sui campi all'interno di i messaggi protobuf dopo averli letti da Bigtable.