Ira, negociación y depresión cuando se trabaja con InfluxDB

Si utiliza una base de datos de series temporales (timeseries db, wiki) como el almacenamiento principal de un sitio con estadísticas, entonces, en lugar de resolver el problema, puede tener muchos dolores de cabeza. Estoy trabajando en un proyecto que usa una base de datos de este tipo y, a veces, InfluxDB, que se discutirá, generalmente presenta sorpresas inesperadas.

ObservaciónNota: Los problemas que se muestran son para InfluxDB 1.7.4.

¿Por qué series de tiempo?

El proyecto es rastrear transacciones en varias cadenas de bloques y mostrar estadísticas. Específicamente, nos fijamos en la emisión y quema de monedas estables (wiki). En función de estas transacciones, debe crear gráficos y mostrar tablas dinámicas.

Al analizar las transacciones, surgió una idea: utilizar la base de datos de series temporales de InfluxDB como almacenamiento principal. Las transacciones son puntos en el tiempo y encajan bien en el modelo de serie temporal.

Las funciones de agregación también parecían muy convenientes: son ideales para procesar gráficos con un período largo. El usuario necesita un gráfico para un año y la base de datos contiene un conjunto de datos con un marco de tiempo de cinco minutos. No tiene sentido enviarle los cien mil puntos; excepto por un procesamiento largo, no caben en la pantalla. Puede escribir su propia implementación para aumentar el período de tiempo o usar las funciones de agregación integradas en Influx. Con su ayuda, puede agrupar datos por día y enviar los 365 puntos deseados.

Fue un poco vergonzoso que tales bases de datos se usen generalmente para recopilar métricas. Monitoreo de servidores, dispositivos iot, todo desde donde “fluyen” millones de puntos de la forma: [<tiempo> - <valor métrico>]. Pero si la base de datos funciona bien con un gran flujo de datos, ¿por qué un volumen pequeño debería causar problemas? Con este pensamiento, llevaron InfluxDB al trabajo.

Qué más conviene en InfluxDB

Además de las funciones de agregación mencionadas, hay otra gran cosa: consultas continuas (doc). Este es un planificador integrado en la base de datos que puede procesar datos en un horario. Por ejemplo, puede agrupar todos los registros del día cada 24 horas, calcular el promedio y escribir un nuevo punto en otra tabla sin escribir sus propias bicicletas.

también hay una políticas de retención (doc) - configuración para eliminar datos después de un período determinado. Es útil cuando, por ejemplo, necesita almacenar la carga en la CPU durante una semana con mediciones una vez por segundo, pero a una distancia de un par de meses, no se necesita tal precisión. En tal situación, puede hacer esto:

1. crear una consulta continua para agregar datos en otra tabla;
2. para la primera tabla, defina una política para eliminar métricas que sean anteriores a esa misma semana.

E Influx reducirá el tamaño de los datos y eliminará los datos innecesarios por sí solo.

Acerca de los datos almacenados

No se almacenan muchos datos: unas 70 mil transacciones y otro millón de puntos con información de mercado. Agregar nuevas entradas: no más de 3000 puntos por día. También hay métricas para el sitio, pero hay pocos datos allí y, de acuerdo con la política de retención, se almacenan por no más de un mes.

Problemas

Durante el desarrollo y posterior prueba del servicio, surgieron cada vez más problemas críticos en el funcionamiento de InfluxDB.

1. Eliminación de datos

Hay una serie de datos con transacciones:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Resultado:

Envío un comando para eliminar datos:

DELETE FROM transactions WHERE symbol=’USDT’

Además, solicito la obtención de datos ya eliminados. E Influx, en lugar de una respuesta vacía, devuelve un dato que debe eliminarse.

Estoy tratando de eliminar toda la tabla:

DROP MEASUREMENT transactions

Compruebo la eliminación de la tabla:

SHOW MEASUREMENTS

