Best practice di progettazione dello schema

Questa pagina contiene informazioni sulla progettazione dello schema di 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 durante la progettazione dello 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 di applicazione anziché da un file o da un oggetto di definizione dello 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 un intervallo di righe è il modo più rapido per leggere i dati di Bigtable, i consigli in questa pagina sono progettati per aiutarti a eseguire l'ottimizzazione per le letture di intervalli di righe. Nella maggior parte dei casi, ciò significa inviare una query in base ai prefissi delle chiave di riga.

Un'altra considerazione è l'evitare gli hotspot. Per evitare gli hotspot, devi prendere in considerazione i pattern di scrittura e come evitare di accedere a un piccolo spazio di chiavi in breve tempo.

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

  • Bigtable è uno spazio di archiviazione chiave/valore, non relazionale. Non supporta le unioni 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 secondari. Ogni chiave di riga deve essere univoca.
  • Le righe sono ordinate lessicograficamente in base alla chiave riga, dalla stringa di byte più bassa a quella più alta. Le chiavi riga sono ordinate in ordine di byte big endian (a volte chiamato ordine di byte di rete), l'equivalente binario dell'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 lessicografico all'interno della famiglia di colonne. Ad esempio, in una famiglia di colonne denominata SysMonitor con qualificatori di colonna ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, Bigtable memorizza 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. Un aggregato consente di riunire 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 che le scritture dovrebbero essere distribuite in modo uniforme nello spazio delle righe di una tabella.
  • Le tabelle Bigtable sono sparse. Una colonna non occupa spazio in una riga che non la utilizza.

Best practice

Uno schema valido offre prestazioni e scalabilità eccellenti, mentre uno schema progettato male 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. Le eccezioni vengono indicate.

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

Tutti gli elementi della tabella, in particolare le chiavi di riga, devono essere progettati tenendo conto delle richieste di lettura pianificate. 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 nello stesso 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 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, puoi scegliere di archiviare i dati in più tabelle in base all'oggetto e al numero di colonne. In Bigtable, tuttavia, solitamente è meglio archiviare tutti i dati in una 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 il sovraccarico di 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

Riunisci 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 il più possibile per evitare di dover progettare filtri complessi e ottenere solo le informazioni di cui hai bisogno, ma non di più, nelle richieste di lettura più frequenti.

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 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 nella tabella tutte le colonne di cui hai bisogno. Bigtable sono sparse e non c'è alcuna penalità di spazio per una colonna che non viene utilizzata una riga. Puoi avere milioni di colonne in una tabella, a condizione che 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 questa best practice:

  • Bigtable impiega del tempo per elaborare ogni cella di una riga.
  • Ogni cella aggiunge un po' di overhead alla quantità di dati memorizzati nella tabella e inviati 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 tuo set di dati richiede logicamente più colonne per riga di quante Bigtable possa elaborare in modo efficiente, ti consigliamo di archiviare i dati come protobuf in una singola colonna.

Facoltativamente, puoi trattare i qualificatori di colonna come dati. Poiché devi memorizzare un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando alla colonna un nome con un valore. Ad esempio, considera una tabella che memorizza 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. Il valore di ogni colonna in quella riga può essere il circolo sociale in cui si trova l'amico. In questo ad esempio, le righe potrebbero avere il seguente aspetto:

Chiave di riga Fred Gabriel Hiroshi Seo Yoon Jakob
Jose club del libro lavoro tennis
Sofia lavoro scuola club degli scacchi

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

Chiave di riga Amico Galleria
Jose#1 Fred book-club
Giuseppe 2 Gabriele lavoro
Jose#3 Hiroshi tennis
Sofia n. 1 Hiroshi lavoro
Sofia#2 Seo Yoon scuola
Sofia n. 3 Jakob club-di-scacchi

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

Se utilizzi i qualificatori di colonna per archiviare i dati, assegna 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 le dimensioni di tutti i valori in una singola riga inferiori a 100 MB. Assicurati che i dati di una singola riga non superare i 256 MB. Le righe che superano questo limite possono comportare una riduzione delle prestazioni di lettura.

Mantieni tutte le informazioni di un'entità in una singola riga. Per la maggior parte dei casi d'uso, evita di memorizzare i dati che devi leggere in modo atomico, o tutti contemporaneamente, in più 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 l'aggiornamento di più righe 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 di centinaia di MB, devi suddividere i dati in più righe.

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

Celle

Non archiviare più di 10 MB di dati in una singola cella. Ricorda che una cella rappresenta i dati archiviati per una determinata 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 raccolta dei rifiuti impostato per la famiglia di colonne che contiene la 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, consulta Aggregare i valori al momento della scrittura.

Chiavi di riga

Crea la chiave di riga in base alle query che utilizzerai per recuperare i dati. Le chiavi di riga ben progettate consentono di ottenere 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. Le chiavi di riga lunghe occupano memoria e spazio di archiviazione aggiuntivi e aumentano il tempo necessario per ricevere risposte dal server Bigtable.

Memorizza più valori delimitati in ogni chiave di riga. Poiché il modo migliore per eseguire query su Bigtable in modo efficiente è tramite la chiave di riga, spesso è utile includere più identificatori nella chiave di riga. Quando la chiave di riga include più valori, è particolarmente importante avere una comprensione chiara di come utilizzi i dati.

I segmenti chiave di riga sono in genere 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

