Wut, Verhandlung und Depression bei der Arbeit mit InfluxDB

Wenn man eine Zeitreihendatenbank (timeseries db, wiki) als primäres Speicher für eine Statistikwebsite verwendet, kann man statt einer Lösung viele Kopfschmerzen bekommen. Ich arbeite an einem Projekt, in dem eine solche Datenbank verwendet wird, und manchmal hat InfluxDB, über die ich hier sprechen werde, ganz unerwartete Überraschungen bereitet.

Haftungsausschluss: die genannten Probleme beziehen sich auf die Version InfluxDB 1.7.4.

Warum Zeitreihen?

Das Projekt besteht darin, Transaktionen in verschiedenen Blockchains zu verfolgen und Statistiken darzustellen. Konkret betrachten wir die Emission und das Verbrennen von Stablecoins (wiki). Auf Basis dieser Transaktionen müssen Diagramme erstellt und Zusammenfassungen angezeigt werden.

Bei der Analyse der Transaktionen kam die Idee auf, die Zeitreihendatenbank InfluxDB als primäres Speichermedium zu nutzen. Transaktionen sind Zeitpunkte, und sie fügen sich gut in das Modell der Zeitreihe ein.

Auch die Aggregationsfunktionen sahen sehr praktisch aus – sie sind perfekt für die Verarbeitung von Diagrammen über einen langen Zeitraum geeignet. Der Benutzer benötigt ein Diagramm für ein Jahr, aber die Datenbank enthält einen Datensatz mit einem Zeitrahmen von fünf Minuten. Es macht keinen Sinn, alle hunderttausend Punkte zu senden – abgesehen von der langen Verarbeitung würden sie auch nicht auf den Bildschirm passen. Man kann seine eigene Implementierung zur Erhöhung des Zeitrahmens schreiben oder die in Influx integrierten Aggregationsfunktionen nutzen. Mit deren Hilfe können die Daten nach Tagen gruppiert und die erforderlichen 365 Punkte gesendet werden.

Es war etwas verwirrend, dass solche Datenbanken normalerweise zur Erfassung von Metriken verwendet werden. Serverüberwachung, IoT-Geräte, alles, wo Millionen von Punkten wie: – „fließen“. Aber wenn die Datenbank gut mit einem hohen Datenstrom arbeitet, warum sollte dann ein geringer Umfang Probleme verursachen? Mit diesem Gedanken haben wir InfluxDB in Betrieb genommen.

Was ist noch praktisch an InfluxDB

Neben den erwähnten Aggregationsfunktionen gibt es noch eine bemerkenswerte Sache – fortlaufende Abfragen (doc). Dies ist ein in die Datenbank integrierter Scheduler, der Daten nach einem Zeitplan verarbeiten kann. Zum Beispiel kann man alle 24 Stunden alle Einträge eines Tages gruppieren, den Durchschnitt berechnen und einen neuen Punkt in eine andere Tabelle schreiben, ohne eigene Lösungen entwickeln zu müssen.

Es gibt auch eine Aufbewahrungsrichtlinien (doc) — Einstellung der Datenlöschung nach einem bestimmten Zeitraum. Nützlich, wenn man zum Beispiel die CPU-Auslastung über eine Woche mit Messungen pro Sekunde speichern muss, während eine so hohe Genauigkeit über einige Monate nicht erforderlich ist. In einer solchen Situation kann man Folgendes machen:

1. eine kontinuierliche Abfrage zur Aggregation von Daten in eine andere Tabelle erstellen;
2. für die erste Tabelle die Löschrichtlinie für Metriken festlegen, die älter als diese Woche sind.

Und Influx wird selbstständig die Datenmenge reduzieren und Unnötiges löschen.

Über die gespeicherten Daten

Es werden nicht viele Daten gespeichert: etwa 70.000 Transaktionen und eine weitere Million Punkte mit Marktdaten. Es werden täglich nicht mehr als 3.000 Punkte hinzugefügt. Außerdem gibt es Metriken zur Website, aber dort sind die Daten gering, und gemäß der Retention-Policy werden sie nicht länger als einen Monat gespeichert.

Probleme

Bei der Entwicklung und anschließenden Testung des Dienstes traten immer kritischer werdende Probleme beim Betrieb von InfluxDB auf.

1. Daten löschen

Es gibt eine Datenreihe mit Transaktionen:

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

Ergebnis:

Ich sende den Befehl zum Löschen von Daten:

DELETE FROM transactions WHERE symbol='USDT'

Anschließend mache ich eine Anfrage, um die bereits gelöschten Daten zu erhalten. Und Influx gibt anstelle einer leeren Antwort einen Teil der Daten zurück, die gelöscht werden sollten.

Ich versuche, die Tabelle ganz zu löschen:

DROP MEASUREMENT transactions

Ich überprüfe das Löschen der Tabelle:

SHOW MEASUREMENTS

Die Tabelle ist in der Liste nicht zu sehen, aber eine neue Datenanfrage gibt immer noch dasselbe Set von Transaktionen zurück.

Das Problem trat nur einmal auf, da der Fall mit dem Löschen eine Einzelfallangelegenheit ist. Aber ein solches Verhalten der Datenbank passt offensichtlich nicht in den Rahmen einer „korrekten“ Funktion. Später fand ich auf GitHub einen offenen Ticket fast ein Jahr alten Thread zu diesem Thema.

Anschließend half es, die gesamte Datenbank zu löschen und wiederherzustellen.

2. Gleitende Kommazahlen

Mathematische Berechnungen bei Verwendung der in InfluxDB eingebauten Funktionen führen zu Genauigkeitsfehlern. Es ist nicht so, dass dies ungewöhnlich ist, aber es ist unangenehm.

In meinem Fall haben die Daten eine finanzielle Komponente und ich möchte sie mit hoher Genauigkeit bearbeiten. Deshalb plane ich, auf kontinuierliche Abfragen zu verzichten.

3. Kontinuierliche Abfragen können nicht an verschiedene Zeitzonen angepasst werden

Im Dienst gibt es eine Tabelle mit täglichen Statistiken zu Transaktionen. Für jeden Tag müssen alle Transaktionen für diesen Tag gruppiert werden. Aber der Tag beginnt für jeden Benutzer zu unterschiedlichen Zeiten, folglich ist auch der Satz der Transaktionen unterschiedlich. Gemäß UTC gibt es 37 Varianten von Verschiebungen, für die die Daten aggregiert werden müssen.

In InfluxDB kann bei der Gruppierung nach Zeit zusätzlich eine Verschiebung angegeben werden, zum Beispiel für Moskauer Zeit (UTC+3):

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

Aber das Ergebnis der Abfrage wird inkorrekt sein. Aus irgendeinem Grund beginnen die nach Tagen gruppierten Daten bereits im Jahr 1677 (InfluxDB unterstützt offiziell Zeiträume von diesem Jahr an):

Um dieses Problem zu umgehen, wurde der Dienst vorübergehend auf UTC+0 umgestellt.

4. Leistung

Im Internet gibt es viele Benchmarks, die InfluxDB mit anderen Datenbanken vergleichen. Bei der ersten Durchsicht schienen sie mir Marketingmaterialien zu sein, aber mittlerweile denke ich, dass ein Teil der Wahrheit darin steckt.

Ich werde meinen Fall schildern.

Der Dienst bietet eine API-Methode, die Statistiken für die letzten 24 Stunden zurückgibt. Bei den Berechnungen fragt die Methode die Datenbank dreimal mit folgenden Abfragen ab:

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

Erläuterung:

1. In der ersten Abfrage erhalten wir die letzten Punkte für jede Münze mit Marktdaten. In meinem Fall sind das acht Punkte für acht Münzen.
2. Die zweite Abfrage erhält den neuesten Punkt.
3. Die dritte fragt die Liste der Transaktionen der letzten 24 Stunden ab, davon kann es mehrere Hundert geben.

Ich möchte klarstellen, dass in InfluxDB Indizes automatisch nach Tags und Zeit erstellt werden, was die Abfragen beschleunigt. In der ersten Abfrage symbol ist ein Tag.

Ich habe einen Stresstest für diese API-Methode durchgeführt. Bei 25 RPS zeigte der Server eine volle Auslastung von sechs CPU-Kernen:

Dabei hatte der NodeJs-Prozess überhaupt keine Last.

Die Ausführungsgeschwindigkeit verschlechterte sich bereits bei 7-10 RPS: Wenn ein Client eine Antwort in 200 ms erhalten konnte, mussten 10 Clients eine Sekunde warten. 25 RPS ist die Grenze, ab der die Stabilität litt, den Kunden wurden 500-Fehler zurückgegeben.

Mit einer solchen Leistungsfähigkeit ist es unmöglich, Influx in unserem Projekt zu verwenden. Zudem: In einem Projekt, in dem das Monitoring vielen Kunden präsentiert werden muss, können ähnliche Probleme auftauchen und der Metrikserver wird überlastet.

Ausgabe

Die wichtigste Erkenntnis aus der gesammelten Erfahrung ist, dass man keine unbekannte Technologie ohne ausreichende Analyse in ein Projekt einbringen sollte. Ein einfacher Blick auf die offenen Tickets auf GitHub hätte Informationen geliefert, um InfluxDB nicht als primäres Datenspeicher zu wählen.

InfluxDB hätte gut zu den Anforderungen meines Projekts gepasst, aber wie die Praxis zeigte, erfüllt diese DB nicht die Bedürfnisse und hat viele Probleme.

Im Projekt-Repository ist bereits Version 2.0.0-beta zu finden, und man kann nur hoffen, dass die zweite Version wesentliche Verbesserungen bringen wird. In der Zwischenzeit werde ich die Dokumentation von TimescaleDB studieren.

Quelle: habr.com