No veo la tabla en la lista, pero la nueva consulta de datos sigue devolviendo el mismo conjunto de transacciones.

El problema se me presentó solo una vez, ya que el caso de borrado es un caso aislado. Pero este comportamiento de la base de datos claramente no encaja en el marco del trabajo "correcto". Más tarde en github encontrado abierto billete casi un año en este tema.

Como resultado, ayudó la eliminación y posterior restauración de toda la base de datos.

2. Números de punto flotante

Los cálculos matemáticos que utilizan las funciones integradas de InfluxDB dan errores de precisión. No es que fuera algo inusual, sino desagradable.

En mi caso, los datos tienen un componente financiero y me gustaría procesarlos con mucha precisión. Debido a esto, planeamos abandonar las consultas continuas.

3. Las consultas continuas no se pueden adaptar a diferentes zonas horarias

El servicio cuenta con una tabla con estadísticas diarias de transacciones. Para cada día, debe agrupar todas las transacciones de ese día. Pero el día para cada usuario comenzará a una hora diferente, por lo tanto, el conjunto de transacciones es diferente. UTC es Opciones de 37 turnos para los que desea agregar datos.

En InfluxDB, al agrupar por hora, también puede especificar un turno, por ejemplo, para la hora de Moscú (UTC + 3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Pero el resultado de la consulta será incorrecto. Por alguna razón, los datos agrupados por día comenzarán en 1677 (InfluxDB admite oficialmente un período de tiempo a partir de este año):

Para evitar este problema, el servicio se transfirió temporalmente a UTC + 0.

4. Rendimiento

Hay muchos puntos de referencia en Internet con comparaciones de InfluxDB y otras bases de datos. A primera vista, parecían materiales de marketing, pero ahora creo que hay algo de verdad en ellos.

Déjame contarte mi caso.

El servicio proporciona un método API que devuelve estadísticas de las últimas XNUMX horas. Durante los cálculos, el método consulta la base de datos tres veces con las siguientes consultas:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

Explicación

1. En la primera solicitud, obtenemos los últimos puntos de cada moneda con datos de mercado. Ocho puntos por ocho monedas en mi caso.
2. La segunda solicitud obtiene un punto más nuevo.
3. El tercero solicita una lista de transacciones de las últimas XNUMX horas, puede haber varios cientos de ellas.

Permítanme aclarar que en InfluxDB, un índice se construye automáticamente por etiquetas y por tiempo, lo que agiliza las consultas. En la primera solicitud símbolo es una etiqueta

Hice una prueba de estrés para este método API. Para 25 RPS, el servidor mostró una carga completa de seis CPU:

Al mismo tiempo, el proceso de NodeJs no generó ninguna carga.

La velocidad de ejecución ya se degradó entre 7 y 10 RPS: si un cliente podía recibir una respuesta en 200 ms, 10 clientes tenían que esperar un segundo. 25 RPS: el borde del que sufrió la estabilidad, se devolvieron 500 errores a los clientes.

Con tal rendimiento, es imposible usar Influx en nuestro proyecto. Además, en un proyecto donde se debe demostrar el monitoreo a muchos clientes, pueden aparecer problemas similares y el servidor de métricas se sobrecargará.

conclusión

La conclusión más importante de la experiencia adquirida es que no se puede llevar una tecnología desconocida a un proyecto sin un análisis suficiente. Una simple selección de tickets abiertos en github podría proporcionar información para no tomar InfluxDB como el almacén de datos principal.

Se suponía que InfluxDB se adaptaría bien a las tareas de mi proyecto, pero como ha demostrado la práctica, esta base de datos no satisface las necesidades y se estropea mucho.

Ya puedes encontrar la versión 2.0.0-beta en el repositorio del proyecto, queda esperar que haya mejoras significativas en la segunda versión. Mientras tanto, iré a estudiar la documentación de TimescaleDB.

Fuente: habr.com