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. Questa pagina tratta i seguenti argomenti:
- Concetti generali: concetti di base da tenere a mente durante la progettazione dello schema.
- Best practice: linee guida di progettazione 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 dell'applicazione anziché da un file o 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 patterchiave di rigaga 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 criteri di garbage collection
- Colonne
In Bigtable, la progettazione dello schema è determinata principalmente dalle query, o richieste di lettura, che prevedi di inviare alla tabella. Poiché la lettura di un intervallo di righe è il modo più veloce per leggere i dati Bigtable, i consigli in questa pagina sono progettati per aiutarti a ottimizzare le letture dell'intervallo di righe. Nella maggior parte dei casi, ciò significa inviare una query basata sui prefissi delle chiave di riga.
Un'altra considerazione è l'evitare gli hotspot. Per evitarli, devi considerare i pattern di scrittura e come evitare di accedere a uno spazio chiave ridotto in un breve periodo di tempo.
I seguenti concetti generali si applicano alla progettazione dello schema Bigtable:
- Bigtable è uno spazio di archiviazione chiave/valore, non relazionale. Non supporta i join e le transazioni sono supportate solo all'interno di una singola riga.
- Ogni tabella ha un indice: la chiave di riga. Ogni chiave di riga deve essere univoca. Per creare un indice secondario, utilizza una vista materializzata continua. Per saperne di più, consulta Creare un indice secondario globale.
- Le chiavi di riga ordinano le righe lessicograficamente dalla stringa di byte più bassa a quella più alta. Questo ordine è big-endian (a volte chiamato ordine dei 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
SysMonitorcon qualificatori di colonnaProcessName,User,%CPU,ID,Memory,DiskReadePriority, Bigtable archivia 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 dei dati con 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 ti consente di unire 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.
- Le tabelle Bigtable sono sparse. Una colonna non occupa spazio in una riga che non la utilizza.
Best practice
Uno schema ben progettato garantisce prestazioni e scalabilità eccellenti, mentre uno schema progettato male può portare a un sistema con prestazioni scarse. Ogni caso d'uso è diverso e richiede una progettazione specifica, ma le seguenti best practice si applicano alla maggior parte dei casi d'uso. Le eccezioni sono 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 le quote e i limiti per 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 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, potresti scegliere di archiviare i dati in più tabelle in base all'argomento e al numero di colonne. In Bigtable, tuttavia, di solito è meglio archiviare tutti i dati in una sola 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 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 di backend, con conseguente aumento della latenza finale.
- La creazione di più tabelle non migliora il bilanciamento del carico e può aumentare l'overhead di gestione.
Potresti voler giustamente 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 devi creare una nuova tabella perché è iniziato 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, è consigliabile raggruppare le colonne che contengono questi valori nella stessa famiglia di colonne. Raggruppa i dati nel modo più preciso possibile per evitare di dover progettare filtri complessi e per 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. Le policy di garbage collection vengono impostate 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 memorizzare 1000 versioni di qualcos'altro. Altrimenti paghi per archiviare 999 celle di dati che non ti servono.
Colonne
Crea tutte le colonne che ti servono nella tabella. Le tabelle Bigtable sono sparse e non è prevista alcuna penalità di 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 sovraccarico alla quantità di dati memorizzati nella tabella e inviati sulla rete. Ad esempio, se memorizzi 1 KB (1024 byte) di dati, è molto più efficiente in termini di spazio memorizzare i dati in una singola cella, anziché distribuirli su 1024 celle che contengono 1 byte ciascuna.
Se il tuo set di dati richiede logicamente più colonne per riga di Bigtable può elaborare in modo efficiente, valuta la possibilità di archiviare i dati come protobuf in una singola colonna.
(Facoltativo) Puoi trattare i qualificatori di colonna come dati. Poiché devi memorizzare
un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando un valore al nome della colonna. 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 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 | Fred | Gabriel | Hiroshi | Seo Yoon | Jakob |
|---|---|---|---|---|---|
| Jose | book-club | lavorare al meglio | tennis | ||
| Sofia | lavorare al meglio | scuola | chess-club |
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 | Galleria |
|---|---|---|
| Jose#1 | Fred | book-club |
| Jose#2 | Gabriel | lavorare al meglio |
| Jose#3 | Hiroshi | tennis |
| Sofia#1 | Hiroshi | lavorare al meglio |
| Sofia#2 | Seo Yoon | scuola |
| Sofia#3 | Jakob | chess-club |
La seconda progettazione dello schema fa crescere la tabella molto più rapidamente.
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 è 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 per un'entità in una singola riga. Per la maggior parte dei casi d'uso, evita di archiviare i dati che devi leggere in modo atomico o tutti in una volta 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'altro aggiornamento non vada a buon fine. Assicurati che lo schema non richieda l'aggiornamento di più di una riga contemporaneamente per garantire l'accuratezza dei dati correlati. Questa pratica garantisce che se una parte di una richiesta di scrittura non va a buon fine o deve essere inviata di nuovo, la parte di dati non sia temporaneamente incompleta.
Eccezione:se il mantenimento di 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 è il dato memorizzato per una determinata riga e colonna con un timestamp univoco e che più celle possono essere memorizzate all'intersezione di quella riga e colonna. Il numero di celle conservate in una colonna è regolato dai criteri di garbage collection che hai 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 al dettaglio, puoi utilizzare gli aggregati. Per ulteriori informazioni, vedi Aggregare i valori al momento della scrittura.
Chiavi di riga
Progetta la chiave di riga in base alle query che utilizzerai per recuperare i dati. Le chiavi di riga ben progettate consentono di ottenere il miglior rendimento da Bigtable. Le query Bigtable più efficienti recuperano i dati utilizzando uno dei seguenti elementi:
- Chiave di riga
- Prefisso chiave di riga
- Intervallo di righe definito dalle chiavi iniziale e finale delle righe
Altri tipi di query attivano una scansione completa della tabella, che è molto meno efficiente. Se scegli la chiave di riga corretta ora, puoi evitare un processo di migrazione dei dati difficile in un secondo momento.
Mantieni brevi le chiavi di riga. Una chiave di riga deve essere pari o inferiore 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 interrogare 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 tuoi dati.
I segmenti della chiave di riga sono in genere separati da un delimitatore, ad esempio due punti, una barra o un simbolo 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.
I prefissi chiave di riga pianificati con cura ti consentono 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 consente di accedere ai dati correlati come intervallo di righe, anziché eseguire scansioni inefficienti delle tabelle.
Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, aggiungi zero iniziali ai numeri interi. Bigtable archivia i dati in ordine lessicografico. Ad esempio, in ordine lessicografico, 3 > 20 ma 20 > 03. L'aggiunta di uno zero iniziale al 3 garantisce 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 di righe ben definito. 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 costituita dal tipo di dispositivo, dall'ID dispositivo e dal giorno in cui vengono registrati i 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 sarebbe ottimale se volessi recuperare tutti i dati per un determinato giorno. Poiché il giorno è memorizzato nel terzo segmento o nel suffisso della chiave di riga, non puoi 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 esegue la scansione dell'intera tabella alla ricerca del valore del giorno.
Utilizza valori 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, devi 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 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 strutturate
Se prevedi di eseguire query sulla tabella utilizzando SQL, puoi definire chiavi di riga strutturate, che ti consentono di accedere ai dati Bigtable utilizzando chiavi in più parti, simili alle chiavi composte nei database relazionali. La definizione di chiavi di riga strutturate per una tabella consente di accedere a segmenti specifici delle chiavi di riga utilizzando GoogleSQL per le query Bigtable.
Le chiavi di riga strutturate vengono create automaticamente quando crei una vista materializzata continua. Per implementare chiavi di riga strutturate per una tabella Bigtable, puoi creare uno schema della chiave di riga che definisce il tipo di dati e la codifica di ogni segmento della chiave di riga. Bigtable archivia le chiavi riga come byte ordinati lessicograficamente e lo schema della chiave di riga indica a GoogleSQL per Bigtable come decodificare e interpretare questi byte.
Gli schemi delle chiavi di riga vengono ignorati quando esegui query sulla tabella utilizzando il metodo
ReadRows dell'API Bigtable Data con una libreria
client Bigtable.
Per saperne di più, consulta Gestire chiave di riga riga e Query chiave di riga riga.
Chiavi di riga da evitare
Alcuni tipi di chiavi di riga possono rendere difficile l'esecuzione di query sui dati e alcuni comportano un rendimento scarso. Questa sezione descrive alcuni tipi di chiavi di riga che devi evitare di utilizzare in Bigtable.
Chiavi di riga che iniziano con un timestamp. Questo pattern fa sì che le scritture sequenziali vengano inserite in 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 causano l'archiviazione di 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 ciascun utente 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 utenti attivi, questo approccio probabilmente spingerà la maggior parte del traffico verso 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 su 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 un numero 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 aggiorna ripetutamente la riga. Questo tipo di operazione
sovraccarica il tablet che memorizza la riga utilizzata di frequente. Può anche far sì che una riga superi il limite di dimensioni, perché i valori precedenti di una colonna occupano spazio finché le celle non vengono rimosse durante la 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 rispetto alla 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 frequentemente, ad esempio un contatore che viene aggiornato centinaia di volte al minuto, è meglio conservare i dati in memoria, a 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 archiviare le righe in modo ottimale per le query. Per lo stesso motivo, l'hashing dei valori rende difficile 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é come stringhe leggibili. I byte non elaborati vanno bene 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 unico 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 Bigtable e alcune tattiche suggerite per archiviarli nel modo più ottimale.
Dati basati sul tempo
Se recuperi spesso i dati in base all'ora in cui sono stati registrati, puoi includere un timestamp nella chiave di riga.
Ad esempio, la tua 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 per la macchina con un timestamp per i dati (ad esempio, machine_4223421#1425330757685). Tieni presente che le chiavi di riga sono
ordinate in ordine lessicografico.
Se includi 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 inserite in un singolo nodo, creando un hotspot.
Se di solito recuperi prima i record più recenti nelle query, un pattern da considerare è l'utilizzo di timestamp invertiti nella chiave di riga. Questo pattern fa sì che le righe vengano ordinate dalla più recente alla meno recente, in modo che i dati più recenti si trovino all'inizio della tabella. Come per qualsiasi timestamp, evita di iniziare una chiave di riga con un timestamp invertito per non causare hotspot.
Puoi ottenere un timestamp invertito sottraendo 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 Progettazione 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-tenant", uno scenario in cui memorizzi dati simili, utilizzando lo stessomodello dei datii, per conto di più clienti. L'utilizzo di una tabella per tutti i tenant è il modo più efficiente per archiviare e accedere ai dati multitenant.
Ad esempio, supponiamo che tu memorizzi e monitori le cronologie degli acquisti per conto di molte aziende. Puoi utilizzare l'ID univoco di 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ù un tuo cliente e devi eliminare i dati della cronologia acquisti che memorizzavi per l'azienda, puoi eliminare l'intervallo di righe che utilizzano il prefisso della chiave di riga del cliente.
Ad esempio, se memorizzi i dati dei dispositivi mobili per i clienti altostrat e
examplepetstore, puoi creare chiavi di riga come le seguenti. Poi, 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
Al contrario, se memorizzi i dati per conto di ogni azienda in una tabella separata, 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 la creazione di 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 che 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 del servizio, consulta l'Google Cloud Informativa sulla privacy.
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 soprattutto 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 punto, 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 inverso diversi.
Per illustrare questo punto, considera i seguenti nomi di dominio, ordinati automaticamente in ordine lessicografico 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 facilitarne il recupero come intervallo di righe.
Pochi nomi di dominio
Se prevedi di archiviare molti dati per uno o un numero ridotto di nomi di dominio, valuta altri valori per la chiave di riga. In caso contrario, potresti eseguire push delle scritture su un singolo nodo del cluster, causando hotspot, oppure le righe potrebbero diventare troppo grandi.
Query in evoluzione o incerte
Se non esegui sempre le stesse query sui tuoi dati o non sai quali saranno le tue query, un'opzione è 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 estrarre i singoli valori in un secondo momento, ad esempio il formato binario protocol buffer o un file JSON.
La chiave di riga è ancora progettata con cura 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 unico protobuf.
L'archiviazione dei dati come messaggio protobuf in una colonna anziché la loro distribuzione in più colonne presenta vantaggi e svantaggi. I vantaggi includono:
- I dati occupano meno spazio, quindi il costo di archiviazione è inferiore.
- Mantieni una certa flessibilità non impegnandoti con famiglie di colonne e qualificatori di colonne.
- L'applicazione di lettura non deve "sapere" qual è lo schema della tabella.
Alcuni svantaggi sono:
- Devi deserializzare i messaggi protobuf dopo averli letti da Bigtable.
- Perdi la possibilità 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
- Progetta uno schema per i dati delle serie temporali.
- Esamina i passaggi 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.