Modellazione dei dati

Amazon Timestream LiveAnalytics for è progettato per raccogliere, archiviare e analizzare dati di serie temporali da applicazioni e dispositivi che emettono una sequenza di dati con un timestamp. Per prestazioni ottimali, i dati inviati a Timestream LiveAnalytics devono avere caratteristiche temporali e il tempo deve essere un componente essenziale dei dati.

Timestream for LiveAnalytics offre la flessibilità necessaria per modellare i dati in diversi modi per soddisfare i requisiti dell'applicazione. In questa sezione, trattiamo diversi di questi modelli e forniamo linee guida per ottimizzare costi e prestazioni. Acquisite familiarità con i principali argomenti relativi a Timestream per LiveAnalytics concetti quali dimensioni e misure. In questa sezione, scoprirai di più su:

Nel decidere se creare una singola tabella o più tabelle per archiviare i dati, considera quanto segue:

• Quali dati inserire nella stessa tabella rispetto a quando desideri separare i dati su più tabelle e database.

• Come scegliere tra Timestream per record a LiveAnalytics più misure e record a misura singola e i vantaggi della modellazione utilizzando record multimisura, soprattutto quando l'applicazione tiene traccia di più misurazioni contemporaneamente e istantaneamente.

• Quali attributi modellare come dimensioni o come misure.

• Come utilizzare in modo efficace gli attributi del nome della misura per ottimizzare la latenza delle query.

Tabella singola vs. tabelle multiple

Mentre si modellano i dati nell'applicazione, un altro aspetto importante è come modellare i dati in tabelle e database. I database e le tabelle in Timestream for LiveAnalytics sono astrazioni per il controllo degli accessi, la specificazione delle KMS chiavi, i periodi di conservazione, ecc. Timestream consente il partizionamento LiveAnalytics automatico dei dati ed è progettato per scalare le risorse in base al carico e ai requisiti di acquisizione, archiviazione e query delle applicazioni.

Una tabella in Timestream for è LiveAnalytics scalabile fino a petabyte di dati archiviati, decine di gigabyte/sec di scrittura dei dati e le query possono elaborarne centinaia all'ora. TBs Le query in Timestream for LiveAnalytics possono estendersi su più tabelle e database, fornendo join e unioni per fornire un accesso senza interruzioni ai dati su più tabelle e database. Pertanto, la scala dei dati o il volume delle richieste di solito non sono la preoccupazione principale quando si decide come organizzare i dati in Timestream for. LiveAnalytics Di seguito sono riportate alcune considerazioni importanti per decidere quali dati collocare nella stessa tabella anziché in tabelle diverse o tabelle in database diversi.

• Le politiche di conservazione dei dati (conservazione dell'archivio di memoria, conservazione dell'archivio magnetico, ecc.) sono supportate in base alla granularità di una tabella. Pertanto, i dati che richiedono politiche di conservazione diverse devono trovarsi in tabelle diverse.

• AWS KMS le chiavi utilizzate per crittografare i dati sono configurate a livello di database. Pertanto, i diversi requisiti delle chiavi di crittografia implicano che i dati dovranno trovarsi in database diversi.

• Timestream for LiveAnalytics supporta il controllo degli accessi basato sulle risorse con la granularità di tabelle e database. Considera i tuoi requisiti di controllo degli accessi quando decidi quali dati scrivere nella stessa tabella rispetto a tabelle diverse.

• Tieni presente i limiti relativi al numero di dimensioni, ai nomi delle misure e ai nomi degli attributi multimisura quando decidi quali dati archiviare in quale tabella.

