Progettazione dello schema per i dati delle 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 suggerimenti descritti in questa pagina.

Una serie temporale è una raccolta di dati costituita dalle misurazioni e dagli orari in cui queste vengono registrate. Ecco alcuni esempi di serie temporali:

  • Il grafico della memoria utilizzata sul computer
  • Temperatura nel tempo in un notiziario
  • I prezzi del mercato azionario in un determinato periodo di tempo

Uno schema valido produce prestazioni e scalabilità eccellenti, mentre uno schema non valido può portare a un sistema dalle prestazioni scadenti. Tuttavia, nessuno schema singolo è adatto a tutti i casi d'uso.

I pattern descritti in questa pagina forniscono un punto di partenza. Il set di dati univoco e le query che prevedi di utilizzare sono gli aspetti più importanti da considerare 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 tu stia memorizzando i dati per un'app che registra le misurazioni effettuate dai palloni meteorologici una volta al minuto. Usiamo event per indicare una singola richiesta che scrive una o più celle contemporaneamente. Gli ID località corrispondono alle regioni di Google Cloud.

Misurazione Esempio
  1. I timestamp in questa pagina sono nel formato "tAAAA-MM-GG-HHMM" per la leggibilità umana. In una tabella di produzione, i timestamp sono solitamente espressi come il numero di microsecondi a partire da 1970-01-0100:00:00 UTC, ad esempio "1616264288050807".
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

Intervalli di tempo

In un pattern di un bucket temporale, ogni riga della tabella rappresenta un "bucket" di tempo, ad esempio un'ora, un giorno o un mese. Una chiave di riga include un identificatore non timestamp, come week49, per il periodo di tempo registrato nella riga, insieme ad altri dati di identificazione.

Le dimensioni del bucket che utilizzi, ad esempio minuto, ora o giorno, dipendono dalle query che prevedi di utilizzare e dai limiti di dimensione dei dati di Bigtable. Ad esempio, se le righe che contengono un'ora di dati sono più grandi della dimensione massima consigliata di 100 MB, allora le righe che rappresentano mezz'ora o un minuto sono probabilmente una scelta migliore.

I vantaggi dei pattern di bucket di tempo includono quanto segue:

  • Il rendimento sarà migliore. Ad esempio, se archivi 100 misurazioni, Bigtable scrive e legge le misurazioni più velocemente se si trovano in una riga piuttosto che in 100 righe.

  • I dati archiviati in questo modo vengono compressi in modo più efficiente rispetto ai dati in tabelle alte e strette.

Gli svantaggi includono i seguenti:

  • I pattern di progettazione dello schema con bucket temporali sono più complicati dei pattern con timestamp singolo e possono richiedere più tempo e più impegno.

Aggiunta di nuove colonne per i nuovi eventi

In questo pattern del bucket di tempo, scrivi una nuova colonna in una riga per ogni evento, memorizzando 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 il timestamp, ma nessun valore.

Utilizzando questo pattern per i dati di esempio del pallone meteorologico, ogni riga contiene tutte le misurazioni relative a una singola metrica, ad esempio pressure, di un singolo pallone meteorologico nel corso di una settimana. Ogni chiave di riga contiene la località, l'ID del fumetto, la metrica che stai registrando nella riga e un numero della settimana. Ogni volta che un fumetto registra i dati di una metrica, aggiungi una nuova colonna alla riga. Il qualificatore di colonna contiene la misurazione con la pressione in Pascal per il 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:

Aggiungere nuove celle per i nuovi eventi

In questo pattern del bucket temporale, quando scrivi un nuovo evento aggiungi nuove celle alle colonne esistenti. Questo pattern consente di sfruttare la capacità di Bigtable di archiviare più celle con timestamp in una determinata riga e colonna. Quando utilizzi questo pattern, è importante specificare le regole di garbage collection.

Utilizzando i dati relativi al pallone meteorologico come esempio, ogni riga contiene tutte le misurazioni di un singolo pallone meteorologico nel corso di una settimana. Il prefisso della chiave di riga è un identificatore della settimana, quindi puoi leggere i dati di un'intera settimana relativa a più fumetti con una singola query. Gli altri segmenti chiave di riga costituiscono la posizione in cui viene attivato il fumetto e il relativo numero ID. La tabella ha una famiglia di colonne, measurements, e questa famiglia di colonne ha una colonna per ogni tipo di misurazione: pressure, temperature, humidity e altitude.

Ogni volta che un fumetto invia le misurazioni, l'applicazione scrive nuovi valori nella riga che contiene i dati della settimana corrente per il fumetto, inserendo celle aggiuntive con timestamp in ogni colonna. Alla fine della settimana, ogni colonna in ogni riga contiene una misurazione per ogni minuto della settimana o 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 caso, dopo tre minuti, le prime due colonne di riga potrebbero avere il seguente aspetto:

Chiave di riga pressione temperatura
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

In questo pattern, creerai una riga per ogni nuovo evento o misurazione invece di aggiungere celle alle colonne nelle righe esistenti. Il suffisso della chiave di riga è il valore del timestamp. Le tabelle che seguono questo pattern tendono a essere alte e strette e ogni colonna di una riga contiene una sola cella.

Serializzazione con timestamp singolo

In questo pattern, memorizzi tutti i dati di una riga in una singola colonna in un formato serializzato come un buffer di protocollo (protobuf). Questo approccio è descritto in maggiore dettaglio nella progettazione dello schema.

Ad esempio, se utilizzi questo pattern per archiviare i dati del pallone meteorologico, la tabella potrebbe essere la seguente 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 i seguenti:

  • Efficienza dello spazio di archiviazione

  • Velocità

Gli svantaggi includono i seguenti:

  • Impossibilità di recuperare solo determinate colonne durante la lettura dei dati

  • La necessità di deserializzare i dati dopo la loro lettura

I casi d'uso per questo pattern includono:

  • Non sai come eseguirai le query sui dati o le tue query potrebbero fluttuare.

  • La necessità di contenere i costi supera di gran lunga la necessità di poter filtrare i dati prima di recuperarli da Bigtable.

  • Ogni evento contiene così tante misurazioni che potresti superare il limite di 100 MB per riga se archivi i dati in più colonne.

Non serializzato con timestamp singolo

Con questo pattern, ogni evento viene memorizzato in una riga separata, anche se stai registrando una sola misurazione. I dati nelle colonne non sono serializzati.

I vantaggi di questo modello includono i seguenti:

  • In genere è più facile da implementare rispetto a un pattern con bucket temporali.

  • Potresti dedicare meno tempo a perfezionare lo schema prima di utilizzarlo.

Gli svantaggi di questo modello spesso superano i vantaggi:

  • Bigtable ha prestazioni meno elevate con questo pattern.

  • I dati archiviati in questo modo non sono compressi in modo efficiente come i dati in colonne più larghe.

  • Anche se il timestamp si trova alla fine della chiave di riga, questo pattern può generare hotspot.

I casi d'uso per questo pattern includono:

  • Vuoi recuperare sempre tutte le colonne, ma solo un intervallo specificato di timestamp, ma hai un motivo per non archiviare i dati in una struttura serializzata.

  • Vuoi archiviare un numero illimitato di eventi.

Utilizzando i dati di esempio del fumetto del meteo, la famiglia di colonne e i qualificatori di colonna sono gli stessi dell'esempio con bucket temporali e nuove celle. Con questo schema, tuttavia, ogni insieme di misurazioni riportate per ogni pallone meteorologico viene scritto in una nuova riga. La seguente tabella mostra cinque righe 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, valuta la possibilità di archiviare i dati in più tabelle, ciascuna con una chiave di riga progettata per una delle query.

In alcuni casi puoi anche combinare pattern. Ad esempio, puoi archiviare i dati in serie in righe che rappresentano i bucket di tempo, a condizione che le righe non diventino troppo grandi.

Passaggi successivi