Sinne, forhandlinger og depresjon når du jobber med InfluxDB

Hvis du bruker en tidsseriedatabase (timeseries db, wiki) som hovedlagring for et nettsted med statistikk, så i stedet for å løse problemet kan du få mye hodepine. Jeg jobber med et prosjekt som bruker en slik database, og noen ganger presenterte InfluxDB, som vil bli diskutert, helt uventede overraskelser.

Ansvarsfraskrivelse: Problemene som er oppført gjelder for InfluxDB versjon 1.7.4.

Hvorfor tidsserier?

Prosjektet skal spore transaksjoner på ulike blokkjeder og vise statistikk. Spesielt ser vi på utslipp og brenning av stabile mynter (wiki). Basert på disse transaksjonene må du bygge grafer og vise sammendragstabeller.

Mens man analyserte transaksjoner, dukket det opp en idé: å bruke InfluxDB-tidsseriedatabasen som hovedlagring. Transaksjoner er punkter i tid og de passer godt inn i tidsseriemodellen.

Aggregeringsfunksjonene så også veldig praktiske ut - ideell for behandling av diagrammer med lang periode. Brukeren trenger et diagram for et år, og databasen inneholder et datasett med en tidsramme på fem minutter. Det er meningsløst å sende ham alle hundre tusen prikker - bortsett fra lang behandling, vil de ikke engang passe på skjermen. Du kan skrive din egen implementering for å øke tidsrammen, eller bruke aggregeringsfunksjonene innebygd i Influx. Med deres hjelp kan du gruppere data etter dag og sende de nødvendige 365 poengene.

Det var litt forvirrende at slike databaser vanligvis brukes med det formål å samle inn beregninger. Overvåking av servere, iot-enheter, alt som millioner av punkter i formen "flyter" fra: [<tid> - <metrisk verdi>]. Men hvis databasen fungerer bra med en stor dataflyt, hvorfor skulle et lite volum da skape problemer? Med dette i tankene tok vi InfluxDB på jobb.

Hva annet er praktisk i InfluxDB

Bortsett fra de nevnte aggregeringsfunksjonene, er det en annen flott ting - kontinuerlige spørsmål (doc). Dette er en planlegger innebygd i databasen som kan behandle data etter en tidsplan. For eksempel, hver 24. time kan du gruppere alle postene for dagen, beregne gjennomsnittet og registrere ett nytt poeng i en annen tabell uten å skrive dine egne sykler.

Det er også oppbevaringspolitikk (doc) – sette opp sletting av data etter en viss periode. Det er nyttig når du for eksempel skal lagre CPU-belastningen i en uke med målinger en gang per sekund, men over en avstand på et par måneder er det ikke nødvendig med en slik nøyaktighet. I en slik situasjon kan du gjøre dette:

1. lage en kontinuerlig spørring for å samle data til en annen tabell;
2. for den første tabellen, definer en policy for sletting av beregninger som er eldre enn den samme uken.

Og Influx vil uavhengig redusere størrelsen på dataene og slette unødvendige ting.

Om lagrede data

Ikke mye data lagres: rundt 70 tusen transaksjoner og ytterligere en million poeng med markedsinformasjon. Legge til nye oppføringer - ikke mer enn 3000 poeng per dag. Det er også beregninger for nettstedet, men det er lite data der, og i henhold til oppbevaringspolicyen lagres de i ikke mer enn en måned.

Problemer

Under utviklingen og påfølgende testing av tjenesten oppsto det flere og flere kritiske problemer i driften av InfluxDB.

1. Sletting av data

Det er en rekke data med transaksjoner:

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

Resultat:

Jeg sender en kommando for å slette data:

DELETE FROM transactions WHERE symbol=’USDT’

Deretter sender jeg en forespørsel om å motta de allerede slettede dataene. Og i stedet for et tomt svar, returnerer Influx deler av dataene som bør slettes.

Jeg prøver å slette hele tabellen:

DROP MEASUREMENT transactions

Jeg sjekker tabellslettingen:

SHOW MEASUREMENTS

