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 un notiziario
  • Prezzi della borsa in un determinato periodo di tempo

Uno schema valido offre prestazioni e scalabilità eccellenti, mentre uno schema errato può portare a un sistema con prestazioni scadenti. 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 set di dati unico e le query che prevedi di utilizzare sono gli aspetti più importanti da prendere 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 tu stia archiviando i dati di un'app che registra le misurazioni eseguite dai palloni meteorologici ogni minuto. Con evento intendiamo una singola richiesta che scrive una o più celle contemporaneamente. Gli ID posizione corrispondono alle regioni Google Cloud.

Misurazione Esempio
  1. I timestamp in questa pagina sono nel formato "tAAAA-MM-GG-HHMM" per leggibilità umana. In una tabella di produzione, i timestamp di solito sono espresso come il numero di microsecondi 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

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 diverso dal 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 dimensioni 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, 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 archivi 100 misurazioni, Bigtable le scrive e le legge più velocemente se si trovano in una riga rispetto a 100 righe.

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

Gli svantaggi includono:

  • Gli schemi di progettazione degli intervalli di tempo sono più complicati rispetto ai pattern con un singolo timestamp e possono richiedere più tempo e impegno per essere sviluppati.

Aggiunta di nuove colonne per i nuovi eventi

In questo pattern di bucket di tempo, scrivi una nuova colonna in una riga per ogni evento, memorizzando i dati nel qualificatore della 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 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 un callout riporta i dati per una metrica, aggiungi una nuova colonna alla riga. Il qualificatore della colonna contiene la misurazione, 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#pressure#week1 " (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 del bucket di tempo, 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 di una determinata riga e colonna. È importante specificare le regole di raccolta dei rifiuti quando utilizzi questo pattern.

Utilizzando i dati dei palloni meteo come esempio, ogni riga contiene tutte le misurazioni per una singola mongolfiera 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ù palloncini con una singola query. Gli altri segmenti della chiave di riga sono la posizione in cui opera il pallone e il numero ID del pallone. La tabella ha una famiglia di colonne, measurements, che contiene 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 essere in grado di misurare le variazioni delle 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 valore del timestamp. Le tabelle che seguono questo schema tendono a essere alte e strette e ogni colonna di una riga contiene solo una cella.

Serializzato con un solo timestamp

In questo pattern, tutti i dati di una riga vengono archiviati in una singola colonna 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 archiviare i dati dei palloni meteorologici, 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 pattern includono:

  • 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 la lettura

I casi d'uso per questo pattern includono:

  • Non hai la certezza di come eseguirai query sui dati, altrimenti le query potrebbero oscillare.

  • 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 memorizzi i dati in più colonne.

Timestamp singolo non serializzato

In questo pattern, memorizzi ogni evento nella sua riga, anche se registri solo una misurazione. I dati nelle colonne non sono serializzati.

I vantaggi di questo modello includono quanto segue:

  • In genere è più facile da implementare rispetto a un pattern di bucket di tempo.

  • 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 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 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 insieme di misurazioni registrate per ogni pallone meteorologico viene 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 dei 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