Ljutnja, pregovaranje i depresija pri radu s InfluxDB-om

Ako koristite bazu podataka vremenskih serija (timeseries db, wiki) kao glavna pohrana za stranicu sa statistikom, tada umjesto rješenja problema možete dobiti puno glavobolja. Radim na projektu koji koristi takvu bazu podataka, a ponekad je InfluxDB, o kojem će biti riječi, donosio potpuno neočekivana iznenađenja.

Izjava o odricanju od odgovornosti: Navedeni problemi odnose se na InfluxDB verziju 1.7.4.

Zašto vremenski niz?

Projekt je praćenje transakcija na različitim lancima blokova i prikaz statistike. Konkretno, promatramo emisiju i spaljivanje stabilnih kovanica (wiki). Na temelju tih transakcija trebate izgraditi grafikone i prikazati sažete tablice.

Tijekom analize transakcija došla je ideja: koristiti InfluxDB bazu vremenskih serija kao glavnu pohranu. Transakcije su točke u vremenu i dobro se uklapaju u model vremenske serije.

Funkcije agregacije također su izgledale vrlo zgodno - idealno za obradu grafikona s dugim razdobljem. Korisniku je potreban grafikon za godinu dana, a baza podataka sadrži skup podataka s vremenskim okvirom od pet minuta. Besmisleno mu je slati svih sto tisuća točaka - osim duge obrade, neće stati ni 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 potrebnih 365 bodova.

Bilo je malo zbunjujuće da se takve baze podataka obično koriste u svrhu prikupljanja metrike. Praćenje servera, iot uređaja, svega iz čega “teku” milijuni točaka oblika: [ - ]. Ali ako baza podataka dobro radi s velikim protokom podataka, zašto bi mali volumen uzrokovao probleme? Imajući ovo na umu, počeli smo raditi InfluxDB.

Što je još zgodno u InfluxDB-u

Osim spomenutih agregacijskih funkcija, postoji još jedna sjajna stvar - kontinuirani upiti (doc). Ovo je planer ugrađen u bazu podataka koji može obrađivati ​​podatke prema rasporedu. Na primjer, svaka 24 sata možete grupirati sve rekorde za taj dan, izračunati prosjek i zabilježiti jedan novi bod u drugu tablicu bez pisanja vlastitih bicikala.

Postoji također politike zadržavanja (doc)—podešavanje brisanja podataka nakon određenog razdoblja. Korisno je kada, na primjer, trebate pohraniti opterećenje CPU-a tjedan dana s mjerenjima jednom u sekundi, ali na udaljenosti od nekoliko mjeseci takva točnost nije potrebna. U takvoj situaciji možete učiniti sljedeće:

1. stvoriti kontinuirani upit za prikupljanje podataka u drugu tablicu;
2. za prvu tablicu definirajte politiku za brisanje metrika koje su starije od tog istog tjedna.

A Influx će samostalno smanjiti veličinu podataka i izbrisati nepotrebne stvari.

O pohranjenim podacima

Ne pohranjuje se puno podataka: oko 70 tisuća transakcija i još milijun točaka s informacijama o tržištu. Dodavanje novih unosa - ne više od 3000 bodova dnevno. Postoje i metrike za web mjesto, ali tamo ima malo podataka i, prema politici zadržavanja, oni se pohranjuju najviše mjesec dana.

Problemi

Tijekom razvoja i naknadnog testiranja servisa javljalo se sve više kritičnih problema u radu InfluxDB-a.

1. Brisanje podataka

Postoji niz podataka s transakcijama:

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

Rezultat:

Šaljem naredbu za brisanje podataka:

DELETE FROM transactions WHERE symbol=’USDT’

Zatim postavljam zahtjev za primanje već izbrisanih podataka. I umjesto praznog odgovora, Influx vraća dio podataka koje treba izbrisati.

Pokušavam obrisati cijelu tablicu:

DROP MEASUREMENT transactions

Provjeravam brisanje tablice:

SHOW MEASUREMENTS

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

Problem mi se pojavio samo jednom, budući da je slučaj brisanja bio izoliran slučaj. Ali ovakvo ponašanje baze podataka očito se ne uklapa u okvir "ispravnog" rada. Kasnije sam ga našao otvoren na githubu ulaznica prije skoro godinu dana na ovu temu.

Kao rezultat toga, pomoglo je brisanje i vraćanje cijele baze podataka.

2. Brojevi s pomičnim zarezom

Matematički izračuni kada se koriste ugrađene funkcije u InfluxDB-u imaju pogreške u točnosti. Nije da je to nešto neobično, ali je neugodno.

U mom slučaju podaci imaju financijsku komponentu i želio bih ih obraditi s visokom točnošću. Zbog toga planiramo napustiti kontinuirane upite.

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

Usluga ima tablicu s dnevnom statistikom transakcija. Za svaki dan morate grupirati sve transakcije za taj dan. Ali dan svakog korisnika započet će u različito vrijeme, pa će stoga skup transakcija biti drugačiji. Po UTC da 37 varijanti smjene za koje trebate agregirati podatke.

U InfluxDB-u, prilikom grupiranja 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 bit će netočan. Iz nekog razloga, podaci grupirani po danima počet će sve do 1677. (InfluxDB službeno podržava vremenski raspon od ove godine):

Kako bismo zaobišli ovaj problem, privremeno smo prebacili uslugu na UTC+0.

4. Izvedba

Na internetu postoji mnogo mjerila koja uspoređuju InfluxDB i druge baze podataka. Na prvi pogled izgledali su kao marketinški materijali, ali sada mislim da u njima ima istine.

Ispričat ću vam svoj slučaj.

Usluga nudi API metodu koja vraća statistiku za zadnji dan. Prilikom izvođenja izračuna, metoda ispituje bazu podataka tri puta 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

Obrazloženje:

1. U prvom zahtjevu dobivamo zadnje bodove za svaki coin s podacima o tržištu. Osam bodova za osam novčića u mom slučaju.
2. Drugi zahtjev dobiva jedan od najnovijih bodova.
3. Treći traži popis transakcija za zadnja XNUMX sata, može ih biti nekoliko stotina.

Dopustite mi da pojasnim da InfluxDB automatski gradi indeks na temelju oznaka i vremena, što ubrzava upite. U prvom zahtjevu simbol je oznaka.

Pokrenuo sam test otpornosti na stres na ovoj API metodi. Za 25 RPS, poslužitelj je pokazao puno opterećenje od šest CPU-a:

U isto vrijeme, proces NodeJs nije pružio nikakvo opterećenje.

Brzina izvršenja već je smanjena za 7-10 RPS: ako je jedan klijent mogao dobiti odgovor za 200 ms, tada je 10 klijenata moralo čekati sekundu. 25 RPS je granica na kojoj je stabilnost patila; 500 pogrešaka je vraćeno klijentima.

S takvim performansama nemoguće je koristiti Influx u našem projektu. Štoviše: u projektu gdje se nadzor treba demonstrirati mnogim klijentima, mogu se pojaviti slični problemi i poslužitelj metrike bit će preopterećen.

Izlaz

Najvažniji zaključak iz stečenog iskustva je da nepoznatu tehnologiju ne možete uvesti u projekt bez dovoljne analize. Jednostavan pregled otvorenih problema na githubu mogao bi pružiti informacije za izbjegavanje odabira InfluxDB-a kao glavne pohrane podataka.

InfluxDB je trebao dobro odgovarati zadacima mog projekta, ali kao što je praksa pokazala, ova baza podataka ne zadovoljava potrebe i ima puno grešaka.

Verziju 2.0.0-beta već možete pronaći u repozitoriju projekta; možemo se samo nadati da će druga verzija imati značajna poboljšanja. U međuvremenu ću ići proučiti TimescaleDB dokumentaciju.

Izvor: www.habr.com