Best practice di progettazione dello schema

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

• Concetti generali: concetti di base da tenere a mente durante la progettazione dello schema.
• Best practice: progetta linee guida applicabili 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 di Bigtable è diversa da quella per un database relazionale. Uno schema di 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 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, che include la struttura dei seguenti componenti:

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

Punto chiave: progetta lo schema per le query che prevedi di utilizzare.

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 suggerimenti in questa pagina sono progettati per aiutarti a ottimizzare 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 è quella di evitare gli hotspot. Per prevenire gli hotspot, devi considerare i pattern di scrittura e capire come 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 negozio 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 più alta. Le chiavi di riga sono ordinate in ordine di byte big-endian (a volte chiamato ordine di byte di rete), l'equivalente binario in ordine alfabetico.
• Le famiglie di colonne non vengono archiviate in un 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 ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, Bigtable archivia le colonne in questo ordine:

			SysMonitor
%di 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 con timestamp dei dati per la riga e la colonna in questione.
• Le famiglie di colonne aggregate contengono celle aggregate. Puoi creare famiglie di colonne contenenti 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 su nessuna riga.
• Idealmente, sia le letture che le scritture dovrebbero essere distribuite in modo uniforme nello spazio delle righe di una tabella.
• I tavoli multipiano sono pochi. Una colonna non occupa spazio in una riga che non la utilizza.

Best practice

Uno schema valido si traduce in prestazioni e scalabilità eccellenti e uno schema insoddisfacente può portare a un sistema dalle 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. Sono indicate le eccezioni.

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

• Tables
• Famiglie di colonne
• Colonne
• Righe
• Celle
• Chiavi di riga

Tutti gli elementi della tabella, in particolare le chiavi di riga, devono essere progettati tenendo a mente le richieste di lettura pianificate. Controlla le quote e i limiti per verificare i limiti consigliati e di dimensioni fisse per tutti gli elementi della tabella.

Poiché tutte le tabelle di un'istanza sono archiviate sugli stessi tablet, una progettazione dello schema che genera hotspot in una tabella può influire sulla latenza delle 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, 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 di 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 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 di backend, con un conseguente aumento della latenza di coda.
• La creazione di altre tabelle non migliora il bilanciamento del carico e può aumentare l'overhead associato alla gestione.

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

Famiglie di colonne

Inserisci le colonne correlate nella stessa famiglia di colonne. Quando una riga contiene più valori correlati l'uno all'altro, è buona norma raggruppare le colonne che contengono 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 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 che hanno esigenze di conservazione dei dati diverse in famiglie di colonne diverse. Questa prassi è importante se vuoi limitare i costi di archiviazione. I criteri di garbage collection sono 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 archiviarla 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 nella tabella tutte le colonne che ti servono. Le tabelle Bigtable sono sparse e non esiste una penalità di spazio per una colonna che non viene 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 no. Alcuni fattori contribuiscono a questa best practice:

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

Se il tuo set di dati richiede logicamente più colonne per riga di quante Bigtable possa 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é devi memorizzare un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando alla colonna un valore. Ad esempio, supponiamo che una tabella memorizzi 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. Allora il valore di ogni colonna in 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	Jakob
Jose	prenota 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 che invece ha le stesse colonne in ogni riga:

Chiave di riga	Amico	Cerchio
Jose n. 1	Federico	prenota club
Jose n. 2	Gabriele	lavoro
Jose n. 3	Hiroshi	tennis
Sofia n. 1	Hiroshi	lavoro
Sofia n. 2	Seo Yoon	scuola
Sofia n. 3	Jakob	club di scacchi

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

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 che vengono trasferiti per ogni richiesta. La dimensione massima è 16 kB.

Righe

Mantieni le dimensioni di tutti i valori in una singola riga al di sotto dei 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 su un'entità in una singola riga. Nella maggior parte dei casi d'uso, evita di archiviare i dati che devi leggere a livello atomico o tutti insieme in più righe per evitare incongruenze. Ad esempio, se aggiorni due righe in una tabella, è possibile che una riga venga aggiornata correttamente e l'aggiornamento dell'altra non vada a buon fine. Assicurati che lo schema non richieda più di una riga per essere aggiornata 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 di nuovo, quel dato non sarà temporaneamente incompleto.