Prefissare le chiavi di riga in modo appropriato ti consente di sfruttare l'ordine di ordinamento integrato di Bigtable per archiviare i dati correlati in righe contigue. L'archiviazione di dati correlati in righe contigue ti consente di accedere ai dati correlati come intervallo di righe anziché eseguire scansioni della tabella inefficienti.

Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, riempire i numeri interi con zeri iniziali. Bigtable archivia i dati in ordine alfabetico. Ad esempio, dal punto di vista lessicografico, 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 vengono utilizzate query basate su intervalli.

È 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, che è molto più lenta del 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 di dispositivo 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 è memorizzato nel terzo segmento o nel suffisso della chiave di riga, non puoi semplicemente richiedere un intervallo di righe in base al suffisso o a un segmento intermedio della chiave di riga. Devi inviare una richiesta di lettura con un filtro che analizza l'intera tabella cercando il valore giorno.

Utilizza valori di stringa leggibili nelle chiavi di riga, se possibile. Questa pratica semplifica l'utilizzo dello strumento Key Visualizer per risolvere i problemi relativi a Bigtable.

Spesso, è consigliabile progettare chiavi di riga che iniziano con un valore comune e terminano 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 dovresti evitare di utilizzare in Bigtable.

Chiavi di riga che iniziano con un timestamp. Questo pattern fa sì che le scritture sequenziali vengano inviate su un singolo nodo, creando un hotspot. Se inserisci un timestamp in una chiave di riga, precedilo con un valore ad alta cardinalità come un ID utente per evitare 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, che sono inefficienti da leggere insieme.

ID numerici sequenziali. Supponiamo che il tuo sistema assegni un ID numerico a ciascuno degli utenti della tua applicazione. Potresti essere tentato di utilizzare l'ID numerico dell'utente 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 dimensioni, 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 ti consente di leggere rapidamente i dati di un intervallo di date specifico calcolando le chiavi di inizio e fine appropriate.

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

Valori sottoposti ad hashing. 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, i valori di hashing complicano l'utilizzo dello strumento Key Visualizer per risolvere i problemi relativi a Bigtable. Utilizza valori leggibili anziché valori sottoposti ad hashing.

Valori espressi come byte non elaborati anziché stringhe leggibili da una persona. I byte non elaborati sono adatti per i valori delle colonne, ma per la leggibilità e la risoluzione dei problemi, utilizza i valori delle stringhe 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 descrive alcuni, ma non tutti, i diversi tipi di dati di Bigtable e alcune tattiche suggerite per archiviarli nel modo più 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, l'applicazione potrebbe registrare dati relativi alle prestazioni, come l'utilizzo della CPU e della memoria, 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 per primi i record più recenti, puoi utilizzare un timestamp invertito nella chiave riga sottraendo il timestamp dal valore massimo del linguaggio di programmazione per 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 un caso d'uso "multi-tenancy", ovvero un scenario in cui memorizzi dati simili, utilizzando lo stesso modello di dati, per conto di più client. 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 acquisti per conto di molte società. 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 una società 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 per i clienti altostrat e examplepetstore, puoi creare chiavi di riga come quelle riportate di seguito. Poi, se altostrat non è più tuo cliente, elimina tutte le righe con il prefisso della chiave riga 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 ogni azienda nella relativa tabella, potresti riscontrare problemi di prestazioni e scalabilità. Inoltre, è più probabile che tu raggiunga inavvertitamente il limite di Bigtable di 1000 tabelle per istanza. Quando un'istanza raggiunge questo limite, Bigtable ti impedisce creando altre tabelle nell'istanza.

Privacy

A meno che il tuo caso d'uso non lo richieda, evita di utilizzare informazioni che consentono l'identificazione personale (PII) o dati utente nelle chiavi di riga o negli ID famiglia di colonne. I valori nelle chiavi di riga e nelle famiglie di colonne sono sia dati dei clienti sia dati di servizio e le applicazioni che li utilizzano, come la crittografia o la registrazione, possono esporli inavvertitamente a utenti che non dovrebbero 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 memorizzi dati su entità che possono essere rappresentate come nomi di dominio, valuta la possibilità di utilizzare un nome di dominio inverso (ad esempio 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, i nomi di dominio standard non invertiti possono causare l'ordinamento delle righe in modo che i dati correlati non vengano raggruppati in un unico posto, il che può comportare una compressione e letture meno efficienti.

Questo approccio funziona al meglio quando i dati sono distribuiti su molti nomi di dominio inversi diversi.

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

Questo non è auspicabile 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 sono stati invertiti:

      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 inviare le scritture a un singolo nodo del cluster, creando hotspot, oppure le righe potrebbero diventare troppo grandi.

Query modificate o incerte

Se non esegui sempre le stesse query sui dati o non sai quali saranno le tue query, una soluzione è memorizzare tutti i dati di una riga in una colonna anziché in 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 con attenzione per assicurarti di poter recuperare i dati di cui hai bisogno, ma in genere ogni riga ha una sola colonna che contiene tutti i dati della riga in un singolo protobuf.

La memorizzazione dei dati come messaggio protobuf in una colonna anziché suddividerli in più colonne presenta vantaggi e svantaggi. I vantaggi includono seguenti:

  • I dati occupano meno spazio e quindi costa meno archiviarli.
  • Mantieni una certa flessibilità non impegnandoti a utilizzare famiglie di colonne e 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 messaggi protobuf dopo averli letti da Bigtable.

Passaggi successivi