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í](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html). 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. # Uso de la información sobre las consultas para su optimización en Amazon Timestream La información sobre las consultas es una característica de ajuste del rendimiento que le ayuda a optimizar sus consultas, mejorar su rendimiento y reducir los costos. Con la información sobre las consultas, puede evaluar la eficiencia de la poda temporal, basada en tiempo y basada en la clave de partición espacial de las consultas. Con la información sobre las consultas, también puede identificar áreas de mejora del rendimiento de las consultas. Además, con la información sobre las consultas, puede evaluar la eficacia con la que estas usan la indexación basada en tiempo y la indexación basada en clave de partición para optimizar la recuperación de datos. A fin de optimizar el rendimiento de las consultas, es esencial refinar los parámetros temporales y espaciales que rigen la ejecución de las consultas. **Topics** + [Ventajas de la información sobre las consultas](#query-insights-benefits) + [Optimización del acceso a datos en Amazon Timestream](query-insights-optimize-data-access-pattern.md) + [Habilitación de la información sobre las consultas en Amazon Timestream](enable-query-insights.md) + [Optimización de las consultas mediante la respuesta a la información sobre las consultas](optimize-query-using-query-insights.md) ## Ventajas de la información sobre las consultas A continuación, se describen las principales ventajas de usar la información sobre las consultas: + **Identificación de consultas ineficientes**: la información sobre las consultas proporciona información sobre la poda basada en tiempo y la poda basada en atributos de las tablas a las que accede la consulta. Esta información le permitirá identificar las tablas a las que se accede de forma no óptima. + **Optimización del modelo de datos y el particionamiento**: puede usar la información sobre las consultas para acceder a su modelo de datos y su estrategia de particionamiento y refinarlos. + **Ajuste de las consultas**: la información sobre las consultas destaca las oportunidades para usar los índices de forma más eficaz. # Optimización del acceso a datos en Amazon Timestream Puede optimizar los patrones de acceso a los datos en Amazon Timestream mediante el esquema de particionamiento o técnicas de organización de datos de Timestream. **Topics** + [Esquema de particionamiento de Timestream](#query-insights-optimize-data-access-partitioning-scheme) + [Organización de datos](#query-insights-optimize-data-access-data-org) ## Esquema de particionamiento de Timestream Amazon Timestream usa un esquema de particionamiento altamente escalable en el que cada tabla de Timestream puede tener cientos, miles o incluso millones de particiones independientes. Un servicio de indexación y seguimiento de particiones de alta disponibilidad gestiona la partición, lo que minimiza el impacto de los errores y hace que el sistema sea más resistente. ![\[Esquema de particionamiento de Timestream\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png) ## Organización de datos Timestream almacena cada punto de datos que ingiere en una sola partición. Al introducir datos en una tabla Timestream, Timestream crea particiones de forma automática en función de las marcas de tiempo, la clave de partición y otros atributos de contexto de los datos. Además de particionar los datos a tiempo (partición temporal), Timestream también divide los datos en función de la clave de partición seleccionada y de otras dimensiones (partición espacial). Este enfoque permite distribuir el tráfico de escritura y podar de manera eficaz los datos para las consultas. La característica de información sobre las consultas proporciona información valiosa sobre la eficiencia de la poda por parte de la consulta, que incluye las coberturas espacial y temporal de las consultas. **Topics** + [QuerySpatialCoverage](#query-insights-data-org-query-spatial-cvg) + [QueryTemporalCoverage](#query-insights-data-org-query-temporal-cvg) ### QuerySpatialCoverage La [QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)métrica proporciona información sobre la cobertura espacial de la consulta ejecutada y de la tabla con la depuración espacial más ineficiente. Esta información puede ayudarlo a identificar las áreas que deben mejorarse en su estrategia de partición para mejorar la poda espacial. El valor de la métrica `QuerySpatialCoverage` oscila entre 0 y 1. Cuanto más bajo sea el valor de la métrica, más óptima será la poda de la consulta en el eje espacial. Por ejemplo, un valor de 0,1 indica que la consulta explora el 10 % del eje espacial. Un valor de 1 indica que la consulta escanea el 100 % del eje espacial. **Example Uso de la información sobre las consultas para analizar la cobertura espacial de una consulta** Supongamos que tiene una base de datos de Timestream que almacena datos meteorológicos. Suponga que la temperatura se registra cada hora desde estaciones meteorológicas ubicadas en diferentes estados de los Estados Unidos. Imagine que elige `State` como una [clave de partición definida por el cliente](customer-defined-partition-keys.md) (CDPK) para particionar los datos por estado. Supongamos que ejecuta una consulta para recuperar la temperatura media de todas las estaciones meteorológicas de California entre las 2 p. m. y las 4 p. m., de un día específico. El siguiente es un ejemplo de consulta para este escenario: ``` 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'; ``` Con la característica de información sobre las consultas, puede analizar la cobertura espacial de la consulta. Imagine que la métrica `QuerySpatialCoverage` devuelve un valor de 0,02. Esto significa que la consulta solo escaneó el 2 % del eje espacial, lo que es eficiente. En este caso, la consulta pudo reducir el rango espacial de manera efectiva, ya que recuperó únicamente datos de California e ignoró los datos de otros estados. Por el contrario, si la métrica `QuerySpatialCoverage` devolviera un valor de 0,8, indicaría que la consulta escaneó el 80 % del eje espacial, lo que es menos eficiente. Esto podría sugerir que es necesario afinar la estrategia de partición para mejorar la poda espacial. Por ejemplo, puede seleccionar la clave de partición como ciudad o región en lugar de como estado. Con el análisis de la métrica `QuerySpatialCoverage`, puede identificar oportunidades para optimizar su estrategia de particionamiento y mejorar el rendimiento de sus consultas. En la siguiente imagen, se muestra una poda espacial deficiente. ![\[Resultado que proporciona la métrica QuerySpatialCoverage y muestra una poda espacial deficiente.\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png) Para mejorar la eficiencia de la poda espacial, puede llevar a cabo una de las siguientes acciones o ambas: + Agregue `measure_name`, la clave de partición predeterminada o use los predicados de la CDPK en la consulta. + Si ya ha agregado los atributos que se mencionan en el punto anterior, elimine las funciones relacionadas con estos atributos o cláusulas, por ejemplo, `LIKE`. ### QueryTemporalCoverage La métrica `QueryTemporalCoverage` proporciona información sobre el rango temporal que se explora con la consulta ejecutada, lo que incluye la tabla con el mayor rango de tiempo escaneado. El valor de la métrica `QueryTemporalCoverage` es el intervalo de tiempo representado en nanosegundos. Cuanto más bajo sea el valor de esta métrica, más óptima será la poda de la consulta en el rango temporal. Por ejemplo, una consulta que escanea los últimos minutos de datos es más eficaz que una consulta que escanea todo el intervalo de tiempo de la tabla. **Example** Supongamos que tiene una base de datos de Timestream que almacena datos de sensores de IoT, con mediciones tomadas cada minuto desde dispositivos que se encuentran en una planta de fabricación. Suponga que ha dividido sus datos por `device_ID`. Supongamos que ejecuta una consulta para recuperar la lectura media del sensor de un dispositivo específico durante los últimos 30 minutos. El siguiente es un ejemplo de consulta para este escenario: ``` SELECT AVG(sensor_reading) FROM "sensor_data"."factory_1" WHERE device_id = 'DEV_123' AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW(); ``` Con la característica de información sobre las consultas, puede analizar el rango temporal que escanea la consulta. Imagine que la métrica `QueryTemporalCoverage` devuelve un valor de 1800000000000 nanosegundos (30 minutos). Esto significa que la consulta solo escaneó los datos de los últimos 30 minutos, lo que constituye un intervalo temporal relativamente estrecho. Esto es una buena señal porque indica que la consulta pudo podar eficazmente la partición temporal y solo recuperó los datos que se solicitaron. Por el contrario, si la métrica `QueryTemporalCoverage` arrojó un valor de 1 año en nanosegundos, indica que la consulta analizó un intervalo de tiempo de un año en la tabla, lo que resulta menos eficiente. Esto podría sugerir que la consulta no está optimizada para la poda temporal, por lo que podría mejorarla si añade filtros de tiempo. En la siguiente imagen, se muestra una poda temporal deficiente. ![\[Resultado que proporciona la métrica QueryTemporalCoverage y muestra una poda temporal deficiente.\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png) Para mejorar la poda temporal, le recomendamos que realice una o todas las siguientes acciones: + Agregue los predicados de tiempo que faltan en la consulta y asegúrese de que estos poden el intervalo de tiempo deseado. + Elimine funciones relacionadas con los predicados de tiempo, como `MAX()`. + Agregue predicados de tiempo a todas las subconsultas. Esto es importante si las subconsultas unen tablas grandes o realizan operaciones complejas. # Habilitación de la información sobre las consultas en Amazon Timestream Puede habilitar la información sobre las consultas con la información que se proporciona directamente a través de la respuesta a la consulta. La habilitación de la información sobre las consultas no requiere infraestructura adicional ni implica costos adicionales. Al habilitar la información sobre las consultas, esta devuelve campos de metadatos relacionados con el rendimiento de la consulta, además de los resultados, como parte de la respuesta. Puede usar esta información para ajustar las consultas con el fin de mejorar el rendimiento y reducir el costo. Consulte [Ejecutar una consulta](console_timestream.md#console_timestream.queries.using-console) para obtener información sobre cómo habilitar la información sobre las consultas. Consulte [Ejemplos de consultas programadas](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples) para ver ejemplos de las respuestas que se devuelven cuando se habilita la información sobre las consultas. **nota** Cuando habilita la información sobre las consultas, la frecuencia se limita a 1 consulta por segundo (QPS). Para evitar que el rendimiento se vea afectado, le recomendamos encarecidamente que habilite la información sobre las consultas solo durante la fase de evaluación, antes de implementarlas en producción. Las estadísticas que se proporcionan en la información sobre las consultas acaba siendo coherente, lo que significa que podría cambiar a medida que se incorporen nuevos datos a las tablas. # 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. **Topics** + [Consulta del consumo de energía de las últimas 24 horas](#query-energy-consumption-data) + [Optimización de la consulta de rango temporal](#optimize-query-temporal-range) + [Optimización de la consulta de cobertura espacial](#optimize-query-spatial-coverage) + [Mejora del rendimiento de consultas](#improved-query-performance) ## 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-metrics` es de 23 horas. Esto indica que solo se escanean 23 horas del rango temporal. + La poda espacial de la tabla `aggregate-metrics` es 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.