Enuig, negociació i depressió quan es treballa amb InfluxDB

Si utilitzeu una base de dades de sèries temporals (timeseries db, wiki) com a emmagatzematge principal d'un lloc amb estadístiques, aleshores, en lloc de resoldre el problema, podeu tenir molts maldecaps. Estic treballant en un projecte que utilitza aquesta base de dades i, de vegades, InfluxDB, que es comentarà, presenta sorpreses generalment inesperades.

renúnciaNota: els problemes que es mostren són per a InfluxDB 1.7.4.

Per què sèries temporals?

El projecte consisteix a fer un seguiment de les transaccions en diverses cadenes de blocs i mostrar estadístiques. Concretament, ens fixem en l'emissió i la crema de monedes estables (wiki). A partir d'aquestes transaccions, heu de crear gràfics i mostrar taules dinàmiques.

En analitzar les transaccions, va sorgir una idea: utilitzar la base de dades de sèries temporals InfluxDB com a emmagatzematge principal. Les transaccions són punts en el temps i encaixen bé en el model de sèries temporals.

Les funcions d'agregació també semblaven molt convenients: són ideals per processar gràfics amb un període llarg. L'usuari necessita un gràfic durant un any i la base de dades conté un conjunt de dades amb un període de temps de cinc minuts. No té sentit enviar-li els cent mil punts, tret d'un processament llarg, no caben a la pantalla. Podeu escriure la vostra pròpia implementació per augmentar el període de temps o utilitzar les funcions d'agregació integrades a Influx. Amb la seva ajuda, podeu agrupar les dades per dia i enviar els 365 punts desitjats.

Era una mica vergonyós que aquestes bases de dades s'utilitzen normalment per recopilar mètriques. Monitorització de servidors, dispositius iot, tot des del qual “flueixen” milions de punts de la forma: [<temps> - <valor mètric>]. Però si la base de dades funciona bé amb un gran flux de dades, per què un petit volum hauria de causar problemes? Amb aquest pensament, van portar InfluxDB a treballar.

Què més és convenient a InfluxDB

A més de les funcions d'agregació esmentades, hi ha una altra gran cosa: consultes contínues (doctor). Es tracta d'un programador integrat a la base de dades que pot processar dades segons una programació. Per exemple, podeu agrupar tots els registres del dia cada 24 hores, calcular la mitjana i escriure un punt nou en una altra taula sense escriure les vostres pròpies bicicletes.

també hi ha una polítiques de retenció (doctor) - configuració per suprimir dades després d'un període determinat. És útil quan, per exemple, necessiteu emmagatzemar la càrrega a la CPU durant una setmana amb mesures una vegada per segon, però a una distància d'un parell de mesos, aquesta precisió no és necessària. En aquesta situació, podeu fer això:

1. crear una consulta contínua per agregar dades en una altra taula;
2. per a la primera taula, definiu una política per suprimir mètriques que siguin anteriors a la mateixa setmana.

I Influx reduirà la mida de les dades i esborrarà les dades innecessàries per si mateix.

Sobre les dades emmagatzemades

No s'emmagatzemen moltes dades: unes 70 mil transaccions i un altre milió de punts amb informació del mercat. Afegir noves entrades: no més de 3000 punts per dia. També hi ha mètriques per al lloc, però hi ha poques dades i, segons la política de retenció, s'emmagatzemen no més d'un mes.

Problemes

Durant el desenvolupament i les proves posteriors del servei, cada cop van sorgir més problemes crítics en el funcionament d'InfluxDB.

1. Eliminació de dades

Hi ha una sèrie de dades amb transaccions:

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

Resultat:

Envio una ordre per eliminar dades:

DELETE FROM transactions WHERE symbol=’USDT’

A més, sol·licito l'obtenció de dades ja suprimides. I Influx, en lloc d'una resposta buida, retorna una dada que s'hauria d'eliminar.

Estic intentant esborrar tota la taula:

DROP MEASUREMENT transactions

Comproveu l'eliminació de la taula:

SHOW MEASUREMENTS

No veig la taula a la llista, però la nova consulta de dades encara retorna el mateix conjunt de transaccions.

El problema em va sorgir només una vegada, ja que el cas d'eliminació és un cas aïllat. Però aquest comportament de la base de dades clarament no encaixa en el marc del treball "correcte". Més tard, github es va trobar obert bitllet gairebé un any sobre aquest tema.

Com a resultat, l'eliminació i la posterior restauració de tota la base de dades va ajudar.

2. Nombres de coma flotant

Els càlculs matemàtics que utilitzen les funcions integrades d'InfluxDB donen errors de precisió. No és que fos res inusual, sinó desagradable.

En el meu cas, les dades tenen un component financer i m'agradaria processar-les amb gran precisió. Per això, tenim previst abandonar les consultes contínues.

3. Les consultes contínues no es poden adaptar a diferents zones horàries

El servei té una taula amb estadístiques diàries de transaccions. Per a cada dia, heu d'agrupar totes les transaccions d'aquest dia. Però el dia per a cada usuari començarà en una hora diferent, per tant, el conjunt de transaccions és diferent. UTC és 37 variants torns per als quals voleu agregar dades.

A InfluxDB, en agrupar per hora, també podeu especificar un canvi, per exemple, per a l'hora de Moscou (UTC + 3):

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

Però el resultat de la consulta serà incorrecte. Per alguna raó, les dades agrupades per dia començaran fins al 1677 (InfluxDB admet oficialment un període de temps a partir d'aquest any):

Per evitar aquest problema, el servei es va transferir temporalment a UTC + 0.

4. Rendiment

Hi ha molts punts de referència a Internet amb comparacions d'InfluxDB i altres bases de dades. A primera vista, semblaven materials de màrqueting, però ara crec que hi ha una mica de veritat.

Deixa'm explicar-te el meu cas.

El servei proporciona un mètode API que retorna estadístiques de les últimes XNUMX hores. Durant els càlculs, el mètode consulta la base de dades tres vegades amb les consultes següents:

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ó:

1. A la primera sol·licitud, obtenim els últims punts per a cada moneda amb dades de mercat. Vuit punts per vuit monedes en el meu cas.
2. La segona sol·licitud obté un punt més nou.
3. El tercer sol·licita una llista de transaccions de les últimes XNUMX hores, poden haver-hi diversos centenars.

Permeteu-me aclarir que a InfluxDB, un índex es construeix automàticament per etiquetes i per temps, cosa que accelera les consultes. En la primera petició símbol és una etiqueta.

Vaig fer una prova d'estrès per a aquest mètode API. Per a 25 RPS, el servidor va mostrar una càrrega completa de sis CPU:

Al mateix temps, el procés NodeJs no donava cap càrrega.

La velocitat d'execució ja es va degradar en 7-10 RPS: si un client podia rebre una resposta en 200 ms, llavors 10 clients havien d'esperar un segon. 25 RPS: la frontera de la qual va patir l'estabilitat, es van retornar 500 errors als clients.

Amb aquest rendiment, és impossible utilitzar Influx al nostre projecte. A més, en un projecte on s'ha de demostrar la supervisió a molts clients, poden aparèixer problemes similars i el servidor de mètriques es sobrecarregarà.

Sortida

La conclusió més important de l'experiència adquirida és que no es pot incorporar una tecnologia desconeguda a un projecte sense una anàlisi suficient. Una simple selecció de bitllets oberts a github podria proporcionar informació per no prendre InfluxDB com a magatzem de dades principal.

Se suposava que InfluxDB s'adaptava bé a les tasques del meu projecte, però, com ha demostrat la pràctica, aquesta base de dades no satisfà les necessitats i estropea molt.

Ja podeu trobar la versió 2.0.0-beta al repositori del projecte, cal esperar que hi hagi millores importants en la segona versió. Mentrestant, aniré a estudiar la documentació de TimescaleDB.

Font: www.habr.com