Eccezione: se tenere un'entità in una singola riga genera righe di centinaia di MB, devi suddividere i dati in 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 è i dati archiviati per una determinata riga e colonna con un timestamp univoco e che più celle possono essere archiviate all'intersezione di quella riga e colonna. Il numero di celle conservate in una colonna è regolato dai criteri di garbage collection impostati per la famiglia di colonne contenente quella colonna.

Utilizza 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 i dati aggregati. Per ulteriori 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. 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. Scegliendo ora la chiave di riga corretta, puoi evitare un secondo processo di migrazione dei dati in un secondo momento difficile.

Utilizza chiavi di riga brevi. Una chiave di riga non deve superare i 4 kB. Le chiavi di riga lunghe occupano più memoria e spazio di archiviazione 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 generalmente separati da un delimitatore, ad esempio due punti, una barra o un simbolo di cancelletto. Il primo segmento o insieme di segmenti contigui corrisponde al prefisso della chiave di riga, mentre l'ultimo segmento o insieme di segmenti contigui corrisponde al suffisso della chiave di riga.

I prefissi chiave di riga ben pianificati consentono di sfruttare l'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 un intervallo di righe, anziché eseguire analisi delle tabelle inefficienti.

Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, inserisci i numeri interi utilizzando gli zeri iniziali. Bigtable archivia i dati lessicograficamente. Ad esempio, lessicograficamente, 3 > 20 ma 20 > 03. La spaziatura interna dei 3 con uno zero iniziale garantisce che i numeri siano ordinati numericamente. Questa tattica è importante per i timestamp in cui vengono utilizzate query basate su intervallo.

È importante creare una chiave di riga che permetta di recuperare un intervallo di righe ben definito. In caso contrario, la query richiede una scansione della tabella, 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 per:

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

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

Se possibile, utilizza valori stringa leggibili nelle chiavi di riga. Questa pratica semplifica l'utilizzo dello strumento Key Visualizer per la risoluzione dei 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 simili alle seguenti in modo che vengano automaticamente ordinate per prime 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

Nota: in produzione, utilizza identificatori che occupano meno spazio di archiviazione, come AS per l'Asia o 591 per la Bolivia.

Chiavi di riga da evitare

Alcuni tipi di chiavi di riga possono complicare l'esecuzione di query sui dati, mentre altri comportano 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 comporta 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 hotspot.

Chiavi di riga che impediscono il raggruppamento dei dati correlati. Evita chiavi di riga che causano l'archiviazione dei dati correlati in intervalli di righe non contigui, che non sono efficienti per la lettura insieme.

ID numerici sequenziali. Supponiamo che il tuo sistema assegni un ID numerico a ciascun utente dell'applicazione. Potresti avere la tentazione di utilizzare l'ID numerico dell'utente come chiave di riga della tabella. Tuttavia, poiché i nuovi utenti hanno maggiori probabilità di essere utenti attivi, è probabile che questo approccio spinga la maggior parte del traffico a un numero ridotto 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 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 i dati sull'utilizzo della memoria per diversi dispositivi una volta al secondo, non utilizzare una singola chiave di riga per ogni dispositivo composto dall'ID dispositivo e dalla metrica memorizzata, ad esempio 4c410523#memusage, e aggiorna la riga ripetutamente. Questo tipo di operazione sovrascrive il tablet in cui è archiviata la riga utilizzata di frequente. Può anche causare il superamento del limite di dimensione di una riga, in quanto 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 che la creazione 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 al minuto, è preferibile mantenere i dati in memoria, a livello di applicazione, e scrivere nuove righe in Bigtable periodicamente.

Valori sottoposti ad hashing. L'hashing di una chiave di riga elimina la possibilità di sfruttare l'ordinamento naturale di Bigtable, rendendo impossibile l'archiviazione delle righe in modo ottimale per le query. Per lo stesso motivo, l'hashing dei valori rende difficile l'utilizzo dello strumento Key Visualizer per la risoluzione dei problemi con Bigtable. Utilizzare valori leggibili da una persona invece di valori sottoposti ad hashing.

