Best practice di progettazione dello schema

Questa pagina contiene informazioni sulla progettazione dello schema Bigtable. Prima di leggere questa pagina, dovresti conoscere la panoramica di Bigtable. In questa pagina vengono trattati i seguenti argomenti:

  • Concetti generali: concetti di base da tenere presenti quando progetta lo schema.
  • Best practice: linee guida per la progettazione applicabili alla maggior parte dei casi d'uso, suddivise per componente della tabella.
  • Casi d'uso speciali: suggerimenti per alcuni casi d'uso e pattern di dati specifici.

Concetti generali

Progettare uno schema Bigtable è diverso da quello per un database relazionale. Uno schema Bigtable è definito dalla logica dell'applicazione anziché da un oggetto o un file 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 che scrivi nella tabella.

In Bigtable, uno schema è un progetto o un modello di una tabella, che include la struttura dei seguenti componenti della tabella:

  • 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 sulle 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 suggerimenti in questa pagina sono progettati per aiutarti a ottimizzare per le letture dell'intervallo di righe. Nella maggior parte dei casi, questo significa inviare una query basata sui prefissi dellechiave di rigaa.

Una considerazione secondaria è quella di evitare gli hotspot: per evitarli, devi considerare i pattern di scrittura e come puoi evitare di accedere a un piccolo spazio delle chiavi in un breve periodo di tempo.

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

  • Bigtable è un archivio chiave/valore, non un archivio relazionale. 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 ci sono indici secondari. Ogni chiave di riga deve essere univoca.
  • Le righe sono ordinate lessicograficamente per chiave di riga,dalla stringa di byte più bassa a quella con il valore più alto. 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 vengono 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 di ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, Bigtable archivia le colonne nel seguente ordine:
SysMonitor
%CPU DiskRead ID Memoria Priorità ProcessName Utente
  • L'intersezione di una riga e di una colonna può contenere più celle con timestamp. Ogni cella contiene una versione univoca dei dati con un timestamp per quella riga e colonna.
  • Le famiglie di colonne aggregate contengono celle aggregate. Puoi creare famiglie di colonne che contengono solo celle aggregate. Un'aggregazione consente di unire nuovi dati con quelli già presenti nella cella.
  • Tutte le operazioni sono atomiche a livello di riga. Un'operazione interessa un'intera riga o nessuna della riga.
  • Idealmente, sia le letture sia le scritture dovrebbero essere distribuite in modo uniforme nello spazio di riga di una tabella.
  • Le tabelle Bigtable sono sparse. Una colonna non occupa spazio in una riga che non usa la colonna.

Best practice

Uno schema buono si traduce in prestazioni e scalabilità eccellenti, mentre uno schema mal progettato può portare a un sistema dalle prestazioni scadenti. Ogni caso d'uso è diverso e richiede un design proprio, ma per la maggior parte dei casi d'uso si applicano le seguenti best practice. Sono previste eccezioni.

A partire dal livello di tabella e fino al livello della chiave di riga, le seguenti sezioni 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 conoscere i limiti di dimensioni consigliati e rigidi per tutti gli elementi della tabella.

Poiché tutte le tabelle di un'istanza sono archiviate sugli stessi tablet, una progettazione dello schema che prevede la presenza di hotspot in una tabella può influire sulla latenza di altre tabelle nella stessa istanza. 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 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. Tuttavia, in Bigtable è preferibile archiviare tutti i dati in un'unica tabella. Puoi assegnare un prefisso univoco della chiave di riga da utilizzare per ogni set di dati, in modo che Bigtable archivi i dati correlati in un intervallo contiguo di righe su cui puoi eseguire query in base al prefisso della chiave di riga.

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

  • L'invio di richieste a molte tabelle diverse può aumentare l'overhead della connessione al 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 caso d'uso diverso che richiede uno schema diverso, ma non è consigliabile utilizzare tabelle separate per dati simili. Ad esempio, non devi creare una nuova tabella perché è un nuovo anno o perché hai un nuovo cliente.

