Wut, Verhandlung und Depression bei der Arbeit mit InfluxDB

Wenn man eine Zeitreihendatenbank (timeseries db) als primären Speicher für eine Webseite mit Statistiken verwendet, kann man anstelle der Lösung des Problems viele Kopfschmerzen bekommen. Ich arbeite an einem Projekt, in dem eine solche Datenbank verwendet wird, und manchmal hat InfluxDB, über die hier die Rede ist, wirklich unerwartete Überraschungen gebracht. Wiki: Die genannten Probleme beziehen sich auf die Version InfluxDB 1.7.4.

HaftungsausschlussWarum Zeitreihen?

Das Projekt besteht darin, Transaktionen in verschiedenen Blockchains zu verfolgen und Statistiken anzuzeigen. Konkret betrachten wir die Emission und das Verbrennen von Stablecoins (

). Basierend auf diesen Transaktionen müssen Diagramme erstellt und Pivot-Tabellen angezeigt werden.WikiBei der Analyse der Transaktionen kam die Idee auf, die Zeitreihendatenbank InfluxDB als primären Speicher zu verwenden. Transaktionen sind Zeitpunkte und passen gut in das Modell der Zeitreihe.

Bei der Analyse von Transaktionen entstand die Idee, die InfluxDB-Zeitreihe als primären Speicher zu verwenden. Transaktionen sind Zeitpunkte und passen gut in das Modell der Zeitreihe.

Weitere Aggregationsfunktionen waren äußerst praktisch – sie eignen sich hervorragend zur Verarbeitung von Diagrammen über längere Zeiträume. Wenn der Nutzer ein Diagramm für ein Jahr benötigt, liegt in der Datenbank jedoch ein Datensatz mit einem Zeitrahmen von fünf Minuten vor. Es wäre sinnlos, alle hunderttausend Punkte zu senden – sie würden nicht nur lange verarbeitet werden, sondern auch nicht auf den Bildschirm passen. Man könnte eine eigene Implementierung zur Erhöhung des Zeitrahmens schreiben oder die in Influx integrierten Aggregationsfunktionen nutzen. Mit ihrer Hilfe können die Daten nach Tagen gruppiert und die gewünschten 365 Punkte gesendet werden.

Es war etwas verwirrend, dass solche Datenbanken normalerweise zum Sammeln von Metriken verwendet werden. Serverüberwachung, IoT-Geräte, all das, wo Millionen von Punkten in der Form: [ – ] „fließen“. Wenn die Datenbank jedoch gut mit großen Datenströmen arbeitet, warum sollte dann ein kleiner Umfang Probleme verursachen? Mit diesem Gedanken haben wir InfluxDB in unseren Arbeitsprozess aufgenommen.

Was ist noch praktisch an InfluxDB?

Neben den erwähnten Aggregationsfunktionen gibt es noch eine wunderbare Sache – kontinuierliche Abfragen (doc). Dies ist ein integrierter Datenbank-Planer, der Daten nach einem Zeitplan verarbeiten kann. Beispielsweise können alle täglichen Aufzeichnungen alle 24 Stunden gruppiert, der Durchschnitt berechnet und ein neuer Wert in eine andere Tabelle aufgezeichnet werden, ohne eigene Lösungen zu erstellen.

Es gibt auch eine Aufbewahrungsrichtlinien (doc) — eine Einstellung zur Löschung von Daten nach einem bestimmten Zeitraum. Das ist nützlich, wenn zum Beispiel die CPU-Belastung für eine Woche mit Messungen pro Sekunde gespeichert werden muss, während solch eine Genauigkeit über mehrere Monate nicht erforderlich ist. In so einem Fall kann man Folgendes tun:

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

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

Über die gespeicherten Daten

Es gibt nicht viele gespeicherte Daten: etwa 70.000 Transaktionen und eine weitere Million Punkte mit Marktdaten. Es werden täglich nicht mehr als 3.000 neue Aufzeichnungen hinzugefügt. Auch gibt es Metriken zur Website, aber die Daten sind gering und werden gemäß der Aufbewahrungsrichtlinie nicht länger als einen Monat gespeichert.

Die Probleme

Bei der Entwicklung und anschließenden Tests des Services traten immer kritische Probleme beim Betrieb von InfluxDB auf.

1. Daten löschen

