Ljutnja, cjenkanje i depresija pri radu sa InfluxDB

Ako koristite bazu podataka vremenskih serija (timeseries db, Wiki) kao glavni skladišni prostor za stranicu sa statistikom, onda umjesto rješavanja problema možete dobiti dosta glavobolje. Radim na projektu koji koristi takvu bazu podataka, a ponekad InfluxDB, o čemu će biti riječi, predstavlja generalno neočekivana iznenađenja.

odricanjeNapomena: Prikazani problemi su za InfluxDB 1.7.4.

Zašto vremenske serije?

Projekt je praćenje transakcija u različitim blockchainima i prikaz statistike. Konkretno, posmatramo emisiju i sagorevanje stabilnih kovanica (Wiki). Na osnovu ovih transakcija, potrebno je da napravite grafikone i prikažete pivot tabele.

Kada smo analizirali transakcije, pojavila se ideja: koristiti bazu podataka vremenskih serija InfluxDB kao glavno skladište. Transakcije su tačke u vremenu i dobro se uklapaju u model vremenske serije.

Funkcije agregacije su također izgledale vrlo zgodno - idealne su za obradu grafikona sa dugim periodom. Korisniku je potreban grafikon za godinu dana, a baza podataka sadrži skup podataka sa vremenskim okvirom od pet minuta. Besmisleno mu je slati svih sto hiljada poena - osim duge obrade, neće stati na ekran. Možete napisati vlastitu implementaciju povećanja vremenskog okvira ili koristiti funkcije agregacije ugrađene u Influx. Uz njihovu pomoć možete grupirati podatke po danima i poslati željenih 365 bodova.

Bilo je malo neugodno što se takve baze podataka obično koriste za prikupljanje metrike. Nadgledanje servera, iot uređaja, svega iz čega “teku” milioni tačaka oblika: [<vrijeme> - <metrička vrijednost>]. Ali ako baza podataka dobro radi s velikim protokom podataka, zašto bi onda mali volumen stvarao probleme? Sa ovom mišlju, uzeli su InfluxDB na posao.

Šta je još zgodno u InfluxDB-u

Pored spomenutih funkcija agregacije, postoji još jedna sjajna stvar - kontinuirani upiti (doc). Ovo je planer ugrađen u bazu podataka koji može obraditi podatke prema rasporedu. Na primjer, možete grupisati sve zapise za dan svaka 24 sata, izračunati prosjek i upisati jednu novu tačku u drugu tabelu bez pisanja vlastitih bicikla.

Takođe je politike zadržavanja (doc) - postavka za brisanje podataka nakon određenog perioda. Korisno je kada, na primjer, trebate pohraniti opterećenje CPU-a na tjedan dana s mjerenjima jednom u sekundi, ali na udaljenosti od nekoliko mjeseci takva preciznost nije potrebna. U takvoj situaciji možete učiniti sljedeće:

1. kreirajte kontinuirani upit za agregiranje podataka u drugu tabelu;
2. za prvu tabelu, definirajte politiku za brisanje metrike starije od te iste sedmice.

A Influx će smanjiti veličinu podataka i sam obrisati nepotrebne podatke.

O pohranjenim podacima

Nema mnogo podataka pohranjenih: oko 70 hiljada transakcija i još milion tačaka sa tržišnim informacijama. Dodavanje novih unosa - ne više od 3000 bodova dnevno. Postoje i metrike za stranicu, ali tamo ima malo podataka i, prema politici zadržavanja, čuvaju se ne duže od mjesec dana.

Problemi

Tokom razvoja i naknadnog testiranja servisa, sve više kritičnih problema nastajalo je u radu InfluxDB-a.

1. Brisanje podataka

Postoji niz podataka sa transakcijama:

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

Rezultat:

Šaljem naredbu za brisanje podataka:

DELETE FROM transactions WHERE symbol=’USDT’

Dalje tražim dobijanje već izbrisanih podataka. A Influx, umjesto praznog odgovora, vraća dio podataka koji treba ukloniti.

Pokušavam obrisati cijelu tabelu:

DROP MEASUREMENT transactions

Provjeravam brisanje tabele:

SHOW MEASUREMENTS

