Woede, bedinging en depressie wanneer jy met InfluxDB werk

As jy 'n tydreeksdatabasis gebruik (tydreeks db, wiki) as die hoofberging vir 'n webwerf met statistieke, dan kan jy in plaas daarvan om die probleem op te los, baie hoofpyn kry. Ek werk aan 'n projek wat so 'n databasis gebruik, en soms het InfluxDB, wat bespreek sal word, oor die algemeen onverwagte verrassings aangebied.

VrywaringLet wel: Die kwessies wat gewys word, is vir InfluxDB 1.7.4.

Hoekom tydreekse?

Die projek is om transaksies in verskeie blokkettings op te spoor en statistieke te vertoon. Spesifiek kyk ons ​​na die vrystelling en verbranding van stabiele munte (wiki). Op grond van hierdie transaksies moet jy grafieke bou en spilpunttabelle wys.

By die ontleding van transaksies het 'n idee ontstaan: om die InfluxDB-tydreeksdatabasis as die hoofberging te gebruik. Transaksies is tydstip en pas goed in die tydreeksmodel.

Die samevoegingsfunksies het ook baie gerieflik gelyk - hulle is ideaal vir die verwerking van kaarte met 'n lang tydperk. Die gebruiker benodig 'n grafiek vir 'n jaar, en die databasis bevat 'n datastel met 'n tydraamwerk van vyf minute. Dit is sinloos om al honderdduisend punte vir hom te stuur - behalwe vir 'n lang verwerking, sal dit nie op die skerm pas nie. Jy kan jou eie implementering skryf om die tydraamwerk te verhoog, of die samevoegingsfunksies wat in Influx ingebou is, gebruik. Met hul hulp kan jy data per dag groepeer en die verlangde 365 punte stuur.

Dit was 'n bietjie verleentheid dat sulke databasisse gewoonlik gebruik word om metrieke in te samel. Monitering van bedieners, iot-toestelle, alles waaruit miljoene punte van die vorm “vloei”: [<tyd> - <metriese waarde>]. Maar as die databasis goed werk met 'n groot datastroom, hoekom moet 'n klein volume dan probleme veroorsaak? Met hierdie gedagte het hulle InfluxDB werk toe geneem.

Wat anders is gerieflik in InfluxDB

Benewens die genoemde samevoegingsfunksies, is daar nog 'n wonderlike ding - deurlopende navrae (doc). Dit is 'n skeduleerder wat in die databasis ingebou is wat data op 'n skedule kan verwerk. Byvoorbeeld, jy kan elke 24 uur al die rekords vir die dag groepeer, die gemiddelde bereken en een nuwe punt na 'n ander tabel skryf sonder om jou eie fietse te skryf.

Daar is ook retensiebeleide (doc) - instelling vir die verwydering van data na 'n sekere tydperk. Dit is nuttig wanneer u byvoorbeeld die las op die SVE vir 'n week moet stoor met metings een keer per sekonde, maar op 'n afstand van 'n paar maande is sulke akkuraatheid nie nodig nie. In so 'n situasie kan jy dit doen:

1. skep 'n deurlopende navraag om data in 'n ander tabel saam te voeg;
2. vir die eerste tabel, definieer 'n beleid vir die uitvee van maatstawwe wat ouer as dieselfde week is.

En Influx sal die grootte van die data verminder en onnodige data op sy eie uitvee.

Oor gestoorde data

Nie veel data word gestoor nie: ongeveer 70 duisend transaksies en nog 'n miljoen punte met markinligting. Voeg nuwe inskrywings by - nie meer as 3000 punte per dag nie. Daar is ook maatstawwe vir die webwerf, maar daar is min data daar en volgens die retensiebeleid word dit vir nie meer as 'n maand gestoor nie.

probleme

Tydens die ontwikkeling en daaropvolgende toetsing van die diens het al hoe meer kritieke probleme in die werking van InfluxDB ontstaan.

1. Die verwydering van data

Daar is 'n reeks data met transaksies:

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

Gevolg:

Ek stuur 'n opdrag om data uit te vee:

DELETE FROM transactions WHERE symbol=’USDT’

Verder versoek ek vir die verkryging van reeds geskrap data. En Influx, in plaas van 'n leë antwoord, gee 'n stukkie data terug wat verwyder moet word.

Ek probeer die hele tabel uitvee:

DROP MEASUREMENT transactions

Ek kontroleer die verwydering van die tabel:

SHOW MEASUREMENTS

Ek sien nie die tabel in die lys nie, maar die nuwe data-navraag gee steeds dieselfde stel transaksies terug.

Die probleem het net een keer vir my ontstaan, aangesien die skrap-geval 'n geïsoleerde geval is. Maar hierdie gedrag van die databasis pas duidelik nie in die raamwerk van "korrekte" werk nie. Later op github gevind oop kaartjie amper 'n jaar oud oor hierdie onderwerp.

As gevolg hiervan het die verwydering en daaropvolgende herstel van die hele databasis gehelp.

2. Wisselpuntgetalle

Wiskundige berekeninge wat InfluxDB se ingeboude funksies gebruik, gee presisiefoute. Nie dat dit iets ongewoons was nie, maar onaangenaam.

In my geval het die data 'n finansiële komponent en ek wil dit graag met hoë akkuraatheid verwerk. As gevolg hiervan beplan ons om deurlopende navrae te laat vaar.

3. Deurlopende navrae kan nie by verskillende tydsones aangepas word nie

Die diens het 'n tabel met daaglikse transaksiestatistieke. Vir elke dag moet jy alle transaksies vir daardie dag groepeer. Maar die dag vir elke gebruiker sal op 'n ander tyd begin, daarom is die stel transaksies anders. UTC is 37 variante skofte waarvoor jy data wil saamvoeg.

In InfluxDB, wanneer u volgens tyd groepeer, kan u addisioneel 'n verskuiwing spesifiseer, byvoorbeeld vir Moskou-tyd (UTC + 3):

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

Maar die navraagresultaat sal verkeerd wees. Om een ​​of ander rede sal die data wat volgens dag gegroepeer is so vroeg as 1677 begin (InfluxDB ondersteun amptelik 'n tydperk vanaf hierdie jaar):

Om hierdie probleem te omseil, is die diens tydelik na UTC + 0 oorgeplaas.

4. Prestasie

Daar is baie maatstawwe op die internet met vergelykings van InfluxDB en ander databasisse. Met die eerste oogopslag het hulle soos bemarkingsmateriaal gelyk, maar nou dink ek daar steek 'n mate van waarheid daarin.

Laat ek jou my saak vertel.

Die diens bied 'n API-metode wat statistieke vir die afgelope XNUMX uur terugstuur. Tydens berekeninge bevraagteken die metode die databasis drie keer met die volgende navrae:

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

Verduideliking:

1. In die eerste versoek kry ons die nuutste punte vir elke muntstuk met markdata. Agt kolletjies vir agt munte in my geval.
2. Die tweede versoek kry een nuutste punt.
3. Die derde een versoek 'n lys van transaksies vir die afgelope XNUMX uur, daar kan 'n paar honderd van hulle wees.

Laat ek dit duidelik maak dat in InfluxDB 'n indeks outomaties gebou word deur etikette en deur tyd, wat navrae versnel. In die eerste versoek simbool is 'n merker.

Ek het 'n strestoets vir hierdie API-metode gedoen. Vir 25 RPS het die bediener 'n volle vrag van ses SVE's getoon:

Terselfdertyd het die NodeJs-proses glad nie enige las gegee nie.

Die uitvoeringspoed het reeds met 7-10 RPS verswak: as een kliënt 'n reaksie binne 200 ms kon ontvang, dan moes 10 kliënte vir 'n sekonde wag. 25 RPS - die grens waaraan stabiliteit gely het, 500 foute is aan kliënte terugbesorg.

Met sulke prestasie is dit onmoontlik om Influx in ons projek te gebruik. Verder, in 'n projek waar monitering aan baie kliënte gedemonstreer moet word, kan soortgelyke probleme voorkom en die metrieke bediener sal oorlaai word.

Output

Die belangrikste gevolgtrekking uit die ervaring wat opgedoen is, is dat jy nie 'n onbekende tegnologie in 'n projek kan inneem sonder voldoende ontleding nie. 'n Eenvoudige sifting van oop kaartjies op github kan inligting verskaf om nie InfluxDB as die hoofdatawinkel te neem nie.

InfluxDB was veronderstel om die take van my projek goed te pas, maar soos die praktyk getoon het, voldoen hierdie databasis nie aan die behoeftes nie en mors dit baie deur.

U kan reeds weergawe 2.0.0-beta in die projekbewaarplek vind, daar moet nog gehoop word dat daar aansienlike verbeterings in die tweede weergawe sal wees. Intussen gaan ek die TimescaleDB-dokumentasie bestudeer.

Bron: will.com