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.

Pilar de eficiencia de rendimiento

El pilar de eficiencia del rendimiento del AWS Well-Architected Framework se centra en cómo optimizar el rendimiento al ingerir o consultar datos. La optimización del rendimiento es un proceso gradual y continuo que consiste en lo siguiente:

El pilar de la eficiencia del rendimiento proporciona pautas que pueden ayudarlo a elegir un modelo de datos de alto rendimiento. El pilar de la eficiencia del rendimiento incluye las mejores prácticas de optimización de consulta y escritura.

El pilar de la eficiencia del rendimiento se centra en las siguientes áreas clave:

Modelado de datos de afluencia y optimización de consultas

Diseñar un esquema efectivo es crucial para optimizar el rendimiento y las capacidades de consulta de los datos de series temporales en InfluxDB. Comience por elegir las etiquetas y los campos correctos. InfluxDB indexa las etiquetas, por lo que el motor de consultas no necesita escanear todos los registros de una medición para localizar el valor de una etiqueta. Esto significa que consultar etiquetas es más eficiente que consultar campos. Para compactar y almacenar los datos, el motor de almacenamiento agrupa los valores de los campos por clave de serie y, a continuación, los ordena por tiempo. Una clave de serie se define mediante la medición, la clave y el valor de la etiqueta y la clave de campo. Para obtener más información sobre el diseño de datos, consulte la documentación de InfluxDB.

El motor de almacenamiento utiliza un formato de datos de árbol de fusión estructurado en el tiempo (TSM). Para obtener más información sobre el formato de datos TSM, consulte la documentación de InfluxDB.

Imagine que está recopilando datos (timestamp,,host_id,region,cpu, memory network_in_bytesnetwork_out_bytes,disk_io) como parte de un DevOps caso de uso. Las etiquetas, incluida la marca de tiempo del registro, proporcionan un contexto que ayuda a identificar el quién, el qué, el cuándo y el dónde de un registro. Las etiquetas se utilizan para organizar y clasificar los datos y para filtrar los datos como parte de una consulta.

Las region etiquetas host_id y son etiquetas ideales para organizar y categorizar el caso de DevOps uso. Estas columnas ayudan a filtrar los datos de un host en particular o a ejecutar un análisis basado en la columna de la región.

Las medidas proporcionan la base para realizar cálculos matemáticos (como calcular los totales, los promedios y las diferencias en la tasa de cambio) y el análisis cuantitativo de los datos. Por lo tanto cpumemory,, network_in_bytesnetwork_out_bytes, y disk_io capturan métricas importantes relacionadas con las DevOps que cambian con el tiempo. Puede utilizar estas métricas para realizar varios análisis, como calcular la CPU y la memoria en distintos hosts. Puede usar estos valores métricos para tomar decisiones basadas en datos que le ayuden a evitar interrupciones en la producción y a planificar la infraestructura.

La cardinalidad es la combinación de valores de etiqueta únicos. Intente mantener la cardinalidad lo más baja posible. Si su aplicación requiere un identificador único para cada punto de datos, utilice valores de campo en lugar de valores de etiqueta. Esto se traducirá en una latencia de consulta significativamente mejor. Un buen diseño del esquema puede evitar una alta cardinalidad de las series, lo que se traduce en un mejor rendimiento de las consultas. Si nota que las lecturas y escrituras de datos se ralentizan o si quiere saber cómo afecta la cardinalidad al rendimiento, consulte la documentación de Timestream for InfluxDB.

Si tu aplicación emite objetos JSON, conviértelos en columnas individuales (etiquetas o campos) y carga las columnas en InfluxDB. InfluxDB está diseñado para datos de series temporales, por lo que organizar los datos con columnas individuales es una buena práctica para aprovechar al máximo las capacidades del servicio.

