Ilska, förhandlingar och depression när du arbetar med InfluxDB

Om du använder en tidsseriedatabas (timeseries db, wiki) som huvudlagring för en webbplats med statistik, så istället för att lösa problemet kan du få mycket huvudvärk. Jag håller på med ett projekt som använder en sådan databas, och ibland presenterade InfluxDB, som kommer att diskuteras, helt oväntade överraskningar.

Villkor: Problemen som anges gäller för InfluxDB version 1.7.4.

Varför tidsserier?

Projektet går ut på att spåra transaktioner på olika blockkedjor och visa statistik. Specifikt tittar vi på utsläpp och förbränning av stabila mynt (wiki). Baserat på dessa transaktioner måste du bygga grafer och visa sammanfattningstabeller.

När man analyserade transaktioner kom en idé upp: att använda InfluxDB-tidsseriedatabasen som huvudlagring. Transaktioner är tidpunkter och de passar väl in i tidsseriemodellen.

Aggregeringsfunktionerna såg också väldigt bekväma ut - perfekt för att bearbeta diagram med en lång period. Användaren behöver ett diagram för ett år, och databasen innehåller en datamängd med en tidsram på fem minuter. Det är meningslöst att skicka honom alla hundra tusen prickar - förutom lång bearbetning får de inte ens plats på skärmen. Du kan skriva din egen implementering för att öka tidsramen, eller använda aggregeringsfunktionerna inbyggda i Influx. Med deras hjälp kan du gruppera data efter dag och skicka de nödvändiga 365 poängen.

Det var lite förvirrande att sådana databaser vanligtvis används i syfte att samla in mått. Övervakning av servrar, iot-enheter, allt från vilket miljontals punkter av formen "flödar": [<tid> - <metriskt värde>]. Men om databasen fungerar bra med ett stort dataflöde, varför skulle då en liten volym orsaka problem? Med detta i åtanke tog vi InfluxDB till jobbet.

Vad mer är bekvämt i InfluxDB

Förutom de nämnda aggregeringsfunktionerna finns det en annan bra sak - kontinuerliga frågor (doc). Detta är en schemaläggare inbyggd i databasen som kan bearbeta data enligt ett schema. Till exempel kan du var 24:e timme gruppera alla poster för dagen, beräkna medelvärdet och registrera en ny punkt i en annan tabell utan att skriva dina egna cyklar.

det finns också en lagringspolicyer (doc) – ställa in dataradering efter en viss period. Det är användbart när du till exempel behöver lagra CPU-belastningen i en vecka med mätningar en gång per sekund, men över ett avstånd på ett par månader behövs ingen sådan noggrannhet. I en sådan situation kan du göra så här:

1. skapa en kontinuerlig fråga för att samla data till en annan tabell;
2. för den första tabellen, definiera en policy för att ta bort mätvärden som är äldre än samma vecka.

Och Influx kommer självständigt att minska storleken på data och radera onödiga saker.

Om lagrad data

Inte mycket data lagras: cirka 70 tusen transaktioner och ytterligare en miljon poäng med marknadsinformation. Lägga till nya poster - inte mer än 3000 poäng per dag. Det finns också mätvärden för sajten, men det finns lite data där och enligt lagringspolicyn lagras de i högst en månad.

Problem

Under utvecklingen och efterföljande testning av tjänsten uppstod fler och fler kritiska problem i driften av InfluxDB.

1. Radera data

Det finns en serie data med transaktioner:

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

Resultat:

Jag skickar ett kommando för att radera data:

DELETE FROM transactions WHERE symbol=’USDT’

Därefter gör jag en begäran om att få de redan raderade uppgifterna. Och istället för ett tomt svar returnerar Influx en del av den data som ska raderas.

Jag försöker ta bort hela tabellen:

DROP MEASUREMENT transactions

Jag kollar raderingen av tabellen:

SHOW MEASUREMENTS