Es gibt eine Serie von Transaktionsdaten:

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

Das Ergebnis:

Ich sende den Befehl zum Löschen der Daten:

DELETE FROM transactions WHERE symbol='USDT'

Anschließend mache ich eine Anfrage zum Abrufen der bereits gelöschten Daten. Und Influx gibt anstelle einer leeren Antwort einen Teil der Daten zurück, die hätten gelöscht werden sollen.

Ich versuche, die Tabelle vollständig zu löschen:

DROP MEASUREMENT transactions

Ich überprüfe die Löschung der Tabelle:

SHOW MEASUREMENTS

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

Das Problem trat nur einmal bei mir auf, da der Fall des Löschens ein Einzelfall war. Aber solches Verhalten der Datenbank passt eindeutig nicht in die Kategorie „korrekte“ Funktion. Später fand ich auf GitHub einen offenen Ticket fast ein Jahr alten Eintrag zu diesem Thema.

In der Folge half das Löschen und anschließende Wiederherstellen der gesamten Datenbank.

2. Gleitende Zahlen

Mathematische Berechnungen unter Verwendung der in InfluxDB integrierten Funktionen führen zu Genauigkeitsfehlern. Es ist nicht so, dass dies etwas Ungewöhnliches wäre, aber es ist unangenehm.

In meinem Fall haben die Daten eine finanzielle Komponente, und ich möchte sie mit hoher Präzision verarbeiten. Deshalb plane ich, von kontinuierlichen Abfragen abzusehen.

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

Der Dienst verfügt über eine Tabelle mit täglichen Statistiken zu den Transaktionen. Für jeden Tag müssen alle Transaktionen dieses Tages gruppiert werden. Aber der Tag beginnt für jeden Benutzer zu unterschiedlichen Zeiten, was zu unterschiedlichen Transaktionssets führt. Es gibt 37 mögliche Verschiebungen für die Aggregierung der Daten nach UTC. 37 Varianten von Verschiebungen, für die die Daten aggregiert werden müssen.

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

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

Das Ergebnis der Abfrage wird jedoch fehlerhaft sein. Aus irgendeinem Grund beginnen die nach Tagen gruppierten Daten bereits im Jahr 1677 (InfluxDB unterstützt offiziell Zeiträume ab diesem Jahr):

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 meinem ersten Blick schienen sie wie Marketingmaterialien, aber mittlerweile denke ich, dass ein Teil der Wahrheit darin steckt.

Ich möchte von meinem Fall erzählen.

Der Dienst bietet eine API-Methode, die die Statistiken der letzten 24 Stunden zurückgibt. Bei den Berechnungen macht die Methode dreimal Anfragen an die Datenbank mit den folgenden Abfragen:

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

Erklärung:

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

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 vollständige Auslastung von sechs CPUs:

Dabei hatte der NodeJs-Prozess keinerlei Belastung.

Die Ausführungsgeschwindigkeit hat sich bereits auf 7-10 RPS verschlechtert: Während ein Kunde eine Antwort in 200 ms erhalten konnte, mussten 10 Kunden eine Sekunde warten. 25 RPS ist die Grenze, ab der die Stabilität leidet und den Kunden 500-Fehler zurückgegeben werden.

Mit dieser Leistung ist es unmöglich, Influx in unserem Projekt zu verwenden. Darüber hinaus können in einem Projekt, in dem das Monitoring vielen Kunden präsentiert werden muss, ähnliche Probleme auftreten und der Metriken-Server wird überlastet.

Fazit

Die wichtigste Erkenntnis aus den gewonnenen Erfahrungen ist, dass man in einem Projekt keine unbekannte Technologie ohne ausreichende Analyse verwenden sollte. Ein einfacher Blick auf offene Tickets auf GitHub hätte Informationen geliefert, um InfluxDB nicht als primäres Datenspeicher zu wählen.

InfluxDB schien gut für die Anforderungen meines Projekts geeignet zu sein, aber die Praxis hat gezeigt, dass diese Datenbank den Bedürfnissen nicht entspricht und viele Probleme aufweist.

Im Projekt-Repository ist bereits die Version 2.0.0-beta verfügbar. Es bleibt zu hoffen, dass die zweite Version bedeutende Verbesserungen bringen wird. Währenddessen werde ich die Dokumentation zu TimescaleDB studieren.

Quelle: habr.com