As jy 'n tydreeksdatabasis gebruik (tydreeks db,
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 (
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 (
Daar is ook retensiebeleide (
- skep 'n deurlopende navraag om data in 'n ander tabel saam te voeg;
- 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
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
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:
- In die eerste versoek kry ons die nuutste punte vir elke muntstuk met markdata. Agt kolletjies vir agt munte in my geval.
- Die tweede versoek kry een nuutste punt.
- 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