Valori espressi come byte non elaborati anziché come stringhe leggibili da una persona. I byte non elaborati sono validi per i valori delle colonne, ma per una maggiore leggibilità e risoluzione dei problemi è consigliabile utilizzare valori stringa nelle chiavi di riga.

Casi d'uso speciali

Potresti avere un set di dati univoco che richiede un'attenzione particolare durante la progettazione di uno schema per archiviarlo in Bigtable. Questa sezione descrive alcuni tipi di dati di Bigtable, ma non tutti, e alcune tattiche suggerite per archiviarli nel modo migliore possibile.

Dati basati sul tempo

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

Ad esempio, l'applicazione potrebbe registrare dati relativi alle prestazioni, come l'utilizzo di CPU e 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 esempio, machine_4223421#1425330757685). Tieni presente che le chiavi di riga sono ordinate lessicograficamente.

Non utilizzare il timestamp da solo o all'inizio di una chiave di riga, perché in questo modo verrà eseguito 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 del linguaggio di programmazione per i numeri interi lunghi (in Java, java.lang.Long.MAX_VALUE). Con un timestamp invertito, i record verranno ordinati dal più recente al meno recente.

Nota: in genere, i timestamp corrispondono al numero di microsecondi a partire dal 1° gennaio 1970 00:00:00 UTC.

Per informazioni specifiche sull'utilizzo dei dati di serie temporali, consulta Progettazione degli 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 archivi dati simili, utilizzando lo stesso modello dei 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 aziende. Puoi utilizzare il tuo ID univoco per ogni azienda come prefisso della chiave di riga. Tutti i dati di un tenant sono archiviati in righe contigue nella stessa tabella, ed è possibile eseguire query o applicare filtri utilizzando il prefisso della chiave di riga. Quando un'azienda non è più cliente e devi eliminare i dati della cronologia acquisti che memorizzavi per l'azienda, puoi trasmettere 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 riportato di seguito. Poi, se altostrat non è più il tuo cliente, elimina 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

Al contrario, se archivi i dati per conto di ciascuna azienda in una propria tabella, potresti 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 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 i dati dei clienti che i dati di servizio e le applicazioni che li utilizzano, come la crittografia o il logging, possono inavvertitamente esporli a utenti che non dovrebbero avere accesso ai dati privati.

Per ulteriori informazioni 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 stai memorizzando dati sulle 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 è particolarmente utile se i dati di ogni riga tendono a sovrapporsi con le 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 siano raggruppati in un unico luogo, il che può comportare una compressione meno efficiente e letture meno efficienti.

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

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

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

Questo non è consigliabile nel 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 recuperarle più facilmente come intervallo di righe.

Pochi nomi di dominio

Se prevedi di archiviare molti dati solo per uno o un numero limitato 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, con il risultato di hotspot o di dimensioni eccessive delle righe.

Query variabili o incerte

Se non sempre esegui le stesse query sui tuoi dati o non hai la certezza di quali saranno le query, una soluzione è archiviare tutti i dati di una riga in una sola colonna anziché in più colonne. Con questo approccio, utilizzi un formato che rende meno difficile l'estrazione dei singoli valori in un secondo momento, ad esempio il formato binario del buffer di protocollo o un file JSON.

La chiave di riga è stata progettata con attenzione per garantire il recupero dei dati necessari, ma in genere ogni riga 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 anziché diffonderli in più colonne presenta vantaggi e svantaggi. Ecco alcuni dei vantaggi:

• I dati occupano meno spazio, quindi l'archiviazione costa meno.
• Manterrai un certo grado di flessibilità se non ti impegni a definire le famiglie di colonne e i qualificatori di colonna.
• La tua applicazione di lettura non ha bisogno di "sapere" qual è lo schema della tabella.

Alcuni svantaggi sono i seguenti:

• Devi deserializzare i messaggi protobuf dopo che sono stati letti da Bigtable.
• Non potrai più 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

• Progetta uno schema per i dati delle serie temporali.
• Esamina i passaggi necessari per pianificare uno schema.
• Scopri i tipi di richieste di scrittura che puoi inviare a Bigtable.
• Implementa i contatori utilizzando le celle aggregate.
• Esamina le quote e i limiti applicabili.