Para obtener capacidades similares a las de Amazon Timestream, considere Amazon Timestream LiveAnalytics para InfluxDB. Ofrece una ingesta de datos simplificada y tiempos de respuesta a las consultas en milisegundos de un solo dígito para realizar análisis en tiempo real. Obtenga más información aquí.
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Optimización de las consultas mediante la respuesta a la información sobre las consultas
Supongamos que utiliza Amazon Timestream LiveAnalytics para monitorizar el consumo de energía en varios lugares. Imagine que tiene dos tablas en su base de datos denominadas raw-metrics y aggregate-metrics.
La tabla raw-metrics almacena datos de energía detallados a nivel de dispositivo y contiene las siguientes columnas:
-
Timestamp
-
Estado, por ejemplo, Washington
-
Device ID (ID de dispositivo)
-
Consumo de energía
Los datos de esta tabla se recopilan y almacenan de forma granulada minute-by-minute. La tabla usa State como la CDPK.
La tabla aggregate-metrics almacena el resultado de una consulta programada para agregar los datos de consumo de energía de todos los dispositivos cada hora. La tabla contiene las siguientes columnas:
-
Timestamp
-
Estado, por ejemplo, Washington
-
Consumo de energía total
La tabla aggregate-metrics almacena estos datos con una granularidad horaria. La tabla usa State como la CDPK.
Temas
Consulta del consumo de energía de las últimas 24 horas
Supongamos que desea extraer la energía total que se consumió en Washington en las últimas 24 horas. Para encontrar estos datos, puede aprovechar los puntos fuertes de ambas tablas: raw-metrics y aggregate-metrics. La tabla aggregate-metrics proporciona datos sobre el consumo de energía por hora de las últimas 23 horas, mientras que la tabla raw-metrics ofrece datos de la última hora con una granularidad por minuto. Si consulta ambas tablas, puede obtener una imagen completa y precisa del consumo de energía en Washington durante las ú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()
Esta consulta de ejemplo se proporciona únicamente con fines ilustrativos y es posible que no funcione tal cual. Su objetivo es demostrar el concepto, pero es posible que tenga que modificarla para adaptarla a su caso de uso o entorno específicos.
Tras ejecutar esta consulta, es posible que note que el tiempo de respuesta de la consulta es más lento de lo esperado. Para identificar la causa principal de este problema de rendimiento, puede usar la característica de información sobre las consultas para analizar el rendimiento de la consulta y optimizar su ejecución.
En el siguiente ejemplo, se muestra la respuesta de la información sobre las consultas.
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 información sobre las consultas proporciona la siguiente información:
-
Rango temporal: la consulta analizó un rango temporal excesivo de 365 días para la tabla
aggregate-metrics. Esto indica un uso ineficiente del filtrado temporal. -
Cobertura espacial: la consulta escaneó todo el rango espacial (100 %) de la tabla
raw-metrics. Esto sugiere que el uso actual del filtrado espacial no es eficaz.
Si la consulta accede a más de una tabla, la información sobre las consultas proporciona las métricas de la tabla con el patrón de acceso menos óptimo.
Optimización de la consulta de rango temporal
En función de la respuesta de la información sobre la consulta, puede optimizar la consulta para el rango temporal, como se muestra en el siguiente ejemplo.
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'
Si vuelve a ejecutar el comando QueryInsights, devuelve la siguiente respuesta:
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
Esta respuesta muestra que la cobertura espacial de la tabla aggregate-metrics todavía es del 100 %, lo que resulta ineficiente. En la siguiente sección, se muestra cómo optimizar la consulta de cobertura espacial.
Optimización de la consulta de cobertura espacial
En función de la respuesta a la información sobre las consultas, puede optimizar su consulta en cuanto a la cobertura espacial, como se muestra en el siguiente ejemplo.
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'
Si vuelve a ejecutar el comando QueryInsights, devuelve la siguiente respuesta:
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
Mejora del rendimiento de consultas
La información sobre las consultas proporciona la siguiente información después de optimizar la consulta:
-
La poda temporal de la tabla
aggregate-metricses de 23 horas. Esto indica que solo se escanean 23 horas del rango temporal. -
La poda espacial de la tabla
aggregate-metricses de 0,02. Esto indica que solo se escanea el 2 % de los datos del rango espacial de la tabla. La consulta escanea una parte muy pequeña de las tablas, lo que permite obtener un rendimiento rápido y reducir el uso de los recursos. La mejora de la eficiencia de la poda indica que la consulta ahora se optimizó para mejorar el rendimiento.