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 del acceso a los datos en Amazon Timestream
Puede optimizar los patrones de acceso a los datos en Amazon Timestream mediante el esquema de particionamiento de Timestream o técnicas de organización de datos.
Esquema de particionamiento de Timestream
Amazon Timestream utiliza 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 Timestream](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 automáticamente 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 otras dimensiones (partición espacial). Este enfoque está diseñado para distribuir el tráfico de escritura y permitir una depuración eficaz de los datos para las consultas.
La función de información sobre consultas proporciona información valiosa sobre la eficiencia de la consulta, que incluye la cobertura espacial y la cobertura temporal de las consultas.
QuerySpatialCoverage
La QuerySpatialCoveragemétrica proporciona información sobre la cobertura espacial de la consulta ejecutada y de la tabla con el ajuste espacial más ineficiente. Esta información puede ayudarlo a identificar las áreas de mejora en la estrategia de partición para mejorar la reducción espacial. El valor de la QuerySpatialCoverage
métrica oscila entre 0 y 1. Cuanto más bajo sea el valor de la métrica, más óptima será la depuración de las consultas 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.
ejemplo Uso de la información de 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
la clave de partición definida por el cliente (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 14 y las 16 horas de un día específico. En el siguiente ejemplo, se muestra la 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 función de información sobre consultas, puede analizar la cobertura espacial de la consulta. Imagine que la QuerySpatialCoverage
métrica devuelve un valor de 0,02. Esto significa que la consulta solo escaneó el 2% del eje espacial, lo cual es eficiente. En este caso, la consulta pudo reducir el rango espacial de manera efectiva, recuperando únicamente datos de California e ignorando los datos de otros estados.
Por el contrario, si la QuerySpatialCoverage
métrica 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 depuración espacial. Por ejemplo, puede seleccionar la clave de partición como ciudad o región en lugar de como estado. Al analizar la QuerySpatialCoverage
métrica, puede identificar oportunidades para optimizar su estrategia de particionamiento y mejorar el rendimiento de sus consultas.
La siguiente imagen muestra un recorte espacial deficiente.
![Resultado proporcionado por la QuerySpatialCoverage métrica que muestra una poda espacial deficiente.](images/QueryInsights/QuerySpatialCoverageMetricResult.png)
Para mejorar la eficiencia de la poda espacial, puede realizar una de las siguientes acciones o ambas:
-
measure_name
Añada la clave de partición predeterminada o utilice los CDPK predicados en la consulta. -
Si ya ha agregado los atributos mencionados en el punto anterior, elimine las funciones relacionadas con estos atributos o cláusulas, como.
LIKE
QueryTemporalCoverage
La QueryTemporalCoverage
métrica proporciona información sobre el rango temporal explorado por la consulta ejecutada, incluida la tabla con el rango de tiempo más grande escaneado. El valor de la QueryTemporalCoverage
métrica es el intervalo de tiempo representado en nanosegundos. Cuanto más bajo sea el valor de esta métrica, más óptima será la reducción 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.
ejemplo
Supongamos que tiene una base de datos de Timestream que almacena datos de sensores de IoT, con mediciones tomadas cada minuto desde dispositivos ubicados 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. En el siguiente ejemplo, se muestra la 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 función de información sobre consultas, puede analizar el rango temporal escaneado por la consulta. Imagine que la QueryTemporalCoverage
métrica 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 reducir eficazmente la partición temporal y solo recuperó los datos solicitados.
Por el contrario, si la QueryTemporalCoverage
métrica 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 reducción temporal, por lo que podría mejorarla añadiendo filtros de tiempo.
La siguiente imagen muestra una poda temporal deficiente.
![Resultado proporcionado por la QueryTemporalCoverage métrica que muestra una poda temporal deficiente.](images/QueryInsights/QueryTemporalCoverageMetricResult.png)
Para mejorar la poda temporal, le recomendamos que realice una de las siguientes acciones o todas ellas:
-
Agregue los predicados de tiempo que faltan en la consulta y asegúrese de que los predicados de tiempo estén ajustando el intervalo de tiempo deseado.
-
Elimine funciones, por ejemplo, relacionadas
MAX()
con los predicados de tiempo. -
Agregue predicados de tiempo a todas las subconsultas. Esto es importante si las subconsultas unen tablas grandes o realizan operaciones complejas.