Furia, negocierea și depresia atunci când lucrați cu InfluxDB

Dacă utilizați o bază de date cu serii temporale (timeseries db, Wiki) ca stocare principală pentru un site cu statistici, atunci în loc să rezolvi problema poți avea o mulțime de bătăi de cap. Lucrez la un proiect care folosește o astfel de bază de date, iar uneori InfluxDB, despre care se va discuta, a prezentat surprize complet neașteptate.

Declinare a responsabilităţii: Problemele enumerate se aplică pentru versiunea InfluxDB 1.7.4.

De ce serii de timp?

Proiectul este de a urmări tranzacțiile pe diverse blockchain și de a afișa statistici. Mai exact, ne uităm la emisia și arderea monedelor stabile (Wiki). Pe baza acestor tranzacții, trebuie să construiți grafice și să afișați tabele rezumative.

În timpul analizei tranzacțiilor, a apărut o idee: utilizarea bazei de date a seriei temporale InfluxDB ca stocare principală. Tranzacțiile sunt momente în timp și se încadrează bine în modelul seriei temporale.

Funcțiile de agregare păreau, de asemenea, foarte convenabile - ideale pentru procesarea diagramelor cu o perioadă lungă. Utilizatorul are nevoie de o diagramă pentru un an, iar baza de date conține un set de date cu un interval de timp de cinci minute. Nu are rost să-i trimiți toate cele o sută de mii de puncte - în afară de procesarea lungă, nici măcar nu vor încăpea pe ecran. Puteți scrie propria implementare a creșterii intervalului de timp sau puteți utiliza funcțiile de agregare încorporate în Influx. Cu ajutorul lor, puteți grupa datele pe zi și puteți trimite cele 365 de puncte necesare.

A fost puțin confuz faptul că astfel de baze de date sunt utilizate de obicei în scopul colectării de valori. Monitorizarea serverelor, a dispozitivelor iot, a tot ceea ce „curg” milioane de puncte de forma: [<timp> - <valoare metrică>]. Dar dacă baza de date funcționează bine cu un flux mare de date, atunci de ce un volum mic ar cauza probleme? Având în vedere acest lucru, am luat InfluxDB să lucreze.

Ce altceva este convenabil în InfluxDB

În afară de funcțiile de agregare menționate, există un alt lucru grozav - interogări continue (medic). Acesta este un planificator încorporat în baza de date care poate procesa date într-un program. De exemplu, la fiecare 24 de ore puteți grupa toate înregistrările zilei, puteți calcula media și puteți înregistra un punct nou într-un alt tabel fără a vă scrie propriile biciclete.

De asemenea, au politici de reținere (medic)—setarea ștergerii datelor după o anumită perioadă. Este util atunci când, de exemplu, trebuie să stocați sarcina procesorului timp de o săptămână cu măsurători o dată pe secundă, dar pe o distanță de câteva luni nu este necesară o astfel de precizie. Într-o astfel de situație, puteți face acest lucru:

1. creați o interogare continuă pentru a agrega datele într-un alt tabel;
2. pentru primul tabel, definiți o politică pentru ștergerea valorilor care sunt mai vechi decât aceeași săptămână.

Și Influx va reduce în mod independent dimensiunea datelor și va șterge lucrurile inutile.

Despre datele stocate

Nu sunt stocate multe date: aproximativ 70 de mii de tranzacții și încă un milion de puncte cu informații de piață. Adăugarea de noi intrări - nu mai mult de 3000 de puncte pe zi. Există și metrici pentru site, dar există puține date acolo și, conform politicii de reținere, acestea sunt stocate nu mai mult de o lună.

Probleme

În timpul dezvoltării și testării ulterioare a serviciului, au apărut tot mai multe probleme critice în funcționarea InfluxDB.

1. Ștergerea datelor

Există o serie de date cu tranzacții:

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

Rezultat:

Trimit o comandă de ștergere a datelor:

DELETE FROM transactions WHERE symbol=’USDT’

În continuare fac o solicitare pentru a primi datele deja șterse. Și în loc de un răspuns gol, Influx returnează o parte din datele care ar trebui șterse.

Încerc să șterg întregul tabel:

DROP MEASUREMENT transactions

Verific ștergerea tabelului:

SHOW MEASUREMENTS

Nu văd tabelul în listă, dar o nouă interogare de date returnează în continuare același set de tranzacții.

Problema mi-a apărut o singură dată, deoarece cazul de ștergere a fost un caz izolat. Dar acest comportament al bazei de date în mod clar nu se încadrează în cadrul operațiunii „corecte”. Mai târziu l-am găsit deschis pe github bilet acum aproape un an pe acest subiect.

Ca rezultat, ștergerea și apoi restaurarea întregii baze de date a ajutat.

2. Numere în virgulă mobilă

Calculele matematice atunci când se utilizează funcții încorporate în InfluxDB au erori de precizie. Nu că este ceva neobișnuit, dar este neplăcut.

În cazul meu, datele au o componentă financiară și aș dori să le procesez cu mare acuratețe. Din această cauză, intenționăm să renunțăm la interogările continue.

3. Interogările continue nu pot fi adaptate la diferite fusuri orare

Serviciul are un tabel cu statistici zilnice ale tranzacțiilor. Pentru fiecare zi, trebuie să grupați toate tranzacțiile pentru ziua respectivă. Dar ziua fiecărui utilizator va începe la un moment diferit și, prin urmare, setul de tranzacții va fi diferit. După UTC da 37 variante ture pentru care trebuie să agregați date.

În InfluxDB, atunci când grupați după oră, puteți specifica în plus o schimbare, de exemplu pentru ora Moscovei (UTC+3):

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

Dar rezultatul interogării va fi incorect. Din anumite motive, datele grupate pe zi vor începe până în 1677 (InfluxDB acceptă oficial un interval de timp din acest an):

Pentru a rezolva această problemă, am trecut temporar serviciul la UTC+0.

4. Performanță

Există multe benchmark-uri pe Internet care compară InfluxDB și alte baze de date. La prima vedere, păreau materiale de marketing, dar acum cred că există ceva adevăr în ele.

Vă spun cazul meu.

Serviciul oferă o metodă API care returnează statistici pentru ultima zi. La efectuarea calculelor, metoda interogează baza de date de trei ori cu următoarele interogări:

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

Explicaţie:

1. În prima solicitare, obținem ultimele puncte pentru fiecare monedă cu date de piață. Opt puncte pentru opt monede în cazul meu.
2. A doua cerere primește unul dintre cele mai noi puncte.
3. Al treilea solicită o listă de tranzacții din ultimele XNUMX de ore; pot fi câteva sute de ele.

Permiteți-mi să clarific că InfluxDB construiește automat un index bazat pe etichete și timp, ceea ce accelerează interogările. La prima cerere simbol este o etichetă.

Am efectuat un test de stres pe această metodă API. Pentru 25 RPS, serverul a demonstrat o încărcare completă de șase procesoare:

În același timp, procesul NodeJs nu a furnizat deloc încărcare.

Viteza de execuție a scăzut deja cu 7-10 RPS: dacă un client putea primi un răspuns în 200 ms, atunci 10 clienți trebuiau să aștepte o secundă. 25 RPS este limita la care a suferit stabilitatea; 500 de erori au fost returnate clienților.

Cu o astfel de performanță este imposibil să folosim Influx în proiectul nostru. Mai mult: într-un proiect în care monitorizarea trebuie demonstrată pentru mulți clienți, pot apărea probleme similare și serverul de metrici va fi supraîncărcat.

Producție

Cea mai importantă concluzie din experiența acumulată este că nu puteți introduce o tehnologie necunoscută într-un proiect fără o analiză suficientă. O simplă examinare a problemelor deschise pe github ar putea oferi informații pentru a evita alegerea InfluxDB ca magazin de date principal.

InfluxDB ar fi trebuit să fie potrivit pentru sarcinile proiectului meu, dar după cum a arătat practica, această bază de date nu răspunde nevoilor și are o mulțime de erori.

Puteți găsi deja versiunea 2.0.0-beta în depozitul de proiect; putem doar să sperăm că a doua versiune va avea îmbunătățiri semnificative. Între timp, voi merge să studiez documentația TimescaleDB.

Sursa: www.habr.com