• Quando decidi come organizzare i dati, prendi in considerazione il carico di lavoro e i modelli di accesso delle query, poiché la latenza delle query e la facilità di scrittura delle query dipenderanno da ciò.

  • Se si archiviano i dati su cui si eseguono frequentemente query nella stessa tabella, in genere si semplificherà il modo in cui si scrivono le query, in modo da evitare spesso la necessità di scrivere join, unioni o espressioni di tabella comuni. Ciò comporta in genere anche una minore latenza delle query. È possibile utilizzare i predicati sulle dimensioni e sui nomi delle misure per filtrare i dati pertinenti alle query.

    Ad esempio, si consideri un caso in cui si archiviano dati da dispositivi situati in sei continenti. Se le tue query accedono spesso ai dati provenienti da tutti i continenti per ottenere una vista aggregata globale, l'archiviazione dei dati di questi continenti nella stessa tabella semplificherà la scrittura delle query. D'altra parte, se memorizzi dati su tabelle diverse, puoi comunque combinare i dati nella stessa query, tuttavia dovrai scrivere una query per unire i dati di più tabelle.

  • Timestream for LiveAnalytics utilizza il partizionamento e l'indicizzazione adattivi dei dati. Pertanto alle query vengono addebitati solo i dati pertinenti alle tue domande. Ad esempio, se disponi di una tabella che memorizza i dati di un milione di dispositivi in sei continenti, se la tua query contiene predicati del tipo WHERE device_id = 'abcdef' orWHERE continent = 'North America', alle query vengono addebitati solo i dati relativi al dispositivo o al continente.

  • Ove possibile, se si utilizza il nome della misura per separare i dati nella stessa tabella che non vengono emessi contemporaneamente o non vengono interrogati frequentemente, utilizzando i predicati come WHERE measure_name = 'cpu' nella query, non solo si ottengono i vantaggi di misurazione, ma Timestream for LiveAnalytics può anche eliminare efficacemente le partizioni che non hanno il nome della misura utilizzato nel predicato di query. Ciò consente di archiviare i dati correlati con nomi di misure diversi nella stessa tabella senza influire sulla latenza o sui costi delle query ed evita la diffusione dei dati in più tabelle. Il nome della misura viene utilizzato essenzialmente per partizionare i dati ed eliminare le partizioni non pertinenti alla query.

Record multimisura vs. record a misura singola

Timestream for LiveAnalytics consente di scrivere dati con più misure per record (multimisura) o una singola misura per record (misura singola).

Record multimisura

In molti casi d'uso, un dispositivo o un'applicazione monitorata può emettere più metriche o eventi contemporaneamente. In questi casi, puoi memorizzare tutte le metriche emesse nello stesso timestamp nello stesso record multimisura. Cioè, tutte le misure memorizzate nello stesso record multimisura vengono visualizzate come colonne diverse nella stessa riga di dati.

Considerate, ad esempio, che la vostra applicazione emetta metriche come cpu, memory, disk_iops da un dispositivo misurato nello stesso istante. Di seguito è riportato un esempio di tabella di questo tipo in cui più metriche emesse nello stesso istante vengono memorizzate nella stessa riga. Vedrai che due host emettono le metriche una volta al secondo.

Hostname (Nome host)	measure_name	Orario	cpu	Memoria	disk_iops
Host-24 GJU	metriche	01/12/2021 19:00:00	35	54,9	38,2
Host-24 GJU	metriche	01/12/2021 19:00:01	36	58	39
Host-28 GJU	metriche	01/12/2021 19:00:00	15	55	92
Host-28 GJU	metriche	01/12/2021 19:00:01	16	50	40

Record a misura singola