Jag ser inte tabellen i listan, men en ny datafråga returnerar fortfarande samma uppsättning transaktioner.

Problemet uppstod bara för mig en gång, eftersom borttagningsfallet var ett isolerat fall. Men detta beteende hos databasen passar uppenbarligen inte in i ramen för "korrekt" drift. Senare hittade jag den öppen på github biljett nästan ett år sedan om detta ämne.

Som ett resultat hjälpte det att ta bort och sedan återställa hela databasen.

2. Flyttal

Matematiska beräkningar vid användning av inbyggda funktioner i InfluxDB har noggrannhetsfel. Inte för att detta är något ovanligt, men det är obehagligt.

I mitt fall har uppgifterna en ekonomisk komponent och jag skulle vilja behandla den med hög noggrannhet. På grund av detta planerar vi att överge kontinuerliga frågor.

3. Kontinuerliga frågor kan inte anpassas till olika tidszoner

Tjänsten har en tabell med daglig transaktionsstatistik. För varje dag måste du gruppera alla transaktioner för den dagen. Men varje användares dag börjar vid en annan tidpunkt, och därför kommer uppsättningen av transaktioner att vara olika. Med UTC ja 37 alternativ skift för vilka du behöver samla data.

I InfluxDB, när du grupperar efter tid, kan du dessutom ange ett skifte, till exempel för Moskva-tid (UTC+3):

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

Men frågeresultatet blir felaktigt. Av någon anledning kommer data grupperade efter dag att börja ända tillbaka till 1677 (InfluxDB stöder officiellt ett tidsintervall från detta år):

För att undvika det här problemet bytte vi tillfälligt tjänsten till UTC+0.

4. Prestanda

Det finns många riktmärken på Internet som jämför InfluxDB och andra databaser. Vid första anblicken såg de ut som marknadsföringsmaterial, men nu tror jag att det ligger en viss sanning i dem.

Jag ska berätta mitt fall.

Tjänsten tillhandahåller en API-metod som returnerar statistik för den sista dagen. När du utför beräkningar frågar metoden databasen tre gånger med följande frågor:

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

Förklaring:

1. I den första begäran får vi de sista poängen för varje mynt med marknadsdata. Åtta poäng för åtta mynt i mitt fall.
2. Den andra begäran får en av de senaste poängen.
3. Den tredje begär en lista över transaktioner för de senaste XNUMX timmarna, det kan finnas flera hundra av dem.

Låt mig förtydliga att InfluxDB automatiskt bygger ett index baserat på taggar och tid, vilket påskyndar frågor. I den första begäran Symbolen är en tagg.

Jag har kört ett stresstest på denna API-metod. För 25 RPS visade servern en full belastning av sex processorer:

Samtidigt gav NodeJs-processen ingen belastning alls.

Exekveringshastigheten har redan minskat med 7-10 RPS: om en klient kunde få ett svar på 200 ms, fick 10 klienter vänta en sekund. 25 RPS är gränsen vid vilken stabiliteten drabbades; 500 fel returnerades till kunderna.

Med sådan prestanda är det omöjligt att använda Influx i vårt projekt. Dessutom: i ett projekt där övervakning måste demonstreras för många klienter kan liknande problem uppstå och mätservern kommer att överbelastas.

Utgång

Den viktigaste slutsatsen av erfarenheterna är att man inte kan ta in en okänd teknik i ett projekt utan tillräcklig analys. En enkel genomgång av öppna problem på github kan ge information för att undvika att välja InfluxDB som huvuddatalager.

InfluxDB borde ha passat bra för uppgifterna i mitt projekt, men som praxis har visat uppfyller denna databas inte behoven och har många buggar.

Du kan redan hitta version 2.0.0-beta i projektförrådet, vi kan bara hoppas att den andra versionen kommer att ha betydande förbättringar. Under tiden ska jag gå och studera TimescaleDB-dokumentationen.

Källa: will.com