

Per funzionalità simili a Amazon Timestream for, prendi in considerazione Amazon Timestream LiveAnalytics per InfluxDB. Offre un'acquisizione semplificata dei dati e tempi di risposta alle query di una sola cifra di millisecondi per analisi in tempo reale. [Scopri](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html) di più qui.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Utilizzo di informazioni dettagliate sulle query per ottimizzare le query in Amazon Timestream
<a name="using-query-insights"></a>

Query Insights è una funzionalità di ottimizzazione delle prestazioni che consente di ottimizzare le query, migliorarne le prestazioni e ridurre i costi. Con Query Insights, puoi valutare l'efficienza di eliminazione delle tue query basata su chiavi di partizione temporali, temporali e spaziali. Utilizzando le informazioni sulle query, è inoltre possibile identificare le aree di miglioramento per migliorare le prestazioni delle query. Inoltre, con Query Insights, è possibile valutare l'efficacia con cui le query utilizzano l'indicizzazione basata sul tempo e sulla chiave di partizione per ottimizzare il recupero dei dati. Per ottimizzare le prestazioni delle query, è essenziale ottimizzare i parametri temporali e spaziali che regolano l'esecuzione delle query.

**Topics**
+ [Vantaggi degli approfondimenti sulle query](#query-insights-benefits)
+ [Ottimizzazione dell'accesso ai dati in Amazon Timestream](query-insights-optimize-data-access-pattern.md)
+ [Attivazione di informazioni dettagliate sulle query in Amazon Timestream](enable-query-insights.md)
+ [Ottimizzazione delle query utilizzando la risposta a Query Insights](optimize-query-using-query-insights.md)

## Vantaggi degli approfondimenti sulle query
<a name="query-insights-benefits"></a>

Di seguito sono riportati i principali vantaggi dell'utilizzo di Query Insights: 
+ **Identificazione delle query inefficienti: Query** Insights fornisce informazioni sull'eliminazione, basata sul tempo e sugli attributi, delle tabelle a cui accede la query. Queste informazioni consentono di identificare le tabelle a cui si accede in modo non ottimale.
+ **Ottimizzazione del modello di dati e del partizionamento**: è possibile utilizzare le informazioni di Query Insights per accedere e perfezionare il modello di dati e la strategia di partizionamento.
+ **Ottimizzazione delle query: Query** Insights evidenzia le opportunità di utilizzare gli indici in modo più efficace.

# Ottimizzazione dell'accesso ai dati in Amazon Timestream
<a name="query-insights-optimize-data-access-pattern"></a>

Puoi ottimizzare i modelli di accesso ai dati in Amazon Timestream utilizzando lo schema di partizionamento Timestream o le tecniche di organizzazione dei dati.

**Topics**
+ [Schema di partizionamento Timestream](#query-insights-optimize-data-access-partitioning-scheme)
+ [Organizzazione dei dati](#query-insights-optimize-data-access-data-org)

## Schema di partizionamento Timestream
<a name="query-insights-optimize-data-access-partitioning-scheme"></a>

Amazon Timestream utilizza uno schema di partizionamento altamente scalabile in cui ogni tabella Timestream può avere centinaia, migliaia o persino milioni di partizioni indipendenti. Un servizio di tracciamento e indicizzazione delle partizioni ad alta disponibilità gestisce il partizionamento, minimizzando l'impatto degli errori e rendendo il sistema più resiliente.

![\[Schema di partizionamento Timestream\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png)


## Organizzazione dei dati
<a name="query-insights-optimize-data-access-data-org"></a>

Timestream memorizza ogni punto dati che acquisisce in una singola partizione. Quando si inseriscono i dati in una tabella Timestream, Timestream crea automaticamente partizioni in base ai timestamp, alla chiave di partizione e ad altri attributi di contesto presenti nei dati. Oltre a partizionare i dati nel tempo (partizionamento temporale), Timestream partiziona anche i dati in base alla chiave di partizionamento selezionata e ad altre dimensioni (partizionamento spaziale). Questo approccio è progettato per distribuire il traffico di scrittura e consentire un'efficace eliminazione dei dati per le query.

La funzionalità di analisi delle query fornisce informazioni preziose sull'efficienza di eliminazione delle query, che include la copertura spaziale delle query e la copertura temporale delle query.

**Topics**
+ [QuerySpatialCoverage](#query-insights-data-org-query-spatial-cvg)
+ [QueryTemporalCoverage](#query-insights-data-org-query-temporal-cvg)

### QuerySpatialCoverage
<a name="query-insights-data-org-query-spatial-cvg"></a>

La [QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)metrica fornisce informazioni sulla copertura spaziale della query eseguita e sulla tabella con la riduzione spaziale più inefficiente. Queste informazioni possono aiutarti a identificare le aree di miglioramento nella strategia di partizionamento per migliorare la potatura spaziale. Il valore della `QuerySpatialCoverage` metrica è compreso tra 0 e 1. Più basso è il valore della metrica, più ottimale è l'eliminazione delle query sull'asse spaziale. Ad esempio, un valore di 0,1 indica che la query analizza il 10% dell'asse spaziale. Il valore 1 indica che l'interrogazione analizza il 100% dell'asse spaziale.

**Example Utilizzo di Query Insights per analizzare la copertura spaziale di un'interrogazione**  
Supponiamo che tu abbia un database Timestream che memorizza i dati meteorologici. Supponiamo che la temperatura venga registrata ogni ora dalle stazioni meteorologiche situate in diversi stati degli Stati Uniti d'America. Immagina di scegliere `State` come [chiave di partizionamento definita dal cliente (CDPK) per partizionare](customer-defined-partition-keys.md) i dati per stato.  
Supponiamo di eseguire un'interrogazione per recuperare la temperatura media di tutte le stazioni meteorologiche della California tra le 14:00 e le 16:00 di un giorno specifico. L'esempio seguente mostra la query per questo scenario.  

```
SELECT AVG(temperature) 
FROM "weather_data"."hourly_weather"
WHERE time >= '2024-10-01 14:00:00' AND time < '2024-10-01 16:00:00' 
  AND state = 'CA';
```
Utilizzando la funzionalità Query Insights, è possibile analizzare la copertura spaziale dell'interrogazione. Immagina che la `QuerySpatialCoverage` metrica restituisca un valore di 0,02. Ciò significa che la query ha scansionato solo il 2% dell'asse spaziale, il che è efficiente. In questo caso, l'interrogazione è stata in grado di ridurre efficacemente l'intervallo spaziale, recuperando solo i dati dalla California e ignorando i dati provenienti da altri stati.  
Al contrario, se la `QuerySpatialCoverage` metrica restituisse un valore di 0,8, indicherebbe che la query ha scansionato l'80% dell'asse spaziale, il che è meno efficiente. Ciò potrebbe suggerire che la strategia di partizionamento debba essere perfezionata per migliorare la potatura spaziale. Ad esempio, è possibile selezionare la chiave di partizione come città o regione anziché come stato. Analizzando la `QuerySpatialCoverage` metrica, è possibile identificare le opportunità per ottimizzare la strategia di partizionamento e migliorare le prestazioni delle query.

L'immagine seguente mostra una potatura spaziale scadente.

![\[Risultato fornito dalla QuerySpatialCoverage metrica che mostra una potatura spaziale scadente.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png)


Per migliorare l'efficienza della potatura spaziale, puoi eseguire una o entrambe le seguenti operazioni:
+ Aggiungi `measure_name` la chiave di partizionamento predefinita o utilizza i predicati CDPK nella tua query.
+ Se hai già aggiunto gli attributi menzionati nel punto precedente, rimuovi le funzioni relative a questi attributi o clausole, ad esempio. `LIKE`

### QueryTemporalCoverage
<a name="query-insights-data-org-query-temporal-cvg"></a>

La `QueryTemporalCoverage` metrica fornisce informazioni sull'intervallo temporale analizzato dalla query eseguita, inclusa la tabella con l'intervallo di tempo più ampio scansionato. Il valore della `QueryTemporalCoverage` metrica è l'intervallo di tempo rappresentato in nanosecondi. Più basso è il valore di questa metrica, più ottimale è l'eliminazione delle query sull'intervallo temporale. Ad esempio, una query che analizza i dati degli ultimi minuti è più efficiente di una query che analizza l'intero intervallo di tempo della tabella.

**Example**  
Supponiamo di avere un database Timestream che memorizza i dati dei sensori IoT, con misurazioni effettuate ogni minuto dai dispositivi situati in uno stabilimento di produzione. Supponiamo di aver partizionato i dati per. `device_ID`  
Supponiamo di eseguire una query per recuperare la lettura media del sensore per un dispositivo specifico negli ultimi 30 minuti. L'esempio seguente mostra l'interrogazione per questo scenario.  

```
SELECT AVG(sensor_reading) 
FROM "sensor_data"."factory_1"
WHERE device_id = 'DEV_123' 
  AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW();
```
Utilizzando la funzionalità Query Insights, è possibile analizzare l'intervallo temporale analizzato dalla query. Immagina che la `QueryTemporalCoverage` metrica restituisca un valore di 1800000000000 nanosecondi (30 minuti). Ciò significa che la query ha analizzato solo i dati degli ultimi 30 minuti, ovvero un intervallo temporale relativamente ristretto. Questo è un buon segno perché indica che la query è stata in grado di ridurre efficacemente il partizionamento temporale e ha recuperato solo i dati richiesti.  
Al contrario, se la `QueryTemporalCoverage` metrica ha restituito un valore di 1 anno in nanosecondi, indica che la query ha analizzato un intervallo di tempo di un anno nella tabella, il che è meno efficiente. Ciò potrebbe suggerire che la query non è ottimizzata per l'eliminazione temporale e che è possibile migliorarla aggiungendo filtri temporali.

L'immagine seguente mostra una scarsa potatura temporale.

![\[Risultato fornito dalla QueryTemporalCoverage metrica che mostra una potatura temporale scadente.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png)


Per migliorare la potatura temporale, ti consigliamo di eseguire una o tutte le seguenti operazioni:
+ Aggiungi i predicati temporali mancanti nella query e assicurati che i predicati temporali riducano la finestra temporale desiderata.
+ Rimuovete le funzioni, ad esempio`MAX()`, i predicati temporali.
+ Aggiungi predicati temporali a tutte le sottointerrogazioni. Questo è importante se le tue sottoquery uniscono tabelle di grandi dimensioni o eseguono operazioni complesse.

# Attivazione di informazioni dettagliate sulle query in Amazon Timestream
<a name="enable-query-insights"></a>

Puoi abilitare gli approfondimenti sulle query per le tue query con approfondimenti forniti direttamente tramite la risposta alla query. L'attivazione di Query Insights non richiede un'infrastruttura aggiuntiva né comporta costi aggiuntivi. Quando si abilita Query Insights, vengono restituiti i campi di metadati relativi alle prestazioni delle query oltre ai risultati delle query come parte della risposta alla query. È possibile utilizzare queste informazioni per ottimizzare le query per migliorare le prestazioni delle query e ridurre i costi delle query.

Per informazioni sull'attivazione di Query Insights, consulta[Esecuzione di una query](console_timestream.md#console_timestream.queries.using-console).

Per visualizzare esempi delle risposte restituite abilitando Query Insights, consulta [Esempi di query pianificate](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples).

**Nota**  
Quando abiliti Query Insights, it rate limita la query a 1 query al secondo (QPS). Per evitare impatti sulle prestazioni, ti consigliamo vivamente di abilitare Query Insights solo durante la fase di valutazione delle query, prima di distribuirle in produzione.
Le informazioni fornite in Query Insights alla fine sono coerenti, il che significa che potrebbero cambiare man mano che nuovi dati vengono continuamente inseriti nelle tabelle.

# Ottimizzazione delle query utilizzando la risposta a Query Insights
<a name="optimize-query-using-query-insights"></a>

Supponiamo che tu stia utilizzando Amazon Timestream LiveAnalytics per monitorare il consumo di energia in varie località. Immagina di avere due tabelle nel tuo database denominate `raw-metrics` e. `aggregate-metrics`

La `raw-metrics` tabella memorizza dati energetici dettagliati a livello di dispositivo e contiene le seguenti colonne:
+ Time stamp
+ Stato, ad esempio, Washington
+ ID dispositivo
+ Consumo energetico

I dati di questa tabella vengono raccolti e archiviati in modo minute-by-minute granulare. La tabella viene utilizzata `State` come CDPK.

La `aggregate-metrics` tabella memorizza il risultato di una query pianificata per aggregare i dati sul consumo energetico di tutti i dispositivi su base oraria. Questa tabella contiene le seguenti colonne:
+ Time stamp
+ Stato, ad esempio, Washington
+ Consumo energetico totale

La `aggregate-metrics` tabella memorizza questi dati con una granularità oraria. La tabella utilizza `State` come CDPK.

**Topics**
+ [Interrogazione del consumo energetico delle ultime 24 ore](#query-energy-consumption-data)
+ [Ottimizzazione della query per l'intervallo temporale](#optimize-query-temporal-range)
+ [Ottimizzazione dell'interrogazione per la copertura spaziale](#optimize-query-spatial-coverage)
+ [Prestazioni di interrogazione migliorate](#improved-query-performance)

## Interrogazione del consumo energetico delle ultime 24 ore
<a name="query-energy-consumption-data"></a>

Supponiamo di voler estrarre l'energia totale consumata a Washington nelle ultime 24 ore. Per trovare questi dati, puoi sfruttare i punti di forza di entrambe le tabelle: `raw-metrics` e. `aggregate-metrics` La `aggregate-metrics` tabella fornisce dati orari sul consumo energetico nelle ultime 23 ore, mentre la `raw-metrics` tabella offre dati granulari al minuto per l'ultima ora. Interrogando entrambe le tabelle, è possibile ottenere un quadro completo e preciso del consumo di energia a Washington nelle ultime 24 ore.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
 "metrics"."aggregate-metrics" am
 LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE rm.time >= ago(1h) and rm.time < now()
```

Questa query di esempio viene fornita solo a scopo illustrativo e potrebbe non funzionare così com'è. Ha lo scopo di dimostrare il concetto, ma potrebbe essere necessario modificarlo per adattarlo al caso d'uso o all'ambiente specifico.

Dopo aver eseguito questa query, potresti notare che il tempo di risposta alla query è più lento del previsto. Per identificare la causa principale di questo problema di prestazioni, è possibile utilizzare la funzionalità Query Insights per analizzare le prestazioni della query e ottimizzarne l'esecuzione.

L'esempio seguente mostra la risposta a Query Insights.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 1.0,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/raw-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value:31540000000000000 //365 days,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

La risposta a Query Insights fornisce le seguenti informazioni:
+ Intervallo **temporale: la query ha analizzato un intervallo** temporale eccessivo di 365 giorni per la tabella. `aggregate-metrics` Ciò indica un uso inefficiente del filtro temporale.
+ **Copertura spaziale**: l'interrogazione ha analizzato l'intero intervallo spaziale (100%) della tabella. `raw-metrics` Ciò suggerisce che il filtro spaziale non viene utilizzato in modo efficace.

Se la query accede a più di una tabella, Query Insights fornisce le metriche per la tabella con il modello di accesso meno ottimale.

## Ottimizzazione della query per l'intervallo temporale
<a name="optimize-query-temporal-range"></a>

In base alla risposta a Query Insights, è possibile ottimizzare la query per l'intervallo temporale, come illustrato nell'esempio seguente.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
  "metrics"."aggregate-metrics" am
  LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE 
  am.time >=  ago(23h) and am.time < now()
  AND rm.time >=  ago(1h) and rm.time < now()
  AND rm.state = 'Washington'
```

Se si esegue nuovamente il `QueryInsights` comando, viene restituita la seguente risposta.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 1.0,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value: 82800000000000 //23 hours,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

Questa risposta mostra che la copertura spaziale della `aggregate-metrics` tabella è ancora del 100%, il che è inefficiente. La sezione seguente mostra come ottimizzare l'interrogazione per la copertura spaziale.

## Ottimizzazione dell'interrogazione per la copertura spaziale
<a name="optimize-query-spatial-coverage"></a>

In base alla risposta a Query Insights, è possibile ottimizzare la query per la copertura spaziale, come illustrato nell'esempio seguente.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
  "metrics"."aggregate-metrics" am
  LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE 
  am.time >=  ago(23h) and am.time < now()
  AND am.state ='Washington'
  AND rm.time >=  ago(1h) and rm.time < now()
  AND rm.state = 'Washington'
```

Se si esegue nuovamente il `QueryInsights` comando, viene restituita la seguente risposta.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 0.02,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value: 82800000000000 //23 hours,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

## Prestazioni di interrogazione migliorate
<a name="improved-query-performance"></a>

Dopo aver ottimizzato la query, Query Insights fornisce le seguenti informazioni:
+ La potatura temporale della `aggregate-metrics` tavola è di 23 ore. Ciò indica che vengono scansionate solo 23 ore dell'intervallo temporale.
+ La potatura spaziale per `aggregate-metrics` la tavola è 0,02. Ciò indica che viene scansionato solo il 2% dei dati relativi all'intervallo spaziale della tabella. La query analizza una parte molto piccola delle tabelle, con conseguente aumento delle prestazioni e riduzione dell'utilizzo delle risorse. La migliore efficienza di potatura indica che la query è ora ottimizzata per le prestazioni.