I record a singola misura sono adatti quando i dispositivi emettono metriche diverse in periodi di tempo diversi o si utilizza una logica di elaborazione personalizzata che emette metrics/events at different time periods (for instance, when a device's reading/state modifiche). Poiché ogni misura ha un timestamp unico, le misure possono essere archiviate nei propri record in Timestream for. LiveAnalytics Ad esempio, prendiamo in considerazione un sensore IoT, che monitora la temperatura e l'umidità del suolo, che emette un record solo quando rileva un cambiamento rispetto alla voce precedente riportata. L'esempio seguente fornisce un esempio di tali dati emessi utilizzando record di misure singole.

device_id	measure_name	Orario	measure_value::double	measure_value::bigint
sensor-sea478	temperature	2021-12-01 19:22:32	35	NULL
sensore-sea478	temperature	2021-12-01 18:07:51	36	NULL
sensore-sea478	umidità	2021-12-01 19:05:30	NULL	21
sensore-sea478	umidità	2021-12-01 19:00:01	NULL	23

Confronto tra record a misura singola e multimisura

Timestream for LiveAnalytics offre la flessibilità necessaria per modellare i dati come record a misura singola o multipla a seconda dei requisiti e delle caratteristiche dell'applicazione. Una singola tabella può memorizzare sia record a singola misura che a più misure, se i requisiti dell'applicazione lo richiedono. In generale, quando l'applicazione emette più misurazioni/eventi contemporaneamente, la modellazione dei dati come record multimisura è generalmente consigliata per un accesso efficiente ai dati e un'archiviazione dei dati conveniente.

Ad esempio, se si considera un caso DevOps d'uso che monitora metriche ed eventi da centinaia di migliaia di server, ogni server emette periodicamente 20 metriche e 5 eventi, in cui gli eventi e le metriche vengono emessi nello stesso istante. Tali dati possono essere modellati utilizzando record a singola misura o utilizzando record a più misure (consulta il generatore di dati open source per lo schema risultante). In questo caso d'uso, la modellazione dei dati utilizzando record a più misure rispetto a record a misura singola produce:

• Misurazione dell'ingestione: i record con più misure consentono di ridurre di circa il 40% i byte di ingestione scritti.

• Ingestione in batch: i record su più misure comportano l'invio di batch di dati più grandi, il che implica che i client abbiano bisogno di meno thread e meno thread per elaborare l'ingestione. CPU

• Misurazione dello storage: i record su più misure riducono lo storage di circa 8 volte, con un notevole risparmio di storage sia per la memoria che per l'archiviazione magnetica.

• Latenza delle query: i record con più misure determinano una latenza di query inferiore per la maggior parte dei tipi di query rispetto ai record a misura singola.

• Byte misurati dalle query: per le query che analizzano dati inferiori a 10 MB, i record a misura singola e quelli a più misure sono comparabili. Per le interrogazioni che accedono a una singola misura e scansionano dati di oltre 10 MB, i record a misurazione singola generano in genere una riduzione dei byte misurati. Per le query che fanno riferimento a 3 o più misure, i record con più misure comportano una riduzione dei byte misurati.

• Facilità di esprimere interrogazioni con più misure: quando le query fanno riferimento a più misure, la modellazione dei dati con record multimisura consente di scrivere query più semplici da scrivere.

I fattori precedenti varieranno a seconda del numero di metriche monitorate, delle dimensioni dei dati, ecc. Sebbene l'esempio precedente fornisca alcuni dati concreti, ad esempio, vediamo in molti scenari applicativi e casi d'uso in cui se l'applicazione emette più misure contemporaneamente, l'archiviazione dei dati come record multimisura è più efficace. Inoltre, i record multimisura offrono la flessibilità dei tipi di dati e la memorizzazione di più altri valori come contesto (ad esempio, l'archiviazione di richieste e timestamp aggiuntiviIDs, di cui parleremo più avanti).

Nota che un record multimisura può anche modellare misure sparse come nell'esempio precedente per i record di misura singola: puoi usare measure_name per memorizzare il nome della misura e utilizzare un nome di attributo multimisura generico, come value_double per memorizzare DOUBLE le misure, value_bigint per memorizzare BIGINT le misure, value_timestamp per memorizzare TIMESTAMP valori aggiuntivi, ecc.

Dimensioni e misure

Una tabella in Timestream per ti LiveAnalytics consente di memorizzare dimensioni (attributi identificativi del dispositivo/dati che stai archiviando) e misure (le metriche/valori che stai monitorando), vedi Timestream per i LiveAnalytics concetti per maggiori dettagli. Mentre state modellando la vostra applicazione su Timestream, il modo in cui mappate i dati in dimensioni e misure influisce LiveAnalytics sulla latenza di inserimento e di interrogazione. Di seguito sono riportate le linee guida su come modellare i dati sotto forma di dimensioni e misure da applicare al caso d'uso.

Scelta delle dimensioni

I dati che identificano la fonte che invia i dati delle serie temporali sono una scelta naturale per le dimensioni, che sono attributi che non cambiano nel tempo. Ad esempio, se disponi di un server che emette metriche, gli attributi che identificano il server, come hostname, Region, rack, Availability Zone, sono candidati per le dimensioni. Allo stesso modo, per un dispositivo IoT con più sensori che riportano dati di serie temporali, l'id del dispositivo, l'id del sensore, ecc. sono candidati per le dimensioni.

Se si scrivono dati come record multimisura, le dimensioni e gli attributi multimisura vengono visualizzati come colonne nella tabella quando si esegue DESCRIBE o si esegue un'SELECTistruzione sulla tabella. Pertanto, quando si scrivono le query, è possibile utilizzare liberamente le dimensioni e le misure della stessa query. Tuttavia, quando create il record di scrittura per importare dati, tenete presente quanto segue quando scegliete quali attributi sono specificati come dimensioni e quali sono valori di misura:

• I nomi delle dimensioni, i valori, il nome della misura e il timestamp identificano in modo univoco i dati delle serie temporali. Timestream for LiveAnalytics utilizza questo identificatore univoco per deduplicare automaticamente i dati. Cioè, se Timestream for LiveAnalytics riceve due punti dati con gli stessi valori di nomi di dimensione, valori di dimensione, nome di misura e timestamp, se i valori hanno lo stesso numero di versione, Timestream for deduplica. LiveAnalytics Se la nuova richiesta di scrittura ha una versione inferiore a quella dei dati già esistenti in Timestream for, la richiesta di scrittura viene rifiutata. LiveAnalytics Se la nuova richiesta di scrittura ha una versione superiore, il nuovo valore sovrascrive il vecchio valore. Pertanto, la scelta dei valori delle dimensioni influirà su questo comportamento di deduplicazione.

• I nomi e i valori delle dimensioni non possono essere aggiornati, mentre il valore di misura può esserlo. Pertanto, qualsiasi dato che potrebbe richiedere aggiornamenti viene meglio modellato come valori di misura. Ad esempio, se in fabbrica è presente una macchina il cui colore può cambiare, è possibile modellare il colore come valore di misura, a meno che non si desideri utilizzare il colore anche come attributo identificativo necessario per la deduplicazione. In altre parole, i valori di misura possono essere utilizzati per memorizzare attributi che cambiano solo lentamente nel tempo.

Tieni presente che una tabella in Timestream for LiveAnalytics non limita il numero di combinazioni univoche di nomi e valori delle dimensioni. Ad esempio, puoi avere miliardi di queste combinazioni di valori uniche memorizzate in una tabella. Tuttavia, come vedrete negli esempi seguenti, un'attenta scelta delle dimensioni e delle misure può ottimizzare in modo significativo la latenza delle richieste, in particolare per le query.

Unico IDs nelle dimensioni

Se lo scenario applicativo richiede la memorizzazione di un identificatore univoco per ogni punto dati (ad esempio, un ID di richiesta, un ID di transazione o un ID di correlazione), la modellazione dell'attributo ID come valore di misura comporterà una latenza di query significativamente migliore. Quando si modellano i dati con record multimisura, l'ID viene visualizzato nella stessa riga nel contesto delle altre dimensioni e dei dati delle serie temporali, in modo che le query possano continuare a utilizzarli in modo efficace. Ad esempio, considerando un caso DevOps d'uso in cui ogni punto dati emesso da un server ha un attributo ID di richiesta univoco, la modellazione dell'ID della richiesta come valore di misura comporta una latenza di query fino a 4 volte inferiore su diversi tipi di query, anziché modellare l'ID di richiesta univoco come dimensione.

È possibile utilizzare l'analogia simile per attributi che non sono completamente unici per ogni punto dati, ma hanno centinaia di migliaia o milioni di valori univoci. È possibile modellare questi attributi sia come dimensioni che come valori di misura. È consigliabile modellarlo come dimensione se i valori sono necessari per la deduplicazione sul percorso di scrittura, come illustrato in precedenza, oppure lo si utilizza spesso come predicato (ad esempio, nella WHERE clausola con un predicato di uguaglianza su un valore di quell'attributo, ad esempio device_id = ‘abcde’ quando l'applicazione monitora milioni di dispositivi) nelle query.

Ampia gamma di tipi di dati con record multimisura

I record multimisura offrono la flessibilità necessaria per modellare efficacemente i dati. I dati archiviati in un record di più misure vengono visualizzati come colonne nella tabella in modo simile alle dimensioni, garantendo così la stessa facilità di ricerca delle dimensioni e dei valori di misura. Hai visto alcuni di questi modelli negli esempi discussi in precedenza. Di seguito troverai modelli aggiuntivi per utilizzare in modo efficace i record multimisura per soddisfare i casi d'uso dell'applicazione.

I record multimisura supportano gli attributi dei tipi di datiDOUBLE,BIGINT, VARCHARBOOLEAN, e. TIMESTAMP Pertanto, si adattano naturalmente a diversi tipi di attributi:

• Informazioni sulla posizione: ad esempio, se si desidera tracciare la posizione (espressa come latitudine e longitudine), modellarla come attributo multimisura comporterà una minore latenza di interrogazione rispetto alla memorizzazione delle stesse come VARCHAR dimensioni, specialmente quando si hanno predicati sulla latitudine e sulle longitudini.

• Più timestamp in un record: se lo scenario dell'applicazione richiede di tenere traccia di più timestamp per un record di serie temporali, è possibile modellarli come attributi aggiuntivi nel record multimisura. Questo modello può essere utilizzato per archiviare dati con timestamp futuri o passati. Tieni presente che ogni record utilizzerà comunque il timestamp nella colonna dell'ora per partizionare, indicizzare e identificare in modo univoco un record.

In particolare, se nella query sono presenti dati numerici o timestamp su cui sono presenti predicati, la modellazione di tali attributi come attributi multimisura anziché come dimensioni comporterà una minore latenza delle query. Questo perché quando si modellano tali dati utilizzando i ricchi tipi di dati supportati nei record multimisura, è possibile esprimere i predicati utilizzando tipi di dati nativi anziché trasferire valori da VARCHAR un altro tipo di dati se tali dati sono stati modellati come dimensioni.

Utilizzo del nome della misura con record multimisura

Le tabelle in Timestream LiveAnalytics supportano un attributo speciale (o colonna) chiamato nome della misura. Specificate un valore per questo attributo per ogni record per cui scrivete su Timestream. LiveAnalytics Per i record a singola misura, è naturale utilizzare il nome della metrica (ad esempio cpu, memoria per le metriche del server o temperatura, pressione per le metriche dei sensori). Quando si utilizzano record multimisura, poiché gli attributi di un record multimisura sono denominati (e questi nomi diventano nomi di colonne nella tabella), cpu, memoria o temperatura, la pressione può diventare nomi di attributi con più misure. Quindi una domanda naturale è come utilizzare efficacemente il nome della misura.

Timestream for LiveAnalytics utilizza i valori nell'attributo del nome della misura per partizionare e indicizzare i dati. Pertanto, se una tabella ha più nomi di misure diversi e se le query utilizzano tali valori come predicati di query, Timestream for LiveAnalytics può utilizzare il partizionamento e l'indicizzazione personalizzati per eliminare i dati non pertinenti alle query. Ad esempio, se la tabella contiene nomi di misure di CPU e memoria e la query ha un predicatoWHERE measure_name = 'cpu', Timestream for LiveAnalytics può eliminare efficacemente i dati per i nomi di misure non pertinenti alla query, ad esempio le righe con memoria dei nomi di misura in questo esempio. Questa eliminazione si applica anche quando si utilizzano nomi di misure con record di più misure. È possibile utilizzare efficacemente l'attributo measure name come attributo di partizionamento per una tabella. Il nome della misura insieme ai nomi e ai valori delle dimensioni e l'ora vengono utilizzati per partizionare i dati in un flusso temporale per tabella. LiveAnalytics Tieni presente i limiti al numero di nomi di misura univoci consentiti in un Timestream for table. LiveAnalytics Si noti inoltre che il nome di una misura è associato anche a un tipo di dati del valore di misura, ad esempio, un singolo nome di misura può essere associato a un solo tipo di valore di misura. Questo tipo può essere uno tra DOUBLE BIGINTBOOLEAN,VARCHAR, eMULTI. I record a più misure memorizzati con un nome di misura avranno il seguente MULTI tipo di dati. Poiché un singolo record multimisura può memorizzare più metriche con tipi di dati diversi (DOUBLE,, BIGINTVARCHAR, eTIMESTAMP)BOOLEAN, è possibile associare dati di tipi diversi in un record con più misure.

Le sezioni seguenti descrivono alcuni esempi diversi di come l'attributo measure name può essere efficacemente utilizzato per raggruppare diversi tipi di dati nella stessa tabella.

Sensori IoT che segnalano qualità e valore

Immagina di avere un'applicazione che monitora i dati provenienti dai sensori IoT. Ogni sensore rileva diverse misure, come temperatura, pressione. Oltre ai valori effettivi, i sensori segnalano anche la qualità delle misurazioni, che è una misura dell'accuratezza della lettura e un'unità di misura. Poiché qualità, unità e valore vengono emessi insieme, possono essere modellati come record multimisura, come mostrato nei dati di esempio riportati di seguito, in cui device_id è una dimensione, qualità, valore e unità sono attributi multimisura:

device_id	measure_name	Orario	Qualità	Valore	Unità
sensor-sea478	temperature	2021-12-01 19:22:32	92	35	c
sensor-sea478	temperature	2021-12-01 18:07:51	93	34	c
sensor-sea478	pressure	2021-12-01 19:05:30	98	31	psi
sensor-sea478	pressure	2021-12-01 19:00:01	24	132	psi

Questo approccio consente di combinare i vantaggi dei record multimisura con il partizionamento e l'eliminazione dei dati utilizzando i valori di measure name. Se le query fanno riferimento a una singola misura, ad esempio la temperatura, è possibile includere un predicato del nome della misura nella query. Di seguito è riportato un esempio di tale interrogazione, che proietta anche l'unità per le misurazioni la cui qualità è superiore a 90.

SELECT device_id, time, value AS temperature, unit
FROM db.table
WHERE time > ago(1h)
    AND measure_name = 'temperature'
    AND quality > 90

L'utilizzo del predicato measure_name sulla query consente a Timestream di eliminare efficacemente partizioni e dati non pertinenti LiveAnalytics alla query, migliorando così la latenza della query.

È anche possibile archiviare tutte le metriche nello stesso record multimisura se tutte le metriche vengono emesse con lo stesso timestamp e/o più metriche vengono interrogate insieme nella stessa query. Ad esempio, puoi costruire un record multimisura con gli attributi temperature_quality, temperature_value, temperature_unit, pressure_quality, pressure_value, pressure_unit, ecc. Molti dei punti discussi in precedenza sulla modellazione dei dati utilizzando record a singola misura anziché a più misure si applicano alla decisione su come modellare i dati. Considerate i modelli di accesso alle query e il modo in cui i dati vengono generati per scegliere un modello che ottimizzi i costi, l'inserimento e la latenza delle query e la facilità di scrittura delle query.

Diversi tipi di metriche nella stessa tabella

Un altro caso d'uso in cui è possibile combinare record di più misure con i valori dei nomi delle misure consiste nel modellare diversi tipi di dati emessi indipendentemente dallo stesso dispositivo. Considerate il caso d'uso del DevOps monitoraggio: i server emettono due tipi di dati: metriche emesse regolarmente ed eventi irregolari. Un esempio di questo approccio è lo schema discusso nel generatore di dati che modella un caso d'uso. DevOps In questo caso, è possibile memorizzare i diversi tipi di dati emessi dallo stesso server nella stessa tabella utilizzando nomi di misure diversi. Ad esempio, tutte le metriche emesse nello stesso istante vengono archiviate con le metriche dei nomi delle misure. Tutti gli eventi emessi in un istante temporale diverso dalle metriche vengono archiviati con gli eventi relativi ai nomi delle misure. Lo schema di misura per la tabella (ad esempio, l'output della SHOW MEASURES query) è:

measure_name	data_type	Dimensioni
events	multi	[{"data_type» :"varchar», "dimension_name» :"availability_zone "}, {" data_type» :"varchar», "dimension_name» :"microservice_name "}, {" data_type» :"varchar», "dimension_name» :"nome_istanza "}, {" tipo_dati» :"varchar» :"varchar», "dimension_name» :"process_name "}, {" data_type» :"varchar», "dimension_name» :"jdk_version "}, {" data_type» :"varchar», "dimension_name» :"cell "}, {" data_type» :"varchar», "dimension_name» :"region "}, {" tipo_dati» :"varchar», "dimension_name» :"region "}, {" tipo_dati» :"varchar», "dimension_name» :"region "}, {" tipo_dati» :"varchar»» :"varchar», "nome_dimensione» :"silo "}]
metriche	multi	[{"data_type» :"varchar», "dimension_name» :"availability_zone "}, {" data_type» :"varchar», "dimension_name» :"microservice_name "}, {" data_type» :"varchar», "dimension_name» :"nome_istanza "}, {" tipo_dati» :"varchar» :"varchar», "dimension_name» :"os_version "}, {" data_type» :"varchar», "dimension_name» :"cell "}, {" data_type» :"varchar», "dimension_name» :"region "}, {" data_type» :"varchar», "dimension_name» :"silo "}, {" tipo_dati» :"varchar» :"dimension_name» :"silo "}, {" tipo_dati» :"varchar» :"dimension_name» :"silo "}, {" tipo_dati» :"varchar» :"dimension_name» :"silo "}, {" tipo_dati» :"varchar» :"dimension_name» :"silo "} «varchar», "nome_dimensione» :"tipo_istanza "}]

In questo caso, puoi vedere che gli eventi e le metriche hanno anche diversi set di dimensioni, dove gli eventi hanno dimensioni diverse jdk_version e process_name mentre le metriche hanno dimensioni instance_type e os_version.

L'utilizzo di nomi di misure diversi consente di scrivere query con predicati in modo da ottenere solo le metriche. WHERE measure_name = 'metrics' Inoltre, avere tutti i dati emessi dalla stessa istanza nella stessa tabella implica che puoi anche scrivere una query più semplice con il predicato instance_name per ottenere tutti i dati per quell'istanza. Ad esempio, un predicato del modulo WHERE instance_name = ‘instance-1234’ senza un predicato measure_name restituirà tutti i dati per un'istanza specifica del server.

Consigli per il partizionamento di record multimisura

Importante

Questa sezione è obsoleta!

Queste raccomandazioni non sono aggiornate. Il partizionamento è ora meglio controllato utilizzando chiavi di partizione definite dal cliente.

Abbiamo visto che nell'ecosistema delle serie temporali c'è un numero crescente di carichi di lavoro che richiedono l'acquisizione e l'archiviazione di enormi quantità di dati e allo stesso tempo richiedono risposte alle query a bassa latenza quando si accede ai dati tramite un set di valori dimensionali ad alta cardinalità.

A causa di tali caratteristiche, i consigli contenuti in questa sezione saranno utili per i carichi di lavoro dei clienti che presentano le seguenti caratteristiche.

• Ha adottato o desidera adottare record multimisura.

• Aspettatevi di ricevere nel sistema un volume elevato di dati che verranno archiviati per lunghi periodi.

• Richiedono tempi di risposta a bassa latenza per i loro modelli di accesso (interrogazione) principali.

• Sappi che i modelli di interrogazione più importanti implicano una condizione di filtraggio di qualche tipo nel predicato. Questa condizione di filtraggio si basa su una dimensione di cardinalità elevata. Ad esempio, considera eventi o aggregazioni per, ServerID UserId DeviceId, host-name e così via.

In questi casi un unico nome per tutte le misure multimisura non sarà di aiuto, poiché il nostro motore utilizza nomi con più misure per partizionare i dati e avere un unico valore limita il vantaggio di partizione che si ottiene. Il partizionamento di questi record si basa principalmente su due dimensioni. Supponiamo che il tempo sia sull'asse x e su un hash di nomi di dimensione e quindi sull'measure_nameasse y. measure_nameIn questi casi funziona quasi come una chiave di partizionamento.

La nostra raccomandazione è la seguente.

• Quando modellate i dati per casi d'uso come quello che abbiamo menzionato, utilizzate un modello measure_name che sia una derivazione diretta del modello di accesso alle query principale. Per esempio:

  • Il tuo caso d'uso richiede il monitoraggio delle prestazioni delle applicazioni e della QoE dal punto di vista dell'utente finale. Potrebbe trattarsi anche del tracciamento delle misurazioni per un singolo server o dispositivo IoT.

  • Se stai eseguendo interrogazioni e filtrando UserId in base a, al momento dell'inserimento devi trovare il modo migliore per associarti a. measure_name UserId

  • Poiché una tabella multimisura può contenere solo 8192 nomi di misure diversi, qualunque formula venga adottata non dovrebbe generare più di 8192 valori diversi.

• Un approccio che abbiamo applicato con successo per i valori di stringa consiste nell'applicare un algoritmo di hashing al valore della stringa. Quindi esegui l'operazione del modulo con il valore assoluto del risultato dell'hash e 8192.

  measure_name = getMeasureName(UserId)
  int getMeasureName(value) {
      hash_value =  abs(hash(value))
      return hash_value % 8192
  }

• Abbiamo anche aggiunto abs() di rimuovere il segno, eliminando la possibilità che i valori vadano da -8192 a 8192. Questa operazione deve essere eseguita prima dell'operazione del modulo.

• Utilizzando questo metodo, le query possono essere eseguite in una frazione del tempo necessario per l'esecuzione su un modello di dati non partizionato.

• Quando interrogate i dati, assicuratevi di includere una condizione di filtro nel predicato che utilizzi il nuovo valore derivato di measure_name. Per esempio:

  • SELECT * FROM your_database.your_table 
    WHERE host_name = 'Host-1235' time BETWEEN '2022-09-01' 
        AND '2022-09-18' 
        AND measure_name = (SELECT cast(abs(from_big_endian_64(xxhash64(CAST('HOST-1235' AS varbinary))))%8192 AS varchar))

  • Ciò ridurrà al minimo il numero totale di partizioni scansionate per ottenere dati che si tradurranno in query più rapide nel tempo.

Tieni presente che se desideri ottenere i vantaggi di questo schema di partizione, l'hash deve essere calcolato sul lato client e passato a Timestream LiveAnalytics come valore statico al motore di query. L'esempio precedente fornisce un modo per verificare che l'hash generato possa essere risolto dal motore quando necessario.

time	host_name	posizione	tipo_server	cpu_usage	memoria_disponibile	cpu_temp
2022-09-07 21:48:44 .000000000	ospitare-1235	us-east1	5,8 xl	55	16,2	78
R2022-09-07 21:48:44 .000000000	host-3587	Stati Uniti-West1	5,8 xl	62	18,1	81
2022-09-07 21:48:45000 000000	host-258743	eu-central	5,8 xl	88	9.4	91
2022-09-07 21:48:45 .000000000	host-35654	Stati Uniti - East2	5,8 xl	29	24	54
R2022-09-07 21:48:45 .000000000	ospite-254	Stati Uniti-West1	5,8 xl	44	32	48

Per generare il codice associato measure_name seguendo la nostra raccomandazione, esistono due percorsi che dipendono dal modello di ingestione.

1. Per l'ingestione in batch di dati storici: puoi aggiungere la trasformazione al tuo codice di scrittura se intendi utilizzare il tuo codice per il processo in batch.

   Basandosi sull'esempio precedente.

           List<String> hosts = new ArrayList<>();
   
           hosts.add("host-1235");
           hosts.add("host-3587");
           hosts.add("host-258743");
           hosts.add("host-35654");
           hosts.add("host-254");
   
           for (String h: hosts){
               ByteBuffer buf2 = ByteBuffer.wrap(h.getBytes());
               partition = abs(hasher.hash(buf2, 0L)) % 8192;
               System.out.println(h + " - " + partition);
   
           }

   Output

   host-1235 - 6445
   host-3587 - 6399
   host-258743 - 640
   host-35654 - 2093
   host-254 - 7051
   

   Set di dati risultante

   time	host_name	posizione	measure_name	tipo_server	cpu_usage	memoria_disponibile	cpu_temp
   2022-09-07 21:48:44 .000000000	ospitare-1235	us-east1	6445	5,8 xl	55	16,2	78
   R2022-09-07 21:48:44 .000000000	host-3587	Stati Uniti-West1	6399	5,8 xl	62	18,1	81
   2022-09-07 21:48:45000 000000	host-258743	eu-central	640	5,8 xl	88	9.4	91
   2022-09-07 21:48:45 .000000000	host-35654	Stati Uniti - East2	2093	5,8 xl	29	24	54
   R2022-09-07 21:48:45 .000000000	ospite-254	Stati Uniti-West1	7051	5,8 xl	44	32	48

2. Per l'ingestione in tempo reale: è necessario generare i dati in measure_name volo man mano che arrivano i dati.

In entrambi i casi, ti consigliamo di testare l'algoritmo di generazione dell'hash su entrambe le estremità (ingestione e interrogazione) per assicurarti di ottenere gli stessi risultati.

Di seguito sono riportati alcuni esempi di codice su cui generare il valore hash. host_name

Esempio Python

>>> import xxhash
>>> from bitstring import BitArray
>>> b=xxhash.xxh64('HOST-ID-1235').digest()
>>> BitArray(b).int % 8192
### 3195

Esempio Go

package main

import (
    "bytes"
    "fmt"
    "github.com/cespare/xxhash"
)

func main() {
    buf := bytes.NewBufferString("HOST-ID-1235")
    x := xxhash.New()
    x.Write(buf.Bytes())
    // convert unsigned integer to signed integer before taking mod
    fmt.Printf("%f\n", abs(int64(x.Sum64())) % 8192)
}

func abs(x int64) int64 {
    if (x < 0) {
        return -x
    }
    return x
}

Esempio Java

import java.nio.ByteBuffer;

import net.jpountz.xxhash.XXHash64;

public class test {
    public static void main(String[] args) {
        XXHash64 hasher = net.jpountz.xxhash.XXHashFactory.fastestInstance().hash64();

        String host = "HOST-ID-1235";
        ByteBuffer buf = ByteBuffer.wrap(host.getBytes());

        Long result = Math.abs(hasher.hash(buf, 0L));
        Long partition = result % 8192;

        System.out.println(result);
        System.out.println(partition);
    }
}

Esempio dipendenza in Maven

        <dependency>
            <groupId>net.jpountz.lz4</groupId>
            <artifactId>lz4</artifactId>
            <version>1.3.0</version>
        </dependency>