Vrede, forhandlinger og depression, når du arbejder med InfluxDB

Hvis du bruger en tidsseriedatabase (timeseries db, wiki) som hovedlageret for et websted med statistik, så i stedet for at løse problemet, kan du få en masse hovedpine. Jeg arbejder på et projekt, der bruger sådan en database, og nogle gange præsenterede InfluxDB, som vil blive diskuteret, generelt uventede overraskelser.

AnsvarsfraskrivelseBemærk: De viste problemer er for InfluxDB 1.7.4.

Hvorfor tidsserier?

Projektet skal spore transaktioner i forskellige blockchains og vise statistik. Specifikt ser vi på emission og afbrænding af stabile mønter (wiki). Baseret på disse transaktioner skal du bygge grafer og vise pivottabeller.

Ved analyse af transaktioner opstod en idé: at bruge InfluxDB-tidsseriedatabasen som hovedlageret. Transaktioner er tidspunkter, og de passer godt ind i tidsseriemodellen.

Aggregeringsfunktionerne så også meget praktiske ud - de er ideelle til at behandle diagrammer med en lang periode. Brugeren har brug for et diagram for et år, og databasen indeholder et datasæt med en tidsramme på fem minutter. Det er meningsløst at sende alle hundrede tusinde point til ham - bortset fra en lang behandling, passer de ikke på skærmen. Du kan skrive din egen implementering for at øge tidsrammen eller bruge aggregeringsfunktionerne indbygget i Influx. Med deres hjælp kan du gruppere data efter dag og sende de ønskede 365 point.

Det var lidt pinligt, at sådanne databaser normalt bruges til at indsamle metrics. Overvågning af servere, iot-enheder, alt, hvorfra millioner af punkter af formen "flyder": [<tid> - <metrisk værdi>]. Men hvis databasen fungerer godt med en stor datastrøm, hvorfor skulle en lille volumen så give problemer? Med denne tanke tog de InfluxDB på arbejde.

Hvad der ellers er praktisk i InfluxDB

Ud over de nævnte aggregeringsfunktioner er der en anden fantastisk ting - løbende forespørgsler (dock). Dette er en skemalægger indbygget i databasen, som kan behandle data efter en tidsplan. For eksempel kan du gruppere alle rekorder for dagen hver 24 timer, beregne gennemsnittet og skrive et nyt punkt til en anden tabel uden at skrive dine egne cykler.

der er også en fastholdelsespolitikker (dock) - indstilling for sletning af data efter en vis periode. Det er nyttigt, når du for eksempel skal gemme belastningen på CPU'en i en uge med målinger en gang i sekundet, men i en afstand på et par måneder er en sådan nøjagtighed ikke nødvendig. I en sådan situation kan du gøre dette:

1. oprette en kontinuerlig forespørgsel for at samle data i en anden tabel;
2. for den første tabel skal du definere en politik for sletning af metrics, der er ældre end den samme uge.

Og Influx vil reducere størrelsen af ​​dataene og slette unødvendige data på egen hånd.

Om lagrede data

Der gemmes ikke meget data: omkring 70 tusinde transaktioner og yderligere en million point med markedsinformation. Tilføjelse af nye poster - ikke mere end 3000 point pr. dag. Der er også målinger for webstedet, men der er få data der, og i henhold til opbevaringspolitikken gemmes de ikke mere end en måned.

Problemer

Under udviklingen og den efterfølgende test af tjenesten opstod der flere og flere kritiske problemer i driften af ​​InfluxDB.

1. Sletning af data

Der er en række data med transaktioner:

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

Resultat:

Jeg sender en kommando for at slette data:

DELETE FROM transactions WHERE symbol=’USDT’

Derudover anmoder jeg om at få allerede slettede data. Og Influx returnerer, i stedet for et tomt svar, et stykke data, der bør fjernes.

Jeg prøver at slette hele tabellen:

DROP MEASUREMENT transactions

Jeg tjekker sletningen af ​​tabellen:

SHOW MEASUREMENTS

Jeg kan ikke se tabellen på listen, men den nye dataforespørgsel returnerer stadig det samme sæt af transaktioner.

Problemet opstod for mig kun én gang, da sletningssagen er et enkeltstående tilfælde. Men denne opførsel af databasen passer tydeligvis ikke ind i rammerne for "korrekt" arbejde. Senere blev github fundet åben billet næsten et år gammel om dette emne.

Som et resultat hjalp fjernelse og efterfølgende gendannelse af hele databasen.

2. Flydende kommatal

Matematiske beregninger ved hjælp af InfluxDBs indbyggede funktioner giver præcisionsfejl. Ikke at det var noget usædvanligt, men ubehageligt.

I mit tilfælde har data en økonomisk komponent, og jeg vil gerne behandle dem med høj nøjagtighed. På grund af dette planlægger vi at opgive løbende forespørgsler.

3. Løbende forespørgsler kan ikke tilpasses forskellige tidszoner

Tjenesten har en tabel med daglig transaktionsstatistik. For hver dag skal du gruppere alle transaktioner for den pågældende dag. Men dagen for hver bruger starter på et andet tidspunkt, derfor er sæt af transaktioner anderledes. UTC er 37 varianter skift, som du ønsker at samle data for.

I InfluxDB, når du grupperer efter tid, kan du desuden angive et skift, for eksempel for Moskva-tid (UTC + 3):

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

Men forespørgselsresultatet vil være forkert. Af en eller anden grund vil dataene grupperet efter dag begynde så tidligt som i 1677 (InfluxDB understøtter officielt et tidsrum fra i år):

For at omgå dette problem blev tjenesten midlertidigt overført til UTC + 0.

4. Ydeevne

Der er mange benchmarks på internettet med sammenligninger af InfluxDB og andre databaser. Ved første øjekast lignede de markedsføringsmaterialer, men nu tror jeg, at der er noget sandhed i dem.

Lad mig fortælle dig min sag.

Tjenesten leverer en API-metode, der returnerer statistik for de sidste XNUMX timer. Under beregninger forespørger metoden databasen tre gange med følgende forespørgsler:

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

Forklaring:

1. I den første anmodning får vi de seneste point for hver mønt med markedsdata. Otte prikker for otte mønter i mit tilfælde.
2. Den anden anmodning får et nyeste punkt.
3. Den tredje anmoder om en liste over transaktioner for de sidste XNUMX timer, der kan være flere hundrede af dem.

Lad mig præcisere, at i InfluxDB bygges et indeks automatisk af tags og af tid, hvilket fremskynder forespørgsler. I den første anmodning symbol er et tag.

Jeg lavede en stresstest for denne API-metode. For 25 RPS viste serveren en fuld belastning på seks CPU'er:

Samtidig gav NodeJs-processen ingen belastning overhovedet.

Udførelseshastigheden blev allerede forringet med 7-10 RPS: Hvis en klient kunne modtage et svar på 200 ms, måtte 10 klienter vente et sekund. 25 RPS - grænsen, som stabiliteten led under, blev 500 fejl returneret til kunderne.

Med en sådan ydeevne er det umuligt at bruge Influx i vores projekt. Desuden, i et projekt, hvor overvågning skal demonstreres for mange klienter, kan lignende problemer opstå, og metric-serveren vil blive overbelastet.

Output

Den vigtigste konklusion fra erfaringerne er, at man ikke kan tage en ukendt teknologi ind i et projekt uden tilstrækkelig analyse. En simpel screening af åbne billetter på github kunne give information om ikke at tage InfluxDB som hoveddatalageret.

InfluxDB skulle passe godt til opgaverne i mit projekt, men som praksis har vist, opfylder denne database ikke behovene og roder en del.

Du kan allerede finde version 2.0.0-beta i projektets repository, det er stadig at håbe, at der vil være væsentlige forbedringer i den anden version. I mellemtiden vil jeg studere TimescaleDB-dokumentationen.

Kilde: www.habr.com