ProHoster > Blogs > Administrācija > Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Ja izmantojat laikrindu datu bāzi (laikrindas db, Wiki) kā galvenā krātuve vietnei ar statistiku, tad problēmas risināŔanas vietā var sagādāt daudz galvassāpes. Es strādāju pie projekta, kurā tiek izmantota Ŕāda datu bāze, un dažreiz InfluxDB, par kuru tiks runāts, sagādāja pilnÄ«gi negaidÄ«tus pārsteigumus.

AtbildÄ«bas noraidÄ«Å”ana: uzskaitÄ«tās problēmas attiecas uz InfluxDB versiju 1.7.4.

Kāpēc laikrindas?

Projekta mērÄ·is ir izsekot darÄ«jumiem dažādās blokķēdes un parādÄ«t statistiku. Konkrēti, mēs aplÅ«kojam stabilu monētu emisiju un dedzināŔanu (Wiki). Pamatojoties uz Å”iem darÄ«jumiem, jums ir jāizveido diagrammas un jāparāda kopsavilkuma tabulas.

Analizējot darījumus, radās ideja: kā galveno krātuvi izmantot InfluxDB laikrindu datu bāzi. Darījumi ir laika punkti, un tie labi iekļaujas laikrindu modelī.

ArÄ« apkopoÅ”anas funkcijas izskatÄ«jās ļoti ērtas - ideāli piemērotas diagrammu apstrādei ar ilgu periodu. Lietotājam ir nepiecieÅ”ama diagramma par gadu, un datu bāzē ir datu kopa ar piecu minÅ«Å”u laika posmu. Nav jēgas sÅ«tÄ«t viņam visus simts tÅ«kstoÅ”us punktu ā€” ja neskaita ilgstoÅ”u apstrādi, tie pat neietilps ekrānā. Varat uzrakstÄ«t savu ievieÅ”anu, lai palielinātu laika periodu, vai izmantot apkopoÅ”anas funkcijas, kas iebÅ«vētas Influx. Ar viņu palÄ«dzÄ«bu jÅ«s varat grupēt datus pa dienām un nosÅ«tÄ«t nepiecieÅ”amos 365 punktus.

Nedaudz mulsināja tas, ka Ŕādas datu bāzes parasti tiek izmantotas metriku vākÅ”anai. Serveru, iot ierīču, visa, no kura ā€œplÅ«stā€ miljoniem punktu, uzraudzÄ«ba: [<laiks> - <metriskā vērtÄ«ba>]. Bet, ja datu bāze darbojas labi ar lielu datu plÅ«smu, tad kāpēc mazam apjomam vajadzētu radÄ«t problēmas? Paturot to prātā, mēs izmantojām InfluxDB darbu.

Kas vēl ir ērts InfluxDB

Bez minētajām apkopoÅ”anas funkcijām ir vēl viena lieliska lieta - nepārtraukti vaicājumi (doc). Å is ir datu bāzē iebÅ«vēts plānotājs, kas var apstrādāt datus pēc grafika. Piemēram, ik pēc 24 stundām varat sagrupēt visus dienas rekordus, aprēķināt vidējo un ierakstÄ«t vienu jaunu punktu citā tabulā, neierakstot savus velosipēdus.

ir arÄ« saglabāŔanas politikas (doc) ā€” datu dzÄ“Å”anas iestatÄ«Å”ana pēc noteikta laika. Noder, ja, piemēram, CPU slodzi vajag uzkrāt nedēļu ar mērÄ«jumiem reizi sekundē, bet pāris mēneÅ”u attālumā Ŕāda precizitāte nav nepiecieÅ”ama. Šādā situācijā varat rÄ«koties Ŕādi:

  1. izveidot nepārtrauktu vaicājumu, lai apkopotu datus citā tabulā;
  2. pirmajai tabulai definējiet politiku metrikas dzÄ“Å”anai, kas ir vecāka par to paÅ”u nedēļu.

Un Influx patstāvīgi samazinās datu apjomu un izdzēsīs nevajadzīgās lietas.

Par saglabātajiem datiem

Datu netiek glabāts daudz: aptuveni 70 tÅ«kstoÅ”i darÄ«jumu un vēl miljons punktu ar tirgus informāciju. Jaunu ierakstu pievienoÅ”ana - ne vairāk kā 3000 punkti dienā. Vietnei ir arÄ« metrika, taču tajā ir maz datu, un saskaņā ar saglabāŔanas politiku tie tiek glabāti ne ilgāk kā mēnesi.

Problēmas

Pakalpojuma izstrādes un turpmākās testÄ“Å”anas laikā InfluxDB darbÄ«bā radās arvien kritiskākas problēmas.

1. Datu dzēŔana

Ir virkne datu par darījumiem:

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

Rezultāts:

Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Es nosūtu komandu dzēst datus:

DELETE FROM transactions WHERE symbol=ā€™USDTā€™

Tālāk es pieprasu saņemt jau dzēstos datus. Un tukÅ”as atbildes vietā Influx atgriež daļu datu, kas bÅ«tu jādzÄ“Å”.

Es mēģinu izdzēst visu tabulu:

DROP MEASUREMENT transactions

Es pārbaudu tabulas dzÄ“Å”anu:

SHOW MEASUREMENTS

Es neredzu tabulu sarakstā, taču jaunais datu vaicājums joprojām atgriež to paŔu darījumu kopu.

Problēma man radās tikai vienu reizi, jo dzÄ“Å”anas gadÄ«jums bija atseviŔķs gadÄ«jums. Bet Ŕī datu bāzes uzvedÄ«ba acÄ«mredzami neietilpst ā€œpareizasā€ darbÄ«bas ietvaros. Vēlāk es atradu to atvērtu vietnē github biļete gandrÄ«z pirms gada par Å”o tēmu.

Rezultātā palÄ«dzēja visas datu bāzes dzÄ“Å”ana un pēc tam atjaunoÅ”ana.

2. PeldoŔā komata skaitļi

Matemātikas aprēķinos, izmantojot InfluxDB iebūvētās funkcijas, ir precizitātes kļūdas. Tas nav nekas neparasts, bet tas ir nepatīkams.

Manā gadÄ«jumā datiem ir finanÅ”u komponents, un es vēlētos tos apstrādāt ar augstu precizitāti. Å Ä« iemesla dēļ mēs plānojam atteikties no nepārtrauktiem vaicājumiem.

3. Nepārtrauktus vaicājumus nevar pielāgot dažādām laika zonām

Pakalpojumā ir tabula ar ikdienas darÄ«jumu statistiku. Katrai dienai ir jāgrupē visi Ŕīs dienas darÄ«jumi. Taču katra lietotāja diena sāksies citā laikā, un tāpēc darÄ«jumu kopums bÅ«s atŔķirÄ«gs. Pēc UTC jā 37 varianti maiņas, par kurām jums ir jāapkopo dati.

InfluxDB, grupējot pēc laika, varat papildus norādīt nobīdi, piemēram, pēc Maskavas laika (UTC+3):

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

Bet vaicājuma rezultāts bÅ«s nepareizs. Kādu iemeslu dēļ dati, kas sagrupēti pa dienām, sāksies lÄ«dz pat 1677. gadam (InfluxDB oficiāli atbalsta laika posmu no Ŕī gada):

Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Lai novērstu Å”o problēmu, mēs Ä«slaicÄ«gi pārslēdzām pakalpojumu uz UTC+0.

4. Performance

Internetā ir daudz etalonu, kas salīdzina InfluxDB un citas datu bāzes. No pirmā acu uzmetiena tie izskatījās pēc mārketinga materiāliem, bet tagad es domāju, ka tajos ir kāda patiesība.

Es jums pastāstīŔu savu gadījumu.

Pakalpojums nodroÅ”ina API metodi, kas atgriež statistiku par pēdējo dienu. Veicot aprēķinus, metode trÄ«s reizes vaicā datu bāzi ar Ŕādiem vaicājumiem:

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

Paskaidrojums

  1. Pirmajā pieprasījumā mēs saņemam pēdējos punktus par katru monētu ar tirgus datiem. Manā gadījumā astoņi punkti par astoņām monētām.
  2. Otrais pieprasījums iegūst vienu no jaunākajiem punktiem.
  3. TreÅ”ais pieprasa pēdējo XNUMX stundu darÄ«jumu sarakstu, to var bÅ«t vairāki simti.

Ļaujiet man precizēt, ka InfluxDB automātiski izveido indeksu, pamatojoties uz tagiem un laiku, kas paātrina vaicājumu izpildi. Pirmajā pieprasījumā simbols ir atzīme.

Esmu veicis Ŕīs API metodes stresa testu. 25 RPS serveris demonstrēja pilnu seÅ”u CPU slodzi:

Dusmas, kaulÄ“Å”anās un depresija, strādājot ar InfluxDB

Tajā paŔā laikā NodeJ process vispār nenodroŔināja slodzi.

Izpildes ātrums ir samazinājies jau par 7-10 RPS: ja viens klients varēja saņemt atbildi 200 ms laikā, tad 10 klientiem bija jāgaida sekunde. 25 RPS ir robeža, pie kuras cieta stabilitāte; klientiem tika atgrieztas 500 kļūdas.

Ar Ŕādu veiktspēju nav iespējams izmantot Influx mÅ«su projektā. Turklāt: projektā, kurā monitorings ir jādemonstrē daudziem klientiem, var rasties lÄ«dzÄ«gas problēmas un tiks pārslogots metrikas serveris.

secinājums

VissvarÄ«gākais secinājums no gÅ«tās pieredzes ir tāds, ka nezināmu tehnoloÄ£iju nevar iekļaut projektā bez pietiekamas analÄ«zes. VienkārÅ”a atklāto problēmu pārbaude vietnē github varētu sniegt informāciju, lai izvairÄ«tos no InfluxDB izvēles par galveno datu krātuvi.

InfluxDB vajadzēja bÅ«t piemērotam mana projekta uzdevumiem, taču, kā liecina prakse, Ŕī datu bāze neatbilst vajadzÄ«bām un tajā ir daudz kļūdu.

Projekta repozitorijā jau var atrast versiju 2.0.0-beta, atliek tikai cerēt, ka otrajā versijā bÅ«s bÅ«tiski uzlabojumi. Tikmēr es ieÅ”u pētÄ«t TimescaleDB dokumentāciju.

Avots: www.habr.com

Pievieno komentāru