Progettazione di uno schema per i dati di serie temporali
Questa pagina descrive i pattern di progettazione dello schema per l'archiviazione dei dati delle serie temporali in Bigtable. Questa pagina si basa sulla progettazione dello schema e presuppone che tu abbia familiarità con i concetti e i consigli descritti in .
Una serie temporale è una raccolta di dati costituita da misurazioni e volte in cui vengono registrate le misurazioni. Esempi di serie temporali includono il comando seguenti:
- Tracciato della memoria utilizzata sul computer
- Temperatura nel tempo in una notizia
- Prezzi del mercato azionario in un determinato periodo di tempo
Uno schema buono si traduce in prestazioni e scalabilità eccellenti, mentre uno schema errato può portare a un sistema insoddisfacente. Tuttavia, la progettazione di uno schema singolo offre la soluzione migliore per tutti i casi d'uso.
I pattern descritti in questa pagina forniscono un punto di partenza. Il tuo indirizzo e le query che intendi usare sono gli aspetti più importanti prendi in considerazione quando progetti uno schema per i dati delle serie temporali.
I pattern di progettazione di base per l'archiviazione dei dati delle serie temporali in Bigtable sono i seguenti:
Dati per gli esempi
Per illustrare le differenze tra i pattern, gli esempi in questa pagina presuppongono che stai memorizzando i dati per un'app che registra misurazioni effettuate dai palloni meteorologici una volta al minuto. Usiamo event per indica una singola richiesta che scrive una o più celle contemporaneamente. Gli ID località corrispondono alle regioni di Google Cloud.
Misurazione | Esempio |
---|---|
|
|
Pressione (pascal) | 94587 |
Temperatura (Celsius) | 9,5 |
Umidità (percentuale) | 65 |
Altitudine (metri) | 601 |
Dati correlati | Esempio |
ID fumetto | 3698 |
Località | asia-southeast1 |
Timestamp1 | t2021-03-05-1204 |
Bucket di tempo
In un pattern a bucket temporale, ogni riga della tabella rappresenta un "bucket" del tempo,
ad esempio un'ora, un giorno o un mese. Una chiave di riga include un identificatore non timestamp,
ad esempio week49
, per il periodo di tempo registrato nella riga, insieme ad altre
identificare i dati.
Le dimensioni del bucket che utilizzi, ad esempio minuto, ora o giorno, dipende dalle query che intendi utilizzare e da quelle Limiti per le dimensioni dei dati Bigtable. Ad esempio, se le righe che contengono un'ora di dati hanno dimensioni maggiori rispetto alla dimensione massima consigliata per riga di 100 MB, poi le righe che rappresentano una mezz'ora o un minuto sono probabilmente una scelta migliore.
I vantaggi dei pattern di bucket temporali includono quanto segue:
Potrai ottenere un rendimento migliore. Ad esempio, se memorizzi 100 misurazioni, Bigtable scrive e legge le misurazioni più velocemente se sono in una riga o in 100 righe.
I dati archiviati in questo modo sono compressi in modo più efficiente rispetto ai dati in formato alto, e tabelle strette.
Gli svantaggi includono quanto segue:
- I pattern di progettazione dello schema time-bucket sono più complicati dei single-timestamp e può richiedere più tempo e impegno.
Aggiungere nuove colonne per nuovi eventi
In questo pattern a bucket temporale, scrivi una nuova colonna in una riga per ogni evento, archiviare i dati nel qualificatore di colonna anziché come valore di cella. Ciò significa che, per ogni cella, invii la famiglia di colonne, il qualificatore di colonna e timestamp, ma nessun valore.
Utilizzando questo pattern per i dati di esempio relativi ai palloncini meteo, ogni riga contiene tutti
le misurazioni per una singola metrica, ad esempio pressure
, per un singolo meteo
a palloncino nell'arco di una settimana. Ogni chiave di riga contiene la posizione, il fumetto
ID, metrica registrata nella riga e numero della settimana. Ogni volta che
fumetto riporta i dati relativi a una metrica, aggiungi una nuova colonna alla riga. La
qualificatore di colonna contiene la misura, la pressione in Pascal, per
minuto identificato dal timestamp della cella.
In questo esempio, dopo tre minuti una riga potrebbe avere il seguente aspetto:
Chiave di riga | 94558 | 94122 | 95992 |
---|---|---|---|
us-west2#3698#pressione#settimana1 | " (t2021-03-05-1200) | " (t2021-03-05-1201) | " (t2021-03-05-1202) |
I casi d'uso per questo pattern includono:
Non è necessario misurare le modifiche nei dati delle serie temporali.
Vuoi risparmiare spazio di archiviazione utilizzando qualificatori di colonna come dati.
Aggiungere nuove celle per nuovi eventi
In questo pattern a bucket temporale, aggiungi nuove celle alle colonne esistenti quando scrivere un nuovo evento. Questo pattern ti consente di sfruttare La capacità di Bigtable di archiviare più celle con timestamp di una determinata riga e colonna. È importante specificare le regole di garbage collection quando usi questo schema.
Utilizzando i dati dei palloni meteo come esempio, ogni riga contiene tutti i
misurazioni per una singola mongolfiera nel corso di una settimana. La chiave di riga
è un identificatore della settimana, in modo da poter leggere il valore di
per più fumetti con una singola query. Gli altri segmenti chiave di riga
la posizione in cui funziona il palloncino e il numero ID del palloncino. La
tabella ha una famiglia di colonne, measurements
, e questa famiglia di colonne ne ha una
colonna per ogni tipo di misurazione: pressure
, temperature
, humidity
e
altitude
.
Ogni volta che un palloncino invia le sue misurazioni, l'applicazione scrive nuovi valori nella riga che contiene i dati della settimana corrente per il fumetto, scrivendo celle aggiuntive con timestamp in ogni colonna. Alla fine della settimana, ogni colonna di ogni riga ha una misurazione per ogni minuto della settimana oppure 10.080 celle (se il criterio di garbage collection lo consente).
Ogni colonna di ogni riga contiene una misurazione per ogni minuto della settimana. In questo dopo tre minuti, le prime due colonne di una riga potrebbero avere il seguente aspetto:
Chiave di riga | pressione | temp |
---|---|---|
asia-south2#3698#settimana1 | 94558 (t2021/03/05/1200) | 9.5 (t2021/03/05/1200) |
94122 (t2021/03/05/1201) | 9.4 (t2021/03/05/1201) | |
95992 (t2021/03/05/1202) | 9.2 (t2021/03/05/1202) |
I casi d'uso per questo pattern includono:
- Vuoi poter misurare i cambiamenti nelle misurazioni nel tempo.
Righe con timestamp singolo
Con questo pattern, crei una riga per ogni nuovo evento o misurazione anziché aggiungendo celle alle colonne nelle righe esistenti. Il suffisso della chiave di riga è il timestamp valore. Le tabelle che seguono questo schema tendono a essere alte e strette e ogni colonna di una riga contiene solo una cella.
Timestamp singolo serializzato
Con questo schema, archivi tutti i dati di una riga in una singola colonna in un in un formato serializzato, ad esempio un buffer di protocollo (protobuf). Questo approccio è descritti più dettagliatamente nella sezione Progettazione dello schema.
Ad esempio, se utilizzi questo pattern per memorizzare i dati dei palloni meteo, i tuoi potrebbe avere il seguente aspetto dopo quattro minuti:
Chiave di riga | measurements_blob |
---|---|
us-west2#3698#2021-03-05-1200 | protobuf_1 |
us-west2#3698#2021-03-05-1201 | protobuf_2 |
us-west2#3698#2021-03-05-1202 | protobuf_3 |
us-west2#3698#2021-03-05-1203 | protobuf_4 |
I vantaggi di questo modello includono quanto segue:
Efficienza di archiviazione
Velocità
Gli svantaggi includono quanto segue:
Impossibilità di recuperare solo determinate colonne quando leggi i dati
La necessità di deserializzare i dati dopo averli letti
I casi d'uso per questo pattern includono:
Non hai la certezza di come eseguirai query sui dati, altrimenti le query potrebbero possono variare.
La necessità di contenere i costi supera l'esigenza di filtrare i dati prima di recuperarlo da Bigtable.
Ogni evento contiene così tante misurazioni che potresti superare il limite di 100 MB per riga se archivi i dati in più righe colonne.
Timestamp singolo non serializzato
Con questo pattern, memorizzi ogni evento in una riga separata, anche se stai registrando con una sola misurazione. I dati nelle colonne non sono serializzati.
I vantaggi di questo modello includono quanto segue:
Di solito è più semplice da implementare rispetto a un pattern time-bucket.
Potresti dedicare meno tempo al perfezionamento dello schema prima di utilizzare li annotino.
Gli svantaggi di questo modello spesso superano i vantaggi:
Bigtable offre prestazioni inferiori con questo pattern.
I dati archiviati in questo modo non vengono compressi in modo efficiente come i dati colonne.
Anche quando il timestamp si trova alla fine della chiave di riga, questo pattern può negli hotspot.
I casi d'uso per questo pattern includono:
Vuoi recuperare sempre tutte le colonne ma solo un intervallo specificato di i timestamp, ma hai un motivo per non archiviare i dati in un alla struttura del centro di costo.
Vuoi archiviare un numero illimitato di eventi.
Utilizzando i dati di esempio relativi ai palloncini meteo, la famiglia di colonne e qualificatori di colonna sono gli stessi dell'esempio in cui vengono utilizzati bucket di tempo e nuove celle. In questo modello, tuttavia, ogni serie di misurazioni riportate per ciascun tempo atmosferico il palloncino è scritto in una nuova riga. La tabella seguente mostra cinque righe corrispondenti scritte utilizzando questo pattern:
Chiave di riga | pressione | temperatura | umidità | altitudine |
---|---|---|---|---|
us-west2#3698#2021-03-05-1200 | 94558 | 9,6 | 61 | 612 |
us-west2#3698#2021-03-05-1201 | 94122 | 9,7 | 62 | 611 |
us-west2#3698#2021-03-05-1202 | 95992 | 9,5 | 58 | 602 |
us-west2#3698#2021-03-05-1203 | 96025 | 9,5 | 66 | 598 |
us-west2#3698#2021-03-05-1204 | 96021 | 9,6 | 63 | 624 |
Strategie aggiuntive
Se devi inviare più query diverse per lo stesso set di dati, considera la possibilità per archiviare i dati in più tabelle, ciascuna con una chiave di riga progettata per uno le query.
In alcuni casi puoi anche combinare i pattern. Ad esempio, puoi archiviare dati serializzati nelle righe che rappresentano bucket temporali, a patto che le righe non diventino troppo grandi.
Passaggi successivi
- Rivedi i passaggi necessari per pianificare uno schema.
- Scopri le best practice per la progettazione di uno schema.
- Scopri le prestazioni che puoi aspettarti da Bigtable.
- Esplora le funzionalità di diagnostica di Key Visualizer.