Una sola instancia de OSS de InfluxDB v2.7 admite aproximadamente 20 depósitos de InfluxDB que se escriben o consultan activamente en todas las organizaciones. Más de 20 cubos pueden afectar negativamente al rendimiento. Hay límites en algunas opciones de configuración de InfluxDB y hay algunas opciones que puede configurar en función de su caso de uso. Valide la configuración en función de la carga de trabajo de la aplicación durante la fase de prueba. Las retenciones de datos se configuran a nivel de bucket, por lo que los datos con diferentes requisitos de retención de datos deben almacenarse en diferentes cubos. Para obtener más información sobre las opciones de configuración, consulte la documentación de Timestream for InfluxDB.

Guarde los datos en valores de etiqueta o valores de campo, no en claves de etiqueta, claves de campo o medidas. Si diseñas tu esquema para almacenar datos en valores de etiquetas y campos, tus consultas serán más fáciles de escribir y más eficientes. Para obtener más información sobre las mejores prácticas sobre el modelado de datos, consulte Diseñar para mejorar el rendimiento.

Utilice las tareas de InfluxDB para agregar previamente los datos, cargarlos en diferentes medidas o grupos y generar datos para los paneles y las visualizaciones a partir de ellos.

InfluxDB OSS expone un /metrics punto final que devuelve métricas de rendimiento, recursos y uso formateadas en el formato de exposición de texto plano de Prometheus. Utilice las plantillas de InfluxDB para configurar la supervisión y las alertas a fin de detectar problemas de forma proactiva, como la alta latencia de las consultas, la degradación del rendimiento de escritura o los picos de uso de los recursos.

Timestream para InfluxDB proporciona almacenamiento incluido en Influx IO. La selección del tamaño de IOPS adecuado puede acelerar significativamente la ejecución de las consultas. Esto resulta especialmente útil para las consultas que necesitan escanear grandes cantidades de datos o gestionar una gran variedad de solicitudes. En algunas situaciones, puede ser necesaria una combinación de ampliación de la instancia y mejora de las IOPS para lograr las mejoras de rendimiento deseadas.

Recomendamos combinar los entornos de desarrollo y producción (clase de instancia, tipo de almacenamiento, configuraciones). Pruebe los cambios en el entorno inferior para cada versión antes de pasar a la fase de producción. En los volúmenes de almacenamiento incluidos en Influx IO, Timestream para InfluxDB ofrece tres niveles de almacenamiento preconfigurados con las IOPS óptimas (3000, 12 000 y 16 000) y el rendimiento necesario para diferentes tipos de cargas de trabajo. La mayoría de los casos de uso requieren menos de 3000 IOPS. Elija 12 000 o 16 000 solo si las pruebas de rendimiento indican la necesidad de altas IOPS. Para obtener más información, consulte la sección de configuración de la documentación de Timestream for InfluxDB.

Optimiza las escrituras

Para optimizar las escrituras en InfluxDB, recomendamos escribir los datos en lotes de 5000 líneas de protocolo de línea por solicitud para minimizar la sobrecarga de la red. Para obtener un mejor rendimiento, ordene las etiquetas por clave en orden lexicográfico antes de escribir los puntos de datos. El uso de la precisión temporal más aproximada posible para las marcas de tiempo, en lugar de nanosegundos, también puede mejorar el rendimiento. Habilitar la compresión gzip es otra forma de acelerar las escrituras y reducir el ancho de banda de la red. En la configuración del plugin de influxdb_v2 salida de tu telegraf.conf archivo, establece la content_encoding opción en. gzip La implementación de estas optimizaciones puede mejorar significativamente el rendimiento y la eficiencia de la escritura de datos en InfluxDB. Para obtener más información sobre las mejores prácticas de escritura de InfluxDB, consulte Optimizar las escrituras en InfluxDB.

El rendimiento de escritura de InfluxDB suele estar estrechamente relacionado con las IOPS disponibles. Al escribir datos, InfluxDB necesita realizar una cantidad significativa de operaciones de E/S para almacenar los datos. Al aumentar las IOPS, InfluxDB puede procesar más escrituras por segundo.