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á.

# Usando insights de consulta para otimizar consultas no Amazon Timestream
<a name="using-query-insights"></a>

O Insights de consulta é um atributo de ajuste de desempenho que ajuda você a otimizar suas consultas, melhorar seu desempenho e reduzir custos. Com os insights de consulta, você pode avaliar a eficiência de redução de partições temporais, baseadas em tempo e espaciais de suas consultas. Usando insights de consulta, você também pode identificar áreas de melhoria para aprimorar o desempenho da consulta. Além disso, com os insights de consulta, você pode avaliar a eficiência com que suas consultas usam a indexação baseada em tempo e em chave de partição para otimizar a recuperação de dados. Para otimizar o desempenho da consulta, é essencial ajustar os parâmetros temporais e espaciais que governam a execução da consulta.

**Topics**
+ [Benefícios dos insights de consulta](#query-insights-benefits)
+ [Otimizar o acesso a dados no Amazon Timestream](query-insights-optimize-data-access-pattern.md)
+ [Habilitar insights de consulta no Amazon Timestream](enable-query-insights.md)
+ [Otimizando consultas usando a resposta de insights de consulta](optimize-query-using-query-insights.md)

## Benefícios dos insights de consulta
<a name="query-insights-benefits"></a>

Os benefícios principais de usar os insights de consulta são os seguintes: 
+ **Identificação de consultas ineficientes**: o Insights de consulta fornece informações sobre a redução baseada em tempo e baseada atributo das tabelas acessadas pela consulta. Essas informações ajudarão você a identificar as tabelas que não são acessadas de forma ideal.
+ **Otimização do seu modelo de dados e particionamento**: você pode usar as informações de insights de consulta para acessar e ajustar seu modelo de dados e sua estratégia de particionamento.
+ **Ajuste de consultas**: os insights de consulta destacam oportunidades de usar índices com mais eficiência.

# Otimizar o acesso a dados no Amazon Timestream
<a name="query-insights-optimize-data-access-pattern"></a>

Você pode otimizar os padrões de acesso aos dados no Amazon Timestream usando o esquema de particionamento Timestream ou técnicas de organização de dados.

**Topics**
+ [Esquema de particionamento do Timestream](#query-insights-optimize-data-access-partitioning-scheme)
+ [Organização de dados](#query-insights-optimize-data-access-data-org)

## Esquema de particionamento do Timestream
<a name="query-insights-optimize-data-access-partitioning-scheme"></a>

O Amazon Timestream usa um esquema de particionamento altamente escalável em que cada tabela do Timestream pode ter centenas, milhares ou até milhões de partições independentes. Um serviço de indexação e rastreamento de partições altamente disponível gerencia o particionamento, minimizando o impacto das falhas e tornando o sistema mais resiliente.

![\[Esquema de particionamento do Timestream\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png)


## Organização de dados
<a name="query-insights-optimize-data-access-data-org"></a>

O Timestream armazena cada ponto de dados que ingere em uma única partição. Conforme você ingere dados em uma tabela do Timestream, o Timestream cria automaticamente partições com base nos registros de data e hora, na chave de partição e em outros atributos de contexto nos dados. Além de particionar os dados no tempo (particionamento temporal), o Timestream também particiona os dados com base na chave de particionamento selecionada e em outras dimensões (particionamento espacial). Essa abordagem foi projetada para distribuir o tráfego de gravação e permitir a remoção eficaz dos dados para consultas.

O atributo de insights de consulta fornece informações valiosas sobre a eficiência de remoção da consulta, que inclui cobertura espacial da consulta e cobertura temporal da consulta.

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

A [QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)métrica fornece informações sobre a cobertura espacial da consulta executada e a tabela com a redução espacial mais ineficiente. Essas informações podem ajudar você a identificar áreas de melhoria na estratégia de particionamento para aprimorar a redução espacial. O valor da métrica `QuerySpatialCoverage` varia entre 0 e 1. Quanto menor o valor da métrica, melhor será a redução da consulta no eixo espacial. Por exemplo, um valor de 0,1 indica que a consulta analisou 10% do eixo espacial. Um valor de 1 indica que a consulta analisou 100% do eixo espacial.

**Example Usando insights de consulta para analisar a cobertura espacial de uma consulta**  
Digamos que você tenha um banco de dados Timestream que armazena dados meteorológicos. Suponha que a temperatura seja registrada a cada hora em estações meteorológicas localizadas em diferentes estados dos Estados Unidos. Imagine que você escolha `State` como a [chave de particionamento definida pelo cliente](customer-defined-partition-keys.md) (CDPK) para particionar os dados por estado.  
Suponha que você execute uma consulta para recuperar a temperatura média de todas as estações meteorológicas na Califórnia entre 14h e 16h em um dia específico. O exemplo a seguir mostra a consulta para esse cenário.  

```
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';
```
Usando o atributo de insights de consulta, você pode analisar a cobertura espacial da consulta. Imagine que a métrica `QuerySpatialCoverage` retorne um valor de 0,02. Isso significa que a consulta analisou apenas 2% do eixo espacial, o que é eficiente. Nesse caso, a consulta conseguiu reduzir efetivamente a faixa espacial, recuperando apenas dados da Califórnia e ignorando dados de outros estados.  
Por outro lado, se a métrica `QuerySpatialCoverage` retornasse um valor de 0,8, isso indicaria que a consulta analisou 80% do eixo espacial, o que é menos eficiente. Isso pode sugerir que a estratégia de particionamento precisa ser refinada para melhorar a redução espacial. Por exemplo, você pode selecionar a chave de partição como cidade ou região em vez de estado. Ao analisar a métrica `QuerySpatialCoverage`, você pode identificar oportunidades para otimizar sua estratégia de particionamento e melhorar o desempenho de suas consultas.

A imagem a seguir mostra uma redução espacial deficiente.

![\[Resultado fornecido pela métrica QuerySpatialCoverage que mostra uma redução espacial deficiente.\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png)


Para melhorar a eficiência da redução espacial, você pode fazer um dos seguintes procedimentos ou ambos:
+ Adicione `measure_name`, que é a chave de particionamento padrão, ou use os predicados do CDPK em sua consulta.
+ Se você já adicionou os atributos mencionados no ponto anterior, remova as funções em torno desses atributos ou cláusulas, como `LIKE`.

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

A métrica `QueryTemporalCoverage` fornece informações sobre o intervalo temporal analisado pela consulta executada, incluindo a tabela com o maior intervalo de tempo verificado. O valor da métrica `QueryTemporalCoverage` é o intervalo de tempo representado em nanossegundos. Quanto menor o valor dessa métrica, melhor será a redução da consulta no intervalo temporal. Por exemplo, uma consulta que verifica os últimos minutos de dados tem melhor desempenho do que uma consulta que verifica todo o intervalo de tempo da tabela.

**Example**  
Digamos que você tenha um banco de dados Timestream que armazena dados de sensores IoT, com medições feitas a cada minuto em dispositivos localizados em uma fábrica. Suponha que você tenha particionado seus dados por `device_ID`.  
Suponha que você execute uma consulta para recuperar a leitura média do sensor de um dispositivo específico nos últimos 30 minutos. O exemplo a seguir mostra a consulta para esse cenário.  

```
SELECT AVG(sensor_reading) 
FROM "sensor_data"."factory_1"
WHERE device_id = 'DEV_123' 
  AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW();
```
Usando o recurso de insights de consulta, você pode analisar o intervalo temporal analisado pela consulta. Imagine que a métrica `QueryTemporalCoverage` retorne um valor de 1800000000000 nanossegundos (30 minutos). Isso significa que a consulta analisou apenas os últimos 30 minutos de dados, o que é um intervalo temporal relativamente estreito. Isso é um bom sinal porque indica que a consulta conseguiu eliminar efetivamente o particionamento temporal e recuperou somente os dados solicitados.  
Por outro lado, se a métrica `QueryTemporalCoverage` retornou um valor de 1 ano em nanossegundos, isso indica que a consulta examinou um ano do intervalo de tempo na tabela, o que é menos eficiente. Isso pode sugerir que a consulta não está otimizada para remoção temporal, e você pode melhorá-la adicionando filtros de tempo.

A imagem a seguir mostra uma redução temporal deficiente.

![\[Resultado fornecido pela métrica QueryTemporalCoverage que mostra uma redução temporal deficiente.\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png)


Para melhorar a redução temporal, é recomendável executar um ou todos os procedimentos a seguir:
+ Adicione os predicados de tempo ausentes na consulta e certifique-se de que os predicados de tempo estejam eliminando a janela de tempo desejada.
+ Remova funções, como `MAX()`, de acordo com os predicados de tempo.
+ Adicione predicados de tempo a todas as subconsultas. Isso é importante se suas subconsultas estiverem unindo tabelas grandes ou executando operações complexas.

# Habilitar insights de consulta no Amazon Timestream
<a name="enable-query-insights"></a>

Você pode habilitar insights de consulta para suas consultas com insights fornecidos diretamente por meio da resposta da consulta. Habilitar insights de consulta não requer infraestrutura adicional nem incorre em custos adicionais. Quando você ativa os insights da consulta, ele retorna campos de metadados relacionados ao desempenho da consulta, além dos resultados da consulta, como parte da resposta da consulta. É possível utilizar essas informações para ajustar suas consultas para melhorar o desempenho da consulta e reduzir o custo da consulta.

Para obter informações sobre como ativar insights de consulta, consulte [Execute uma consulta](console_timestream.md#console_timestream.queries.using-console).

Para ver exemplos das respostas retornadas ao ativar os insights de consulta, consulte [Exemplos de consultas agendadas](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples).

**nota**  
Quando você ativa os insights de consulta, a taxa limita a consulta a 1 consulta por segundo (QPS). Para evitar impactos no desempenho, é altamente recomendável que você ative os insights de consulta somente durante a fase de avaliação de suas consultas, antes de implantá-las na produção.
Os insights fornecidos nos insights de consulta acabam sendo consistentes, o que significa que podem mudar à medida que novos dados são continuamente ingeridos nas tabelas.

# 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.