Famiglie di colonne

Inserisci le colonne correlate nella stessa famiglia di colonne. Quando una riga contiene più valori correlati tra loro, è buona norma raggruppare le colonne che contengono quei valori nella stessa famiglia di colonne. Raggruppa i dati nel modo più preciso possibile per evitare di dover progettare filtri complessi e ottenere solo le informazioni di cui hai bisogno, ma niente 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 trasferiti per ogni richiesta.

Inserisci le colonne con esigenze di conservazione dei dati diverse in famiglie di colonne diverse. 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 conservare solo la versione più recente di un determinato dato, non memorizzarla in una famiglia di colonne impostata per archiviare 1000 versioni di qualcos'altro. Altrimenti, paghi per archiviare 999 celle di dati che non ti servono.

Colonne

Crea tutte le colonne che vuoi nella tabella. Le tabelle Bigtable sono sparse e non è prevista alcuna penalità di spazio per una colonna che non viene utilizzata in 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, una riga non dovrebbe. Alcuni fattori contribuiscono a questa best practice:

  • Bigtable impiega tempo per elaborare ogni cella in una riga.
  • Ogni cella aggiunge un overhead alla quantità di dati archiviati nella tabella e inviati attraverso la rete. Ad esempio, se archivi 1 kB (1024 byte) di dati, archiviare i dati in una singola cella è molto più efficiente in termini di spazio, invece di distribuirli in 1024 celle contenenti 1 byte ciascuna.

Se il set di dati richiede logicamente più colonne per riga di quelle che Bigtable è in grado di elaborare in modo efficiente, valuta la possibilità di archiviare i dati come protobuf in una singola colonna.

Facoltativamente, puoi trattare i qualificatori di colonna come dati. Poiché è necessario archiviare un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando alla colonna un valore. Considera ad esempio 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 di quella riga può essere la cerchia sociale in cui si trova l'amico. In questo 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 schema per gli stessi dati che non trattano i qualificatori di colonna come dati e presentano 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 i qualificatori di colonna per archiviare i dati, assegna ai qualificatori di colonna nomi brevi ma significativi. Questo approccio consente di ridurre la quantità di dati trasferiti per ogni richiesta. La dimensione massima è 16 kB.

Righe

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

Conserva tutte le informazioni relative a un'entità in un'unica riga. Nella maggior parte dei casi d'uso, evita di archiviare i dati che devi leggere a livello atomico o tutti contemporaneamente in più ri righe, per evitare incoerenze. Ad esempio, se aggiorni due righe di una tabella, è possibile che una riga venga aggiornata correttamente e l'altra non vada a buon fine. Per garantire l'accuratezza dei dati correlati, assicurati che lo schema non richieda l'aggiornamento di più di una riga contemporaneamente. Questa prassi garantisce che, se una parte di una richiesta di scrittura non va a buon fine o debba essere inviata di nuovo, i dati non saranno temporaneamente incompleti.

Eccezione: se conservare un'entità in una singola riga genera righe che superano 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 un'unica cella. Ricorda che una cella contiene i dati archiviati per una determinata riga e colonna con un timestamp univoco e che è possibile archiviare più celle all'intersezione di quella riga e colonna. Il numero di celle conservate in una colonna è regolato dal criterio di garbage collection che imposti per la famiglia di colonne che la contiene.

Utilizza le celle aggregate per archiviare e aggiornare i dati aggregati. Se ti interessa solo il valore aggregato degli eventi per un'entità, ad esempio la somma mensile delle vendite per dipendente presso un negozio al dettaglio, puoi utilizzare i dati aggregati. Per maggiori informazioni, consulta Aggregare valori 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 tramite uno dei seguenti modi:

  • 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 un processo di migrazione dei dati complesso 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.

Archivia 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 chiara comprensione di come utilizzi i dati.

I segmenti chiave di riga sono in genere separati da un delimitatore, ad esempio due punti, una barra o un simbolo di hash. Il primo segmento o insieme di segmenti contigui è il prefisso della chiave di riga, mentre l'ultimo segmento o insieme di segmenti contigui è il suffisso della chiave di riga.

Chiave di riga di esempio

Prefissi chiave di riga ben pianificati consentono di sfruttare l'ordinamento integrato di Bigtable per archiviare i dati correlati in righe contigue. L'archiviazione dei dati correlati in righe contigue consente di accedere ai dati correlati come un intervallo di righe, anziché eseguire analisi delle tabelle inefficienti.

Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, aggiungi gli zeri iniziali ai numeri interi. Bigtable archivia i dati in modo lessicografico. ad esempio 3 > 20 e 20 > 03, dal punto di vista lesicografico. Aggiungere il 3 con uno zero iniziale assicura che i numeri vengano ordinati numericamente. Questa tattica è importante per i timestamp in cui vengono utilizzate query basate su intervalli.

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

Ad esempio, se la tua applicazione monitora i dati dei dispositivi mobili, puoi avere una chiave di riga composta dal tipo di dispositivo, dall'ID dispositivo e dal 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 è ottimale per recuperare tutti i dati di un determinato giorno. Poiché il giorno è archiviato nel terzo segmento, ovvero nel suffisso della chiave di riga, non puoi semplicemente richiedere un intervallo di righe in base al suffisso o a un segmento centrale della chiave di riga. Devi invece inviare una richiesta di lettura con un filtro che analizza l'intera tabella cercando il valore day.

Se possibile, utilizza valori di stringa leggibili nelle chiavi di riga. Questa pratica semplifica l'uso dello strumento Key Visualizer per la risoluzione dei problemi relativi a Bigtable.

Spesso, è necessario 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 una città, puoi creare chiavi di riga simili ai seguenti, in modo che vengano ordinate automaticamente per prime 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, mentre altri comportano prestazioni scarse. 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 causa il push delle scritture sequenziali 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 le chiavi di riga che causano l'archiviazione dei dati correlati 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 avere la tentazione di utilizzare l'ID numerico dell'utente come chiave di riga per la tabella. Tuttavia, poiché è più probabile che i nuovi utenti siano utenti attivi, è probabile che questo approccio esegua il push della maggior parte del traffico a un numero ridotto di nodi.

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

Identificatori aggiornati di frequente. Evita di utilizzare una singola chiave di riga per identificare un valore che deve essere aggiornato di frequente. Ad esempio, se archivi una volta al secondo i dati sull'utilizzo della memoria per un certo numero di dispositivi, non utilizzare una singola chiave di riga per ogni dispositivo costituito dall'ID dispositivo e dalla metrica da archiviare, ad esempio 4c410523#memusage, e aggiorna la riga ripetutamente. Questo tipo di operazione sovraccarica il tablet in cui è archiviata la riga utilizzata di frequente. Può anche causare il superamento del limite di dimensione di una riga, 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, pertanto le chiavi di riga sono simili a 4c410523#memusage#1423523569918. Questa strategia è efficace perché in Bigtable la creazione di una nuova riga non richiede più tempo rispetto a quella di una nuova cella. Inoltre, questa strategia consente di leggere rapidamente i dati di un intervallo di date specifico calcolando le chiavi di inizio e di fine appropriate.

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

Valori con hash. L'hashing di una chiave di riga impedisce di sfruttare l'ordinamento naturale di Bigtable, rendendo impossibile archiviare le 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 di 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 consentiti per i valori delle colonne, ma per la leggibilità e la risoluzione dei problemi, utilizza valori stringa nelle chiavi di riga.

Casi d'uso speciali

Potresti avere un set di dati univoco che richiede una particolare attenzione durante la progettazione di uno schema per archiviarlo in Bigtable. Questa sezione descrive alcuni tipi di dati Bigtable (ma non tutti) e alcune strategie suggerite per archiviarli nel modo ottimale.

Dati basati sul tempo

Includi un timestamp nella chiave di riga se recuperi spesso i dati in base all'ora in cui sono stati registrati.

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

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

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

Per informazioni specifiche sull'utilizzo dei dati delle serie temporali, consulta Progettazione di schemi per i dati delle serie temporali.

Multitenancy

I prefissi delle chiavi di riga offrono una soluzione scalabile per un caso d'uso "multi-tenancy", uno scenario in cui si archiviano dati simili utilizzando lo stesso modello dei dati per conto di più client. L'utilizzo di 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 molte aziende. Puoi utilizzare il tuo ID univoco per ogni azienda come prefisso della chiave di riga. Tutti i dati relativi a un tenant vengono archiviati in righe contigue nella stessa tabella e puoi eseguire query o filtrare utilizzando il prefisso della chiave di riga. Quando un'azienda non è più cliente e devi eliminare i dati della cronologia acquisti per l'azienda, puoi eliminare l'intervallo di righe che utilizzano il prefisso della chiave di riga di quel cliente.

Ad esempio, se stai archiviando i dati dei dispositivi mobili per i clienti altostrat e examplepetstore, puoi creare chiavi di riga come la seguente. Se altostrat non è più il tuo cliente, elimini tutte le righe con il prefisso della chiave di 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

Se invece archivi i dati per conto di ciascuna azienda nella propria tabella, puoi riscontrare problemi di prestazioni e scalabilità. Inoltre,è più probabile che tu possa raggiungere inavvertitamente il limite di 1000 tabelle per istanza di Bigtable. Quando un'istanza raggiunge questo limite, Bigtable ti impedisce di creare altre tabelle al suo interno.

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 corrispondono sia a dati dei clienti che a dati di servizio, pertanto le applicazioni che li utilizzano, come crittografia o logging, possono esporli inavvertitamente a utenti che non dovrebbero avere accesso a dati privati.

Per ulteriori informazioni sul modo in cui vengono gestiti i dati dei servizi, consulta l'Informativa sulla privacy di Google Cloud.

Nomi di dominio

Puoi archiviare i nomi di dominio come dati Bigtable.

Ampia gamma di nomi di dominio

Se stai archiviando dati relativi a 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 i dati di ogni riga 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 l'ordinamento delle righe 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 tra molti nomi di dominio inverso diversi.

Per spiegare questo punto, considera i seguenti nomi di dominio, ordinati automaticamente in ordine lessicografico da Bigtable:

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

Questa operazione è indesiderabile 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 poterle recuperare più facilmente come intervallo di righe.

Pochi nomi di dominio

Se prevedi di archiviare molti dati solo per uno o per un numero ridotto di nomi di dominio, prendi in considerazione altri valori per la chiave di riga. In caso contrario, potresti eseguire il push delle scritture su un singolo nodo nel tuo cluster, generando hotspot o le tue righe potrebbero diventare troppo grandi.

Query modificate o incerte

Se non esegui sempre le stesse query sui tuoi dati o se non sei sicuro di quali saranno le tue query, un'opzione è archiviare tutti i dati di una riga in un'unica colonna anziché in più colonne. Con questo approccio, viene utilizzato un formato che rende meno difficile estrarre i singoli valori in un secondo momento, ad esempio il formato binario del buffer di protocollo o un file JSON.

La chiave di riga è comunque progettata con attenzione per assicurarsi di poter recuperare i dati necessari, ma ogni riga in genere ha una sola colonna che contiene tutti i dati della riga in un singolo protobuf.

L'archiviazione dei dati come messaggio protobuf in una colonna invece di distribuirli in più colonne presenta vantaggi e svantaggi. Ecco alcuni dei vantaggi:

  • I dati occupano meno spazio e quindi costa meno archiviarli.
  • Manterrai un certo livello di flessibilità non impegnandoti a famigliere le colonne e ai qualificatori di colonna.
  • L'applicazione di lettura non ha bisogno di "sapere" qual è lo schema della tua tabella.

Ecco alcuni svantaggi:

  • Devi deserializzare i messaggi protobuf dopo che sono stati letti da 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 dei messaggi protobuf dopo averli letti da Bigtable.

Passaggi successivi