Para recursos semelhantes aos do Amazon Timestream para, considere o Amazon Timestream LiveAnalytics para InfluxDB. Ele oferece ingestão de dados simplificada e tempos de resposta de consulta de um dígito em milissegundos para análises em tempo real. Saiba mais [aqui](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Otimizando consultas usando a resposta de insights de consulta
<a name="optimize-query-using-query-insights"></a>

Digamos que você esteja usando o Amazon Timestream LiveAnalytics para monitorar o consumo de energia em vários locais. Imagine que você tenha duas tabelas em seu banco de dados chamadas `raw-metrics` e `aggregate-metrics`.

A tabela `raw-metrics` armazena dados de energia detalhados no nível do dispositivo e contém as seguintes colunas:
+ Timestamp
+ Estado, por exemplo, Washington
+ ID do dispositivo
+ Consumo de energia

Os dados dessa tabela são coletados e armazenados em uma minute-by-minute granularidade. A tabela usa `State` como CDPK.

A tabela `aggregate-metrics` armazena o resultado de uma consulta agendada para agregar os dados de consumo de energia em todos os dispositivos de hora em hora. A tabela contém as colunas a seguir:
+ Timestamp
+ Estado, por exemplo, Washington
+ Consumo de energia total

A tabela `aggregate-metrics` armazena esses dados em uma granularidade horária. A tabela usa `State` como CDPK.

**Topics**
+ [Consultar o consumo de energia nas últimas 24 horas](#query-energy-consumption-data)
+ [Otimizando a consulta para intervalo temporal](#optimize-query-temporal-range)
+ [Otimizando a consulta para cobertura espacial](#optimize-query-spatial-coverage)
+ [Melhoria do desempenho de consultas](#improved-query-performance)

## Consultar o consumo de energia nas últimas 24 horas
<a name="query-energy-consumption-data"></a>

Digamos que você queira extrair a energia total consumida em Washington nas últimas 24 horas. Para encontrar esses dados, você pode aproveitar os pontos fortes de ambas as tabelas: `raw-metrics` e `aggregate-metrics`. A tabela `aggregate-metrics` fornece dados de consumo de energia por hora nas últimas 23 horas, enquanto a tabela `raw-metrics` oferece dados granulares em minutos para a última hora. Ao consultar as duas tabelas, você pode obter uma visão completa e precisa do consumo de energia em Washington nas últimas 24 horas.

```
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()
```

Esse exemplo de consulta é fornecido apenas para fins ilustrativos e pode não funcionar como está. O objetivo é demonstrar o conceito, mas talvez seja necessário modificá-lo para se adequar ao seu caso de uso ou ambiente específico.

Depois de executar essa consulta, você pode perceber que o tempo de resposta da consulta está mais lento do que o esperado. Para identificar a causa raiz desse problema de desempenho, você pode usar o atributo de insights de consulta para analisar o desempenho da consulta e otimizar sua execução.

O exemplo a seguir mostra a resposta do insight de consulta.

```
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
```

A resposta do Insights de consulta fornece as seguintes informações:
+ **Intervalo temporal**: a consulta examinou um intervalo temporal excessivo de 365 dias para a tabela `aggregate-metrics`. Isso indica um uso ineficiente da filtragem temporal.
+ **Cobertura espacial**: a consulta examinou toda a faixa espacial (100%) da tabela `raw-metrics`. Isso sugere que a filtragem espacial não está sendo utilizada de forma eficaz.

Se sua consulta acessar mais de uma tabela, os insights de consulta fornecerão as métricas para a tabela com o padrão de acesso mais abaixo do ideal.

## Otimizando a consulta para intervalo temporal
<a name="optimize-query-temporal-range"></a>

Com base na resposta dos insights de consulta, você pode otimizar a consulta para o intervalo de tempo como mostrado no exemplo a seguir.

```
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 você executar o comando `QueryInsights` novamente, ele vai retornar a seguinte resposta.

```
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
```

Essa resposta mostra que a cobertura espacial da tabela `aggregate-metrics` ainda é de 100%, o que é ineficiente. A seção a seguir mostra como otimizar a consulta para cobertura espacial.

## Otimizando a consulta para cobertura espacial
<a name="optimize-query-spatial-coverage"></a>

Com base na resposta dos insights de consulta, você pode otimizar a consulta para cobertura espacial como mostrado no exemplo a seguir.

```
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 você executar o comando `QueryInsights` novamente, ele vai retornar a seguinte resposta.

```
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
```

## Melhoria do desempenho de consultas
<a name="improved-query-performance"></a>

Depois de otimizar a consulta, o Insights de consulta fornece as seguintes informações:
+ A redução temporal da tabela `aggregate-metrics` é de 23 horas. Isso indica que somente 23 horas do intervalo temporal são analisados.
+ A redução espacial da tabela `aggregate-metrics` é de 0,02. Isso indica que apenas 2% dos dados do intervalo espacial da tabela estão sendo analisados. A consulta analisa uma parte muito pequena das tabelas, levando a um desempenho rápido e à redução da utilização de recursos. A eficiência aprimorada da remoção indica que a consulta agora está otimizada para desempenho.