Ne vidim tabelu na listi, ali novi upit podataka i dalje vraća isti skup transakcija.

Kod mene se problem pojavio samo jednom, pošto je slučaj brisanja izolovan slučaj. Ali ovakvo ponašanje baze podataka očito se ne uklapa u okvir "ispravnog" rada. Kasnije je github pronađen otvoren ulaznica skoro godinu dana na ovu temu.

Kao rezultat toga, pomoglo je uklanjanje i naknadno obnavljanje cijele baze podataka.

2. Brojevi s pomičnim zarezom

Matematički proračuni koji koriste InfluxDB ugrađene funkcije daju greške preciznosti. Nije da je bilo nešto neobično, ali neprijatno.

U mom slučaju, podaci imaju finansijsku komponentu i želio bih da ih obradim sa velikom preciznošću. Zbog toga planiramo odustati od kontinuiranih upita.

3. Kontinuirani upiti se ne mogu prilagoditi različitim vremenskim zonama

Servis ima tabelu sa dnevnom statistikom transakcija. Za svaki dan morate grupisati sve transakcije za taj dan. Ali dan za svakog korisnika počinje u različito vrijeme, stoga je skup transakcija drugačiji. UTC je 37 varijanti smjene za koje želite agregirati podatke.

U InfluxDB, kada grupišete po vremenu, možete dodatno odrediti pomak, na primjer, za moskovsko vrijeme (UTC + 3):

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

Ali rezultat upita će biti netačan. Iz nekog razloga, podaci grupirani po danima počet će već 1677. (InfluxDB službeno podržava vremenski raspon od ove godine):

Da bi se zaobišao ovaj problem, usluga je privremeno prebačena na UTC + 0.

4. Performanse

Na Internetu postoji mnogo mjerila s poređenjem InfluxDB-a i drugih baza podataka. Na prvi pogled su izgledali kao marketinški materijali, ali sada mislim da u njima ima istine.

Dozvolite mi da vam ispričam svoj slučaj.

Usluga pruža API metodu koja vraća statistiku za posljednja XNUMX sata. Tokom izračunavanja, metoda tri puta ispituje bazu podataka sa sljedećim upitima:

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

Objašnjenje:

1. U prvom zahtjevu dobivamo najnovije bodove za svaki novčić s tržišnim podacima. Osam tačaka za osam novčića u mom slučaju.
2. Drugi zahtjev dobija jedan najnoviji poen.
3. Treći traži spisak transakcija za posljednja XNUMX sata, može ih biti nekoliko stotina.

Dozvolite mi da pojasnim da se u InfluxDB indeks automatski gradi po oznakama i vremenu, što ubrzava upite. U prvom zahtjevu simbol je oznaka.

Uradio sam stres test za ovu API metodu. Za 25 RPS-a, server je pokazao puno opterećenje od šest CPU-a:

U isto vrijeme, NodeJs proces uopće nije dao nikakvo opterećenje.

Brzina izvršenja je već smanjena za 7-10 RPS: ako je jedan klijent mogao dobiti odgovor za 200 ms, onda je 10 klijenata moralo čekati sekundu. 25 RPS - granica sa koje je stradala stabilnost, klijentima je vraćeno 500 grešaka.

Sa takvim performansama, nemoguće je koristiti Influx u našem projektu. Štaviše, u projektu gde praćenje treba da se demonstrira mnogim klijentima, mogu se pojaviti slični problemi i metrički server će biti preopterećen.

zaključak

Najvažniji zaključak iz stečenog iskustva je da nepoznatu tehnologiju ne možete uzeti u projekat bez dovoljne analize. Jednostavan pregled otvorenih tiketa na githubu mogao bi pružiti informacije da se InfluxDB ne uzima kao glavno skladište podataka.

InfluxDB je trebao dobro odgovarati zadacima mog projekta, ali kao što je praksa pokazala, ova baza podataka ne zadovoljava potrebe i dosta zabrlja.

Verziju 2.0.0-beta već možete pronaći u repozitorijumu projekta, ostaje da se nadamo da će biti značajnih poboljšanja u drugoj verziji. U međuvremenu ću proučiti TimescaleDB dokumentaciju.

izvor: www.habr.com