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 su Progettazione dello schema e presuppone che tu abbia familiarità con i concetti e i suggerimenti descritti in quella pagina.

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

  • Il grafico della memoria utilizzata sul computer
  • Temperatura nel tempo in un report di notizie
  • Prezzi di mercato del mercato azionario in un periodo di tempo

Uno schema valido si traduce in prestazioni e scalabilità eccellenti, mentre uno schema non valido può portare a un sistema con prestazioni scadenti. Tuttavia, non esiste un unico design dello schema che si adatti al meglio 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 elementi 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 archiviando i dati per un'app che registra le misurazioni effettuate dai palloni meteorologici una volta al minuto. Utilizziamo il termine evento per indicare una singola richiesta che scrive una o più celle contemporaneamente. Gli ID località corrispondono alle regioni Google Cloud .

Misurazione Esempio
  1. I timestamp in questa pagina sono formattati come "tYYYY-MM-DD-HHMM" per una maggiore leggibilità. In una tabella di produzione, i timestamp sono solitamente espressi come numero di microsecondi dal 1° gennaio 1970 alle ore 00:00:00 UTC, ad esempio "1616264288050807".
Pressione (pascal) 94587
Temperatura (Celsius) 9,5
Umidità (percentuale) 65
Altitudine (metri) 601
Dati correlati Esempio
ID palloncino 3698
Località asia-southeast1
Timestamp1 t2021-03-05-1204

Bucket di tempo

In un pattern di 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 identificativi.

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 sono più grandi della dimensione massima consigliata per riga di 100 MB, le righe che rappresentano mezz'ora o un minuto sono probabilmente una scelta migliore.

I vantaggi dei pattern di bucket temporali includono:

  • Registrerai un migliore rendimento. Ad esempio, se memorizzi 100 misurazioni, Bigtable scrive e legge queste misurazioni 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 in tabelle alte e strette.

Gli svantaggi includono:

  • I pattern di progettazione dello schema di bucket temporali sono più complessi dei pattern con un singolo timestamp e possono richiedere più tempo e impegno per lo sviluppo.

Aggiunta di nuove colonne per i nuovi eventi

In questo pattern di bucket temporale, 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 per una singola metrica, ad esempio pressure, per un singolo pallone meteorologico, nel corso di una settimana. Ogni chiave di riga contiene la località, l'ID del pallone, la metrica che stai registrando nella riga e un numero di settimana. Ogni volta che un pallone segnala i propri dati per una metrica, aggiungi una nuova colonna alla riga. Il qualificatore di 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:

Aggiunta di nuove celle per i nuovi eventi

In questo pattern di 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 utilizzi questo pattern.

Se il tuo workload ha una frequenza di eventi elevata, potrebbero verificarsi più eventi nello stesso millisecondo, il che può causare la perdita di dati a causa di collisioni di timestamp. Per evitare questo problema quando aggiungi nuove celle per nuovi eventi, puoi configurare la tabella in modo che utilizzi la granularità del timestamp in microsecondi. Questa funzionalità è disponibile solo per le istanze della versione Enterprise Plus.

Utilizzando i dati del pallone meteorologico come esempio, ogni riga contiene tutte le misurazioni per 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ù palloni con una singola query. Gli altri segmenti della chiave di riga sono la località in cui opera il pallone e il numero ID del pallone. La tabella ha una famiglia di colonne, measurements, che a sua volta ha una colonna per ogni tipo di misurazione: pressure, temperature, humidity e altitude.

Ogni volta che un pallone invia le sue misurazioni, l'applicazione scrive nuovi valori nella riga che contiene i dati della settimana corrente per il pallone, 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, ovvero 10.080 celle (se la policy 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#week1 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 un singolo timestamp

In questo pattern, crei una riga per ogni nuovo evento o misurazione anziché 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.

Serializzato con timestamp singolo

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

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

  • Se non utilizzi le funzionalità di query SQL di Bigtable per JSON o buffer di protocollo, non puoi recuperare solo campi specifici quando leggi i dati e devi invece leggere tutti i dati di una determinata cella.

  • La necessità di deserializzare i dati dopo la lettura

I casi d'uso per questo pattern includono:

  • Quasi sempre è necessario recuperare tutte le misurazioni per un determinato evento contemporaneamente.

  • Dai la priorità all'efficienza dello spazio di archiviazione perché recuperi quasi sempre tutte le misurazioni per un determinato evento contemporaneamente. Sebbene sia possibile utilizzare le funzionalità SQL di Bigtable per filtrare i dati lato server, questo pattern è più vantaggioso quando non è necessario filtrare di frequente.

  • 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 propria riga, anche se stai registrando una sola misurazione. I dati nelle colonne non sono serializzati.

I vantaggi di questo pattern includono:

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

  • Potresti dedicare meno tempo alla perfezionamento dello schema prima di utilizzarlo.

Gli svantaggi di questo pattern spesso superano i vantaggi:

  • Bigtable è meno efficiente con questo pattern.

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

  • Anche quando 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 pallone meteorologico, la famiglia di colonne e i qualificatori di colonna sono gli stessi dell'esempio che utilizza i bucket temporali e le nuove celle. In questo pattern, tuttavia, ogni insieme di misurazioni segnalate per ogni pallone meteorologico 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

Ulteriori strategie

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 dati serializzati in righe che rappresentano bucket temporali, purché le righe non diventino troppo grandi.

Passaggi successivi