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
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
aggregate-metrics
e.
A raw-metrics
tabela 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 o.
A aggregate-metrics
tabela armazena o resultado de uma consulta agendada para agregar os dados de consumo de energia em todos os dispositivos de hora em hora. Essa tabela contém as seguintes colunas:
-
Timestamp
-
Estado, por exemplo, Washington
-
Consumo total de energia
A aggregate-metrics
tabela armazena esses dados em uma granularidade horária. A tabela usa State
como CDPK o.
Tópicos
Consultando o consumo de energia nas últimas 24 horas
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 aggregate-metrics
tabela fornece dados de consumo de energia por hora nas últimas 23 horas, enquanto a raw-metrics
tabela 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 recurso de insights de consulta para analisar o desempenho da consulta e otimizar sua execução.
O exemplo a seguir mostra a resposta dos insights da 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 query insights 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
raw-metrics
tabela. 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 da tabela com o padrão de acesso mais abaixo do ideal.
Otimizando a consulta para intervalo temporal
Com base na resposta dos insights da consulta, você pode otimizar a consulta para o intervalo temporal, conforme 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 QueryInsights
comando novamente, ele 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 aggregate-metrics
tabela 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
Com base na resposta dos insights da consulta, você pode otimizar a consulta para cobertura espacial, conforme 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 QueryInsights
comando novamente, ele 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
Desempenho aprimorado de consultas
Depois de otimizar a consulta, os insights de consulta fornecem as seguintes informações:
-
A poda temporal da
aggregate-metrics
mesa é de 23 horas. Isso indica que somente 23 horas do intervalo temporal são escaneadas. -
A poda espacial da
aggregate-metrics
mesa é de 0,02. Isso indica que apenas 2% dos dados do intervalo espacial da tabela estão sendo digitalizados. A consulta verifica 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.