Woede, onderhandelen en depressie bij het werken met InfluxDB

Als u een tijdreeksdatabase gebruikt (timeseries db, wiki) als hoofdopslag voor een site met statistieken, dan kunt u in plaats van het probleem op te lossen veel kopzorgen krijgen. Ik werk aan een project dat zo'n database gebruikt, en soms zorgde InfluxDB, dat zal worden besproken, voor totaal onverwachte verrassingen.

Disclaimer: De genoemde problemen zijn van toepassing op InfluxDB versie 1.7.4.

Waarom tijdreeksen?

Het project is bedoeld om transacties op verschillende blockchains te volgen en statistieken weer te geven. Concreet kijken we naar de uitstoot en verbranding van stabiele munten (wiki). Op basis van deze transacties moet u grafieken maken en samenvattende tabellen weergeven.

Tijdens het analyseren van transacties kwam er een idee naar voren: om de tijdreeksdatabase van InfluxDB als hoofdopslag te gebruiken. Transacties zijn tijdstippen en passen goed in het tijdreeksmodel.

De aggregatiefuncties zagen er ook erg handig uit - ideaal voor het verwerken van grafieken met een lange periode. De gebruiker heeft een grafiek voor een jaar nodig en de database bevat een dataset met een tijdsbestek van vijf minuten. Het heeft geen zin om hem alle honderdduizend punten te sturen - afgezien van de lange verwerkingstijd passen ze niet eens op het scherm. U kunt uw eigen implementatie schrijven om het tijdsbestek te verlengen, of de aggregatiefuncties gebruiken die in Influx zijn ingebouwd. Met hun hulp kunt u gegevens per dag groeperen en de benodigde 365 punten verzenden.

Het was een beetje verwarrend dat dergelijke databases meestal worden gebruikt voor het verzamelen van statistieken. Monitoring van servers, iot-apparaten, alles waaruit miljoenen punten van de vorm “stromen”: [<tijd> - <metrische waarde>]. Maar als de database goed werkt met een grote datastroom, waarom zou een klein volume dan problemen veroorzaken? Met dit in gedachten hebben we InfluxDB aan het werk gezet.

Wat is er nog meer handig in InfluxDB

Naast de genoemde aggregatiefuncties is er nog iets geweldigs: continue vragen (dok). Dit is een planner die in de database is ingebouwd en die gegevens volgens een schema kan verwerken. U kunt bijvoorbeeld elke 24 uur alle records voor de dag groeperen, het gemiddelde berekenen en een nieuw punt in een andere tabel opnemen zonder uw eigen fietsen te schrijven.

Hebben ook bewaarbeleid (dok) – gegevensverwijdering na een bepaalde periode instellen. Het is handig als u bijvoorbeeld de CPU-belasting een week lang moet opslaan met metingen van één keer per seconde, maar over een afstand van een paar maanden is een dergelijke nauwkeurigheid niet nodig. In een dergelijke situatie kunt u dit doen:

1. een doorlopende query maken om gegevens in een andere tabel samen te voegen;
2. definieer voor de eerste tabel een beleid voor het verwijderen van statistieken die ouder zijn dan diezelfde week.

En Influx zal zelfstandig de omvang van de gegevens verkleinen en onnodige dingen verwijderen.

Over opgeslagen gegevens

Er worden niet veel gegevens opgeslagen: ongeveer 70 duizend transacties en nog eens een miljoen punten met marktinformatie. Nieuwe vermeldingen toevoegen - niet meer dan 3000 punten per dag. Er zijn ook statistieken voor de site, maar die bevatten weinig gegevens en worden volgens het bewaarbeleid niet langer dan een maand bewaard.

Problemen

Tijdens de ontwikkeling en het daaropvolgende testen van de dienst ontstonden er steeds meer kritische problemen bij de werking van InfluxDB.

1. Gegevens verwijderen

Er is een reeks gegevens met transacties:

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

Resultaat:

Ik stuur een opdracht om gegevens te verwijderen:

DELETE FROM transactions WHERE symbol=’USDT’

Vervolgens doe ik een verzoek om de reeds verwijderde gegevens te ontvangen. En in plaats van een leeg antwoord retourneert Influx een deel van de gegevens die moeten worden verwijderd.

Ik probeer de hele tabel te verwijderen:

DROP MEASUREMENT transactions

Ik controleer de tabelverwijdering:

SHOW MEASUREMENTS

Ik zie de tabel niet in de lijst, maar een nieuwe gegevensquery retourneert nog steeds dezelfde reeks transacties.

Het probleem kwam maar één keer bij me op, omdat het verwijderingsgeval een op zichzelf staand geval was. Maar dit gedrag van de database past duidelijk niet in het raamwerk van een “juiste” werking. Later vond ik het open op github ticket bijna een jaar geleden over dit onderwerp.

Het resultaat was dat het verwijderen en vervolgens herstellen van de hele database hielp.

2. Drijvende-kommagetallen

Wiskundige berekeningen bij het gebruik van ingebouwde functies in InfluxDB vertonen nauwkeurigheidsfouten. Niet dat dit iets ongewoons is, maar het is wel onaangenaam.

In mijn geval hebben de gegevens een financiële component en ik wil deze graag met hoge nauwkeurigheid verwerken. Daarom zijn we van plan om doorlopende zoekopdrachten stop te zetten.

3. Doorlopende zoekopdrachten kunnen niet worden aangepast aan verschillende tijdzones

De dienst heeft een tabel met dagelijkse transactiestatistieken. Voor elke dag moet u alle transacties voor die dag groeperen. Maar de dag van elke gebruiker begint op een ander tijdstip, en daarom zal de reeks transacties anders zijn. Via UTC ja 37 varianten ploegendiensten waarvoor u gegevens moet verzamelen.

In InfluxDB kunt u bij het groeperen op tijd bovendien een verschuiving opgeven, bijvoorbeeld voor Moskou-tijd (UTC+3):

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

Maar het resultaat van de zoekopdracht zal onjuist zijn. Om de een of andere reden beginnen de gegevens, gegroepeerd op dag, helemaal terug tot 1677 (InfluxDB ondersteunt officieel een tijdspanne vanaf dit jaar):

Om dit probleem te omzeilen, hebben we de service tijdelijk overgeschakeld naar UTC+0.

4. Prestaties

Er zijn veel benchmarks op internet die InfluxDB en andere databases vergelijken. Op het eerste gezicht leken ze op marketingmateriaal, maar nu denk ik dat er een kern van waarheid in zit.

Ik zal je mijn zaak vertellen.

De service biedt een API-methode die statistieken voor de afgelopen dag retourneert. Bij het uitvoeren van berekeningen doorzoekt de methode de database drie keer met de volgende zoekopdrachten:

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

uitleg:

1. Bij de eerste aanvraag krijgen we de laatste punten voor elke munt met marktgegevens. In mijn geval acht punten voor acht munten.
2. Het tweede verzoek krijgt een van de nieuwste punten.
3. De derde vraagt ​​om een ​​lijst met transacties van de afgelopen XNUMX uur; het kunnen er honderden zijn.

Laat me verduidelijken dat InfluxDB automatisch een index bouwt op basis van tags en tijd, wat zoekopdrachten versnelt. Bij het eerste verzoek symbool is een label.

Ik heb een stresstest uitgevoerd op deze API-methode. Voor 25 RPS demonstreerde de server een volledige belasting van zes CPU's:

Tegelijkertijd zorgde het NodeJs-proces helemaal niet voor enige belasting.

De uitvoeringssnelheid is al met 7-10 RPS afgenomen: als één client binnen 200 ms een antwoord kon ontvangen, moesten 10 clients een seconde wachten. 25 RPS is de limiet waarbij de stabiliteit te lijden heeft; 500 fouten zijn teruggestuurd naar clients.

Met dergelijke prestaties is het onmogelijk om Influx in ons project te gebruiken. Bovendien: in een project waarbij monitoring aan veel klanten moet worden gedemonstreerd, kunnen vergelijkbare problemen optreden en zal de metrische server overbelast raken.

Uitgang

De belangrijkste conclusie uit de opgedane ervaring is dat je een onbekende technologie niet mee kunt nemen in een project zonder voldoende analyse. Een eenvoudige screening van openstaande problemen op github zou informatie kunnen opleveren om te voorkomen dat InfluxDB als de belangrijkste gegevensopslag wordt gekozen.

InfluxDB had goed moeten passen bij de taken van mijn project, maar zoals de praktijk heeft geleerd, voldoet deze database niet aan de behoeften en bevat deze veel bugs.

Je kunt versie 2.0.0-bèta al vinden in de projectrepository; we kunnen alleen maar hopen dat de tweede versie aanzienlijke verbeteringen zal hebben. In de tussentijd ga ik de TimescaleDB-documentatie bestuderen.

Bron: www.habr.com