VictoriaMetrics, TimescaleDB e InfluxDB se compararon en en un conjunto de datos con mil millones de puntos de datos pertenecientes a 40 series temporales únicas.
Hace unos años hubo una era de Zabbix. Cada servidor bare metal no tenía más que unos pocos indicadores: uso de CPU, uso de RAM, uso de disco y uso de red. De esta manera, las métricas de miles de servidores pueden caber en 40 mil series temporales únicas, y Zabbix puede usar MySQL como backend para datos de series temporales :)
Actualmente solo con configuraciones predeterminadas proporciona más de 500 métricas en un host promedio. Hay muchos para diversas bases de datos, servidores web, sistemas de hardware, etc. Todos proporcionan una variedad de métricas útiles. Todo comienzan a establecer varios indicadores por sí mismos. Existe Kubernetes con clústeres y pods que exponen muchas métricas. Esto da como resultado que los servidores expongan miles de métricas únicas por host. Por lo tanto, la serie temporal única de 40K ya no es de alta potencia. Se está volviendo común y debería ser manejado fácilmente por cualquier TSDB moderno en un solo servidor.
¿Cuál es la gran cantidad de series temporales únicas en este momento? ¿Probablemente 400K o 4M? ¿O 40 metros? Comparemos los TSDB modernos con estos números.
Instalación de un punto de referencia
es una excelente herramienta de evaluación comparativa para TSDB. Le permite generar una cantidad arbitraria de métricas pasando la cantidad requerida de series de tiempo dividida por 10 - bandera (anterior -scale-var). 10 es el número de mediciones (métricas) generadas en cada host o servidor. Los siguientes conjuntos de datos se generaron utilizando TSBS para el punto de referencia:
- 400 series temporales únicas, intervalo de 60 segundos entre puntos de datos, datos que abarcan 3 días completos, ~1.7 millones de números totales de puntos de datos.
- 4 millones de series temporales únicas, intervalo de 600 segundos, datos que abarcan 3 días completos, ~1.7 millones de números totales de puntos de datos.
- 40 millones de series temporales únicas, intervalo de 1 hora, datos que abarcan 3 días completos, ~2.8 millones de números totales de puntos de datos.
El cliente y el servidor se ejecutaban en instancias dedicadas. en la nube de Google. Estas instancias tenían las siguientes configuraciones:
- vCPU: 16
- RAM: 60 GB
- Almacenamiento: HDD estándar de 1 TB. Proporciona un rendimiento de lectura/escritura de 120 Mbps, 750 operaciones de lectura por segundo y 1,5 K de escritura por segundo.
Los TSDB se extrajeron de imágenes oficiales de Docker y se ejecutaron en Docker con las siguientes configuraciones:
-
VictoriaMétricas:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Se requieren valores de InfluxDB (-e) para admitir alta potencia. Consulte los detalles en ):
docker run -it --rm -p 8086:8086 -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb -
TimescaleDB (configuración tomada de archivo):
MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432
--shm-size=${SHARED}MB
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data
timescale/timescaledb:latest-pg10 postgres
-cmax_wal_size=${WAL}MB
-clog_line_prefix="%m [%p]: [%x] %u@%d"
-clogging_collector=off
-csynchronous_commit=off
-cshared_buffers=${SHARED}MB
-ceffective_cache_size=${CACHE}MB
-cwork_mem=${WORK}MB
-cmaintenance_work_mem=${MAINT}MB
-cmax_files_per_process=100El cargador de datos se ejecutó con 16 subprocesos paralelos.
Este artículo contiene solo resultados de pruebas comparativas de inserción. Los resultados del benchmark selectivo se publicarán en un artículo aparte.
Serie temporal única de 400
Comencemos con elementos simples: 400K. Resultados de referencia:
- VictoriaMetrics: 2,6 millones de puntos de datos por segundo; Uso de RAM: 3 GB; tamaño final de datos en disco: 965 MB
- InfluxDB: 1.2 millones de puntos de datos por segundo; Uso de RAM: 8.5 GB; tamaño de datos finales en el disco: 1.6 GB
- Escala de tiempo: 849 puntos de datos por segundo; Uso de RAM: 2,5 GB; tamaño final de datos en disco: 50 GB
Como puede ver en los resultados anteriores, VictoriaMetrics gana en rendimiento de inserción y relación de compresión. Timeline gana en uso de RAM, pero utiliza mucho espacio en disco: 29 bytes por punto de datos.
A continuación se muestran los gráficos de uso de CPU para cada una de las TSDB durante la prueba comparativa:
Arriba se muestra una captura de pantalla: VictoriaMetrics: carga de CPU durante la prueba de inserción para una métrica única de 400K.
Arriba se muestra una captura de pantalla: InfluxDB: carga de CPU durante la prueba de inserción para una métrica única de 400K.
Arriba se muestra una captura de pantalla: TimescaleDB: carga de CPU durante la prueba de inserción para una métrica única de 400K.
VictoriaMetrics utiliza todas las vCPU disponibles, mientras que InfluxDB infrautiliza ~2 de 16 vCPU.
Timescale solo usa 3-4 de las 16 vCPU. Las altas proporciones de iowait y system en el gráfico de escala de tiempo de TimescaleDB indican un cuello de botella en el subsistema de entrada/salida (E/S). Veamos los gráficos de uso del ancho de banda del disco:
Arriba se muestra una captura de pantalla: VictoriaMetrics: uso del ancho de banda del disco en la prueba de inserción para métricas únicas 400K.
Arriba se muestra una captura de pantalla: InfluxDB: uso del ancho de banda del disco en la prueba de inserción para métricas únicas 400K.
Arriba se muestra una captura de pantalla: TimescaleDB: uso del ancho de banda del disco en la prueba de inserción para métricas únicas 400K.
VictoriaMetrics registra datos a 20 Mbps con picos de hasta 45 Mbps. Los picos corresponden a grandes fusiones parciales en el árbol. .
InfluxDB escribe datos a 160 MB/s, mientras que una unidad de 1 TB rendimiento de escritura 120 MB/s.
TimescaleDB está limitado a un rendimiento de escritura de 120 Mbps, pero a veces supera este límite y alcanza los 220 Mbps en valores máximos. Estos picos corresponden a los valles de utilización insuficiente de la CPU en el gráfico anterior.
Veamos los gráficos de uso de entrada/salida (E/S):
Arriba se muestra una captura de pantalla: VictoriaMetrics: inserte el uso de E/S de prueba para 400 XNUMX métricas únicas.
Arriba se muestra una captura de pantalla: InfluxDB: inserte el uso de E/S de prueba para 400 XNUMX métricas únicas.
Arriba se muestra una captura de pantalla: TimescaleDB: inserte el uso de E/S de prueba para 400 XNUMX métricas únicas.
Ahora está claro que TimescaleDB está alcanzando su límite de E/S, por lo que no puede usar las 12 vCPU restantes.
4 millones de series temporales únicas
Las series temporales de 4M parecen un poco desafiantes. Pero nuestros competidores aprueban este examen con éxito. Resultados de referencia:
- VictoriaMetrics: 2,2 millones de puntos de datos por segundo; Uso de RAM: 6 GB; Tamaño final de datos en disco: 3 GB.
- InfluxDB: 330 puntos de datos por segundo; Uso de RAM: 20,5 GB; Tamaño final de datos en disco: 18,4 GB.
- TimescaleDB: 480 puntos de datos por segundo; Uso de RAM: 2,5 GB; Tamaño final de datos en disco: 52 GB.
El rendimiento de InfluxDB cayó de 1,2 millones de puntos de datos por segundo para una serie temporal de 400 a 330 puntos de datos por segundo para una serie temporal de 4 millones. Esta es una pérdida de rendimiento significativa en comparación con otros competidores. Miremos los gráficos de uso de la CPU para comprender la causa raíz de esta pérdida:
Arriba se muestra una captura de pantalla: VictoriaMetrics: uso de CPU durante la prueba de inserción para una serie temporal única de 4 millones.
Arriba se muestra una captura de pantalla: InfluxDB: uso de CPU durante la prueba de inserción para series temporales únicas de 4M.
Arriba se muestra una captura de pantalla: TimescaleDB: uso de CPU durante la prueba de inserción para una serie temporal única de 4M.
VictoriaMetrics utiliza casi toda la potencia de la unidad de procesamiento (CPU). La caída al final corresponde a las fusiones LSM restantes después de que se hayan insertado todos los datos.
InfluxDB usa solo 8 de 16 vCPU, mientras que TimsecaleDB usa 4 de 16 vCPU. ¿Qué tienen en común sus gráficas? Alta participación iowait, lo que nuevamente indica un cuello de botella de E/S.
TimescaleDB tiene una alta participación system. Suponemos que la alta potencia resultó en muchas llamadas al sistema o muchas .
Veamos los gráficos de rendimiento del disco:
Arriba se muestra una captura de pantalla: VictoriaMetrics: uso del ancho de banda del disco para insertar 4 millones de métricas únicas.
Arriba se muestra una captura de pantalla: InfluxDB: uso del ancho de banda del disco para insertar 4 millones de métricas únicas.
Arriba se muestra una captura de pantalla: TimescaleDB: uso del ancho de banda del disco para insertar 4 millones de métricas únicas.
VictoriaMetrics alcanzó un límite de 120 MB/s en el pico, mientras que la velocidad de escritura promedio fue de 40 MB/s. Es probable que se hayan realizado varias fusiones LSM pesadas durante el pico.
InfluxDB nuevamente logra un rendimiento de escritura promedio de 200 MB/s con picos de hasta 340 MB/s en un disco con un límite de escritura de 120 MB/s :)
TimescaleDB ya no está limitado por disco. Parece estar limitado por algo más relacionado con la alta proporción системной Carga de CPU.
Veamos los gráficos de uso de IO:
Arriba se muestra una captura de pantalla: VictoriaMetrics: uso de E/S durante la prueba de inserción para una serie temporal única de 4 millones.
Arriba se muestra una captura de pantalla: InfluxDB: uso de E/S durante la prueba de inserción para una serie temporal única de 4M.
Arriba se muestra una captura de pantalla: TimescaleDB: uso de E/S durante la prueba de inserción para series temporales únicas de 4M.
Los patrones de uso de IO reflejan los del ancho de banda del disco: InfluxDB tiene IO limitado, mientras que VictoriaMetrics y TimescaleDB tienen recursos de IO de repuesto.
40 millones de series temporales únicas
40 millones de series temporales únicas eran demasiado grandes para InfluxDB :)
Resultados de referencia:
- VictoriaMetrics: 1,7 millones de puntos de datos por segundo; Uso de RAM: 29 GB; Uso de espacio en disco: 17 GB.
- InfluxDB: No terminó porque requería más de 60 GB de RAM.
- TimescaleDB: 330 puntos de datos por segundo, uso de RAM: 2,5 GB; Uso de espacio en disco: 84 GB.
TimescaleDB muestra un uso de RAM excepcionalmente bajo y estable con 2,5 GB, lo mismo que para las métricas únicas de 4M y 400K.
VictoriaMetrics fue ampliando lentamente a una velocidad de 100 puntos de datos por segundo hasta que se procesaron los 40 millones de nombres de métricas etiquetados. Luego logró una tasa de inserción sostenida de 1,5 a 2,0 millones de puntos de datos por segundo, por lo que el resultado final fue de 1,7 millones de puntos de datos por segundo.
Los gráficos de series temporales únicas de 40 millones son similares a los gráficos de series temporales únicas de 4 millones, así que omitámoslos.
Hallazgos
- Los TSDB modernos son capaces de procesar inserciones de millones de series temporales únicas en un único servidor. En el próximo artículo, probaremos qué tan bien los TSDB realizan la selección en millones de series temporales únicas.
- La utilización insuficiente de la CPU suele indicar un cuello de botella de E/S. También puede indicar que el bloqueo es demasiado aproximado y que solo se pueden ejecutar unos pocos subprocesos a la vez.
- El cuello de botella de E/S existe, especialmente en el almacenamiento que no es SSD, como los dispositivos de bloques virtualizados de los proveedores de la nube.
- VictoriaMetrics proporciona la mejor optimización para almacenamiento de E/S lento y bajo. Proporciona la mejor velocidad y la mejor relación de compresión.
Descargar y pruébalo con tus datos. El binario estático correspondiente está disponible en .
Lea más sobre VictoriaMetrics en este .
Actualización: publicado con resultados reproducibles.
Actualización n.º 2: leer también .
Actualización #3: !
Tema del evento:
Fuente: habr.com