Viha, neuvottelu ja masennus InfluxDB:n kanssa työskennellessä

Jos käytät aikasarjatietokantaa (aikasarja db, wiki) koska se on tilastosivuston päävarasto, ongelman ratkaisemisen sijaan voit saada paljon päänsärkyä. Työskentelen projektin parissa, joka käyttää tällaista tietokantaa, ja joskus InfluxDB, josta keskustellaan, esitti yleensä odottamattomia yllätyksiä.

Vastuun kieltäminenHuomautus: Näytetyt ongelmat koskevat InfluxDB 1.7.4:ää.

Miksi aikasarjat?

Projektin tarkoituksena on seurata tapahtumia eri lohkoketjuissa ja näyttää tilastoja. Tarkastellaan erityisesti vakaiden kolikoiden päästöjä ja polttamista (wiki). Näiden tapahtumien perusteella sinun on rakennettava kaavioita ja näytettävä pivot-taulukoita.

Transaktiota analysoitaessa syntyi idea: käyttää InfluxDB-aikasarjatietokantaa päämuistina. Tapahtumat ovat ajankohtia ja sopivat hyvin aikasarjamalliin.

Aggregointitoiminnot näyttivät myös erittäin käteviltä - ne ovat ihanteellisia pitkän ajanjakson kaavioiden käsittelyyn. Käyttäjä tarvitsee kaavion vuodelle ja tietokanta sisältää viiden minuutin aikakehyksen datajoukon. On turhaa lähettää hänelle kaikki satatuhatta pistettä - pitkää käsittelyä lukuun ottamatta ne eivät mahdu näytölle. Voit kirjoittaa oman toteutuksen aikakehyksen pidentämiseksi tai käyttää Influxin sisäänrakennettuja yhdistämistoimintoja. Heidän avullaan voit ryhmitellä tiedot päiväkohtaisesti ja lähettää haluamasi 365 pistettä.

Oli hieman noloa, että tällaisia ​​tietokantoja yleensä käytetään mittareiden keräämiseen. Palvelimien, iot-laitteiden valvonta, kaikki mistä miljoonia pisteitä "virtaa" muodossa: [<aika> - <metrin arvo>]. Mutta jos tietokanta toimii hyvin suuren tietovirran kanssa, miksi pieni määrä aiheuttaa ongelmia? Tällä ajatuksella he ottivat InfluxDB:n töihin.

Mikä muu on kätevää InfluxDB:ssä

Mainittujen yhdistämistoimintojen lisäksi on toinen hieno asia - jatkuvat kyselyt (telakka). Tämä on tietokantaan sisäänrakennettu ajastin, joka voi käsitellä tietoja aikataulun mukaan. Voit esimerkiksi ryhmitellä kaikki päivän tietueet 24 tunnin välein, laskea keskiarvon ja kirjoittaa yhden uuden pisteen toiseen taulukkoon kirjoittamatta omia pyöriäsi.

on myös säilytyskäytännöt (telakka) - asetus tietojen poistamiseksi tietyn ajan kuluttua. Siitä on hyötyä, kun esimerkiksi prosessorin kuormitusta pitää tallentaa viikoksi mittauksin kerran sekunnissa, mutta parin kuukauden etäisyydellä tällaista tarkkuutta ei tarvita. Tällaisessa tilanteessa voit tehdä näin:

1. luoda jatkuva kysely tietojen yhdistämiseksi toiseen taulukkoon;
2. määritä ensimmäistä taulukkoa varten käytäntö samaa viikkoa vanhempien mittareiden poistamiseksi.

Ja Influx pienentää tietojen kokoa ja poistaa tarpeettomat tiedot itsestään.

Tietoja tallennetuista tiedoista

Tietoja ei tallenneta paljoa: noin 70 tuhatta tapahtumaa ja toinen miljoona pistettä markkinatiedoilla. Uusien merkintöjen lisääminen - enintään 3000 pistettä päivässä. Sivustolla on myös mittareita, mutta siellä on vähän dataa ja säilytyskäytännön mukaan niitä säilytetään enintään kuukauden ajan.

Ongelmat

Palvelun kehittämisen ja myöhemmän testauksen aikana InfluxDB:n toiminnassa ilmaantui yhä enemmän kriittisiä ongelmia.

1. Tietojen poistaminen

Tapahtumat sisältävät useita tietoja:

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

Результат:

Lähetän komennon tietojen poistamiseksi:

DELETE FROM transactions WHERE symbol=’USDT’

Lisäksi pyydän jo poistettujen tietojen saamista. Ja Influx palauttaa tyhjän vastauksen sijaan osan datasta, joka pitäisi poistaa.

Yritän poistaa koko taulukon:

DROP MEASUREMENT transactions

Tarkistan taulukon poistamisen:

SHOW MEASUREMENTS

En näe taulukkoa luettelossa, mutta uusi tietokysely palauttaa silti saman tapahtumajoukon.

Ongelma ilmeni minulle vain kerran, koska poistotapaus on yksittäinen tapaus. Mutta tämä tietokannan käyttäytyminen ei selvästikään sovi "oikean" työn kehykseen. Myöhemmin github löytyi auki lippu melkein vuoden vanha tästä aiheesta.

Tämän seurauksena koko tietokannan poistaminen ja myöhempi palauttaminen auttoi.

2. Liukulukuluvut

Matemaattiset laskelmat InfluxDB:n sisäänrakennetuilla funktioilla antavat tarkkuusvirheitä. Ei sillä, että se olisi ollut mitään epätavallista, mutta epämiellyttävää.

Minun tapauksessani tiedoissa on taloudellinen komponentti ja haluaisin käsitellä ne suurella tarkkuudella. Tämän vuoksi aiomme luopua jatkuvista tiedusteluista.

3. Jatkuvia kyselyitä ei voida sovittaa eri aikavyöhykkeille

Palvelussa on taulukko päivittäisistä tapahtumatilastoista. Jokaiselle päivälle on ryhmiteltävä kaikki kyseisen päivän tapahtumat. Mutta jokaisen käyttäjän päivä alkaa eri aikaan, joten tapahtumasarja on erilainen. UTC on 37 varianttia työvuorot, joiden tiedot haluat koota.

InfluxDB:ssä ajan mukaan ryhmiteltäessä voit lisäksi määrittää siirtymän esimerkiksi Moskovan ajalle (UTC + 3):

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

Mutta kyselyn tulos on virheellinen. Jostain syystä päiväkohtaisesti ryhmitelty data alkaa jo vuonna 1677 (InfluxDB tukee virallisesti aikajaksoa tästä vuodesta):

Tämän ongelman kiertämiseksi palvelu siirrettiin väliaikaisesti UTC + 0:aan.

4. Suorituskyky

Internetissä on monia vertailuja InfluxDB:n ja muiden tietokantojen vertailuun. Ensi silmäyksellä ne näyttivät markkinointimateriaalilta, mutta nyt luulen, että niissä on totuutta.

Anna minun kertoa sinulle tapaukseni.

Palvelu tarjoaa API-menetelmän, joka palauttaa tilastot viimeisen XNUMX tunnin ajalta. Laskelmien aikana menetelmä kysyy tietokannasta kolme kertaa seuraavilla kyselyillä:

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

selitys:

1. Ensimmäisessä pyynnössä saamme viimeisimmät pisteet jokaisesta kolikosta markkinatiedoilla. Minun tapauksessani kahdeksan pistettä kahdeksaa kolikkoa kohti.
2. Toinen pyyntö saa yhden uusimman pisteen.
3. Kolmas pyytää luetteloa tapahtumista viimeisen XNUMX tunnin ajalta, niitä voi olla useita satoja.

Haluan selventää, että InfluxDB:ssä indeksi rakennetaan automaattisesti tunnisteiden ja ajan mukaan, mikä nopeuttaa kyselyitä. Ensimmäisessä pyynnöstä symboli on tunniste.

Tein stressitestin tälle API-menetelmälle. 25 RPS:llä palvelin osoitti kuuden CPU:n täyden kuorman:

Samaan aikaan NodeJs-prosessi ei antanut lainkaan kuormaa.

Suoritusnopeus heikkeni jo 7-10 RPS:llä: jos yksi asiakas sai vastauksen 200 ms:ssa, niin 10 asiakasta joutui odottamaan sekunnin. 25 RPS - raja, josta vakaus kärsi, 500 virhettä palautettiin asiakkaille.

Tällaisella suorituskyvyllä on mahdotonta käyttää Influxia projektissamme. Lisäksi projektissa, jossa valvonta on esitettävä monille asiakkaille, samanlaisia ​​ongelmia saattaa ilmetä ja metriikkapalvelin ylikuormitetaan.

johtopäätös

Kokemuksen tärkein johtopäätös on, että tuntematonta tekniikkaa ei voi ottaa projektiin ilman riittävää analysointia. Yksinkertainen avointen lippujen seulonta githubissa voisi antaa tietoja siitä, ettei InfluxDB:tä oteta päätietovarastoon.

InfluxDB:n piti sopia hyvin projektini tehtäviin, mutta kuten käytäntö on osoittanut, tämä tietokanta ei täytä tarpeita ja sotkee ​​paljon.

Projektivarastosta löytyy jo versio 2.0.0-beta, on toivottavaa, että toiseen versioon tulee merkittäviä parannuksia. Sillä välin menen tutkimaan TimescaleDB-dokumentaatiota.

Lähde: will.com