Jeg ser ikke tabellen i listen, men en ny dataspørring returnerer fortsatt det samme settet med transaksjoner.

Problemet oppstod bare for meg én gang, siden slettingssaken var et isolert tilfelle. Men denne oppførselen til databasen passer tydeligvis ikke inn i rammen for "riktig" operasjon. Senere fant jeg den åpen på github billett for nesten et år siden om dette emnet.

Som et resultat hjalp det å slette og deretter gjenopprette hele databasen.

2. Flyttall

Matematiske beregninger ved bruk av innebygde funksjoner i InfluxDB har nøyaktighetsfeil. Ikke at dette er noe uvanlig, men det er ubehagelig.

I mitt tilfelle har dataene en økonomisk komponent, og jeg vil gjerne behandle dem med høy nøyaktighet. På grunn av dette planlegger vi å forlate kontinuerlige forespørsler.

3. Kontinuerlige spørringer kan ikke tilpasses ulike tidssoner

Tjenesten har en tabell med daglig transaksjonsstatistikk. For hver dag må du gruppere alle transaksjoner for den dagen. Men hver brukers dag vil begynne på et annet tidspunkt, og derfor vil settet med transaksjoner være forskjellig. Med UTC ja 37 varianter skift som du må samle data for.

I InfluxDB, når du grupperer etter tid, kan du i tillegg spesifisere et skifte, for eksempel for Moskva-tid (UTC+3):

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

Men søkeresultatet vil være feil. Av en eller annen grunn vil data gruppert etter dag starte helt tilbake til 1677 (InfluxDB støtter offisielt et tidsrom fra i år):

For å omgå dette problemet byttet vi tjenesten midlertidig til UTC+0.

4. Ytelse

Det er mange benchmarks på Internett som sammenligner InfluxDB og andre databaser. Ved første øyekast så de ut som markedsføringsmateriell, men nå tror jeg det er en viss sannhet i dem.

Jeg skal fortelle deg min sak.

Tjenesten gir en API-metode som returnerer statistikk for siste dag. Når du utfører beregninger, spør metoden databasen tre ganger med følgende spørringer:

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 forespørselen får vi de siste poengene for hver mynt med markedsdata. Åtte poeng for åtte mynter i mitt tilfelle.
2. Den andre forespørselen får et av de nyeste punktene.
3. Den tredje ber om en liste over transaksjoner for de siste XNUMX timene; det kan være flere hundre av dem.

La meg presisere at InfluxDB automatisk bygger en indeks basert på tagger og tid, noe som øker hastigheten på spørringene. I den første forespørselen symbol er en merkelapp.

Jeg har kjørt en stresstest på denne API-metoden. For 25 RPS demonstrerte serveren en full belastning på seks CPUer:

Samtidig ga NodeJs-prosessen ingen belastning i det hele tatt.

Utførelseshastigheten er allerede redusert med 7-10 RPS: Hvis en klient kunne motta et svar på 200 ms, måtte 10 klienter vente et sekund. 25 RPS er grensen for stabiliteten lidd; 500 feil ble returnert til klienter.

Med slik ytelse er det umulig å bruke Influx i prosjektet vårt. Dessuten: i et prosjekt der overvåking må demonstreres for mange klienter, kan lignende problemer oppstå og metrikkserveren vil bli overbelastet.

Utgang

Den viktigste konklusjonen fra erfaringene er at man ikke kan ta en ukjent teknologi inn i et prosjekt uten tilstrekkelig analyse. En enkel screening av åpne problemer på github kan gi informasjon for å unngå å velge InfluxDB som hoveddatalager.

InfluxDB skulle ha passet godt for oppgavene til prosjektet mitt, men som praksis har vist, oppfyller ikke denne databasen behovene og har mange feil.

Du kan allerede finne versjon 2.0.0-beta i prosjektlageret; vi kan bare håpe at den andre versjonen vil ha betydelige forbedringer. I mellomtiden skal jeg studere TimescaleDB-dokumentasjonen.

Kilde: www.habr.com