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 suggerimenti descritti in questa pagina.

Una serie temporale è una raccolta di dati costituita da misurazioni e dai tempi in cui le misurazioni vengono registrate. Ecco alcuni esempi di serie temporali:

  • 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 porta a prestazioni e scalabilità eccellenti, mentre uno schema errato può portare a prestazioni del sistema scarse. Tuttavia, nessun singolo schema offre la soluzione più adatta a tutti i casi d'uso.

I pattern descritti in questa pagina forniscono un punto di partenza. Il tuo 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 vengano memorizzati i dati per un'app che registra le misurazioni effettuate dai palloncini meteorologici una volta al minuto. Usiamo evento 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 garantire la leggibilità da parte di persone fisiche. In una tabella di produzione, i timestamp in genere sono espressi come numero di microsecondi dal 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

Bucket di tempo

In un pattern a 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, ad esempio week49, per il periodo di tempo registrato nella riga, insieme ad altri dati di identificazione.

La dimensione del bucket che utilizzi, ad esempio minuto, ora o giorno, dipende 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 hanno dimensioni maggiori rispetto alla dimensione massima consigliata per riga di 100 MB, allora le righe che rappresentano 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 archivi 100 misurazioni, Bigtable scrive e legge queste misurazioni più velocemente se sono in una sola riga o se sono in 100 righe.

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

Gli svantaggi includono quanto segue:

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

Aggiungere nuove colonne per nuovi eventi

In questo pattern a bucket temporale, scrivi una nuova colonna in una riga per ogni evento, memorizzando i dati nel qualificatore di colonna anziché come un 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 relativi ai palloncini meteorologici, ogni riga contiene tutte le misurazioni relative a una singola metrica, ad esempio pressure, per un singolo palloncino meteorologico, nel corso di una settimana. Ogni chiave di riga contiene la posizione, l'ID fumetto, la metrica registrata nella riga e il numero della settimana. Ogni volta che un fumetto riporta i dati relativi a una metrica, aggiungi una nuova colonna alla riga. Il qualificatore di colonna contiene la misurazione, ovvero 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 nuovi eventi

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

Utilizzando i dati relativi ai palloni meteorologici 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 per più fumetti con una singola query. Gli altri segmenti chiave di riga sono la posizione in cui funziona il fumetto e il numero ID del palloncino. 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, scrivendo altre celle con timestamp in ogni colonna. Alla fine della settimana, ogni colonna di ogni riga presenta 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 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é aggiungere celle alle colonne delle righe esistenti. Il suffisso della chiave di riga è il valore del timestamp. Le tabelle che seguono questo schema tendono ad essere alte e strette e ogni colonna in una riga contiene una sola cella.

Timestamp singolo serializzato

Con questo pattern, archivi tutti i dati per una riga in una singola colonna in un formato serializzato come un buffer di protocollo (protobuf). Questo approccio è descritto in modo più dettagliato nella progettazione dello schema.

Ad esempio, se utilizzi questo pattern per archiviare i dati dei palloncini meteo, la tabella 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 le query sui dati, altrimenti le query potrebbero fluttuare.

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

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

Timestamp singolo non serializzato

Con questo pattern, ogni evento viene archiviato in una riga separata, anche se registri 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 utilizzarlo.

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 quelli in colonne più larghe.

  • Anche quando il timestamp si trova alla fine della chiave di riga, questo pattern può causare 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 relativi ai fumetti di 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 serie di misurazioni segnalate per ogni palloncino meteo viene scritto in una nuova riga. La tabella seguente 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 i pattern. Ad esempio, puoi archiviare i dati in serie in righe che rappresentano bucket temporali, purché non lasci che le righe diventino troppo grandi.

Passaggi successivi