Best practice di progettazione dello schema

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

  • Concetti generali: concetti di base da tenere presenti durante la progettazione dello schema.
  • Best practice: linee guida per il design che si applicano alla maggior parte dei casi d'uso, suddivise per componente della tabella.
  • Casi d'uso speciali: consigli per alcuni casi d'uso e pattern di dati specifici.

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 la crei o la aggiorni, 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, inclusa 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 è incentrata 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 consigli in questa pagina sono progettati per aiutarti a eseguire l'ottimizzazione per le letture di intervalli di righe. Nella maggior parte dei casi, significa inviare una query basata sui 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 di 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 sono presenti indici secondari. Ogni chiave di riga deve essere univoca.
  • Le righe sono ordinate lessicograficamente in base alla chiave di 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 memorizzate in un 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 una colonna può contenere più celle con timestamp. Ogni cella contiene una versione univoca e con timestamp dei dati per quella riga e 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 interessa o un'intera riga o nessuna 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 è diverso e richiede un proprio design, ma le seguenti best practice si applicano alla 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. Consulta la sezione Quote e limiti per informazioni sui limiti di dimensioni consigliati e obbligatori per tutti gli elementi della tabella.

Poiché tutte le tabelle di un'istanza sono archiviate negli stessi tablet, un design dello schema che genera 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 i set di dati con schemi simili nella stessa tabella anziché in 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 prefisso della chiave di riga univoco da utilizzare per ogni set di dati, in modo che Bigtable memorizzi 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 il carico delle connessioni al backend, con conseguente aumento della latenza finale.
  • La creazione di più tabelle non migliora il bilanciamento del carico e può aumentare il sovraccarico di gestione.

Potresti giustamente volere una tabella separata per un caso d'uso diverso che richiede uno schema diverso, ma non dovresti utilizzare tabelle separate per dati simili. Ad esempio, non dovresti creare una nuova tabella perché è iniziato un nuovo anno o perché hai un nuovo cliente.

Famiglie di colonne

Riunisci le colonne correlate nella stessa famiglia di colonne. Quando una riga contiene più valori correlati tra loro, è buona norma raggruppare le colonne che contengono questi 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 calo 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 memorizzarlo in una famiglia di colonne impostata per archiviare 1000 versioni di qualcos'altro. In caso contrario, pagherai per archiviare 999 celle di dati che non ti servono.

Colonne

Crea nella tabella tutte le colonne di cui hai bisogno. Le tabelle Bigtable sono sparse e non viene applicata alcuna penalità per lo spazio per una colonna non utilizzata in 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, una riga non dovrebbe. 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 memorizzi 1 KB (1024 byte) di dati, è molto più efficiente in termini di spazio archiviarli in una singola cella anziché distribuirli su 1024 celle contenenti ciascuna 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 esempio, le righe potrebbero avere il seguente aspetto:

Chiave di riga Fred Gabriel Hiroshi Seo Yoon Jakob
Jose book-club lavoro tennis
Sofia lavoro scuola club-di-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
Jose#2 Gabriel lavoro
Jose#3 Hiroshi tennis
Sofia#1 Hiroshi lavoro
Sofia#2 Seo Yoon scuola
Sofia#3 Jakob club-di-scacchi

Il secondo design 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 di 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 in una singola riga non superino 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 di una tabella, è possibile che un aggiornamento venga completato correttamente e l'altro no. Assicurati che lo schema non richieda l'aggiornamento di più righe contemporaneamente per garantire l'accuratezza dei dati correlati. Questa pratica garantisce che se parte di una richiesta di scrittura non va a buon fine o deve essere inviata di nuovo, quel dato non sia 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 è costituita dai 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 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 il valore aggregato degli eventi per un'entità, ad esempio la somma mensile delle vendite per dipendente in un negozio di vendita al dettaglio, puoi utilizzare gli 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 metodi:

  • 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 subito la chiave di riga corretta, puoi evitare un laborioso processo di migrazione dei dati in un secondo momento.

Mantieni brevi le chiavi di riga. 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 della chiave di riga sono in genere separati da un delimitatore, ad esempio i due punti, la barra o il simbolo hash. Il primo segmento o insieme di segmenti contigui è il prefisso della chiave di riga e l'ultimo segmento o insieme di segmenti contigui è il suffisso della chiave di riga.

Chiave di riga di esempio

Prefissare le chiave 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 memorizzare o ordinare in ordine numerico, aggiungere zero iniziali ai numeri interi. Bigtable archivia i dati in ordine alfabetico. Ad esempio, dal punto di vista lessicografico, 3 > 20, ma 20 > 03. L'aggiunta di uno zero iniziale al 3 garantisce che i numeri vengano ordinati in ordine numerico. 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 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 chiave di riga composta da tipo di dispositivo, ID dispositivo e giorno di registrazione dei dati. Le chiavi di riga per questi dati potrebbero avere il seguente aspetto:

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

Questo design della chiave di riga ti consente di recuperare i dati con una singola richiesta per:

  • Un tipo di dispositivo
  • Una combinazione di tipo di dispositivo e ID dispositivo

Questo design della chiave di riga non è ottimale se vuoi recuperare tutti i dati per un determinato 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 invece inviare una richiesta di lettura con un filtro che esamini l'intera tabella alla ricerca del valore del 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 una città, puoi creare chiavi di riga come quelle riportate di seguito in modo che vengano ordinate automaticamente in base ai valori con cardinalità inferiore:

        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 complicare le query sui dati e alcuni possono portare a un rendimento scadente. 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é i nuovi utenti hanno maggiori probabilità di essere attivi, questo approccio potrebbe indirizzare la maggior parte del traffico verso un numero ridotto di nodi.

Un approccio più sicuro è utilizzare una versione invertita dell'ID numerico dell'utente, che distribuisce il traffico in modo più uniforme tra tutti i nodi della 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 memorizzi i dati sull'utilizzo della memoria per una serie di dispositivi una volta al secondo, non utilizzare una singola chiave di riga per ogni dispositivo composta dall'ID dispositivo e dalla metrica memorizzata, ad esempio 4c410523#memusage, e aggiornare la riga ripetutamente. Questo tipo di operazione sovraccarica il tablet che memorizza la riga utilizzata di frequente. Inoltre, può 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 il garbage collection.

Memorizza 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, quindi le chiavi di riga sono simili a 4c410523#memusage#1423523569918. Questa strategia è efficiente perché in Bigtable la creazione di una nuova riga non richiede più tempo della creazione di 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'ordine di ordinamento naturale di Bigtable, rendendo impossibile memorizzare le righe in modo ottimale per le 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 sottomessi ad hashing.

Valori espressi come byte non elaborati anziché come stringhe leggibili. 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 considerazione speciale durante la progettazione di uno schema per archiviarlo 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

Se spesso recuperi i dati in base all'ora in cui sono stati registrati, puoi includere un timestamp nella chiave di riga.

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 chiave di riga per questi dati potrebbe combinare un identificatore della macchina con un timestamp per i dati (ad es.machine_4223421#1425330757685). Tieni presente che le chiavi di riga sono ordinate in ordine alfabetico.

Se includi i timestamp nella chiave di riga, non utilizzare un timestamp da solo o all'inizio di una chiave di riga. Questo pattern fa sì che le scritture sequenziali vengano inviate su un singolo nodo, creando un hotspot.

Se di solito nelle query recuperi per primi i record più recenti, un pattern da prendere in considerazione è l'utilizzo di timestamp invertiti nella chiave di riga. Questo pattern fa sì che le righe vengano ordinate dalla più recente alla meno recente, quindi i dati più recenti si trovano all'inizio della tabella. Come per qualsiasi timestamp, evita di iniziare una chiave di riga con un timestamp invertito per non creare hotspot.

Per ottenere un timestamp invertito, sottrai il timestamp dal valore massimo del linguaggio di programmazione per numeri interi lunghi (in Java,java.lang.Long.MAX_VALUE).

Per informazioni specifiche sull'utilizzo dei dati delle serie temporali, consulta Design dello 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 dei dati, per conto di più client. L'utilizzo di una 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 i dati di un tenant vengono archiviati in righe contigue nella stessa tabella e puoi eseguire query o filtrare utilizzando il prefisso della chiave di riga. Poi, quando un'azienda non è più il tuo cliente e devi eliminare i dati della cronologia acquisti che stavi memorizzando per l'azienda, puoi eliminare l'intervallo di righe che utilizzano il 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 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

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. Una volta raggiunto questo limite, Bigtable impedisce di creare 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 ai dati privati.

Per saperne di più su come vengono gestiti i dati di servizio, 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 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 è un'idea particolarmente buona se i dati di ogni riga tendono a sovrapporsi a quelli delle 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 illustrare questo punto, prendi in considerazione i seguenti nomi di dominio, ordinati automaticamente in ordine alfabetico da 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 semplificarne il recupero come intervallo di righe.

Pochi nomi di dominio

Se prevedi di memorizzare molti dati solo per uno o un numero limitato di nomi di dominio, valuta la possibilità di utilizzare 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 incerte o in fase di modifica

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 che semplifica l'estrazione dei singoli valori in un secondo momento, ad esempio il formato binario del buffer del protocollo 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:

  • I dati occupano meno spazio, quindi il loro archiviazione costa meno.
  • Mantieni una certa flessibilità non impegnandoti a utilizzare famiglie di colonne e qualificatori di colonna.
  • L'applicazione di lettura non deve "sapere" qual è lo schema della tabella.

Ecco alcuni svantaggi:

  • Devi deserializzare i messaggi protobuf dopo averli letti da Bigtable.
  • Non potrai 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