Wut, Feilschen und Depression bei der Arbeit mit InfluxDB

Wenn Sie eine Zeitreihendatenbank (timeseries db, Wiki) als Hauptspeicher für eine Website mit Statistiken verwenden, kann es zu großen Kopfschmerzen kommen, anstatt das Problem zu lösen. Ich arbeite an einem Projekt, das eine solche Datenbank verwendet, und manchmal brachte InfluxDB, das besprochen wird, allgemein unerwartete Überraschungen.

HaftungsausschlussHinweis: Die angezeigten Probleme gelten für InfluxDB 1.7.4.

Warum Zeitreihen?

Das Projekt besteht darin, Transaktionen in verschiedenen Blockchains zu verfolgen und Statistiken anzuzeigen. Konkret betrachten wir die Emission und Verbrennung von Stable Coins (Wiki). Basierend auf diesen Transaktionen müssen Sie Diagramme erstellen und Pivot-Tabellen anzeigen.

Bei der Analyse von Transaktionen entstand die Idee, die InfluxDB-Zeitreihendatenbank als Hauptspeicher zu verwenden. Transaktionen sind Zeitpunkte und passen gut in das Zeitreihenmodell.

Auch die Aggregationsfunktionen sahen sehr praktisch aus – sie eignen sich ideal für die Verarbeitung von Diagrammen mit einem langen Zeitraum. Der Benutzer benötigt ein Diagramm für ein Jahr und die Datenbank enthält einen Datensatz mit einem Zeitrahmen von fünf Minuten. Es ist sinnlos, alle hunderttausend Punkte an ihn zu senden – bis auf eine lange Verarbeitung passen sie nicht auf den Bildschirm. Sie können Ihre eigene Implementierung zur Erhöhung des Zeitrahmens schreiben oder die in Influx integrierten Aggregationsfunktionen verwenden. Mit ihrer Hilfe können Sie Daten nach Tagen gruppieren und die gewünschten 365 Punkte versenden.

Es war ein wenig peinlich, dass solche Datenbanken normalerweise zum Sammeln von Metriken verwendet werden. Überwachung von Servern, IoT-Geräten, allem, woraus Millionen von Punkten der Form „fließen“: [<Zeit> - <metrischer Wert>]. Aber wenn die Datenbank mit einem großen Datenstrom gut funktioniert, warum sollte dann ein kleines Volumen Probleme verursachen? Mit diesem Gedanken nahmen sie InfluxDB an die Arbeit.

Was ist in InfluxDB sonst noch praktisch?

Neben den genannten Aggregationsfunktionen gibt es noch eine weitere tolle Sache – Kontinuierliche Abfragen (Dock). Hierbei handelt es sich um einen in die Datenbank integrierten Planer, der Daten nach einem Zeitplan verarbeiten kann. Sie können beispielsweise alle Datensätze des Tages alle 24 Stunden gruppieren, den Durchschnitt berechnen und einen neuen Punkt in eine andere Tabelle schreiben, ohne Ihre eigenen Fahrräder zu schreiben.

es gibt auch eine Aufbewahrungsrichtlinien (Dock) – Einstellung zum Löschen von Daten nach einem bestimmten Zeitraum. Dies ist nützlich, wenn Sie beispielsweise die Auslastung der CPU eine Woche lang mit Messungen einmal pro Sekunde speichern müssen, im Abstand von einigen Monaten eine solche Genauigkeit jedoch nicht erforderlich ist. In einer solchen Situation können Sie Folgendes tun:

1. Erstellen Sie eine kontinuierliche Abfrage, um Daten in einer anderen Tabelle zusammenzufassen.
2. Definieren Sie für die erste Tabelle eine Richtlinie zum Löschen von Messwerten, die älter als dieselbe Woche sind.

Und Influx reduziert die Datengröße und löscht unnötige Daten von selbst.

Über gespeicherte Daten

Es werden nicht viele Daten gespeichert: etwa 70 Transaktionen und eine weitere Million Punkte mit Marktinformationen. Neue Einträge hinzufügen – nicht mehr als 3000 Punkte pro Tag. Es gibt auch Metriken für die Website, aber dort gibt es nur wenige Daten und sie werden gemäß der Aufbewahrungsrichtlinie nicht länger als einen Monat gespeichert.

Probleme

Während der Entwicklung und anschließenden Tests des Dienstes traten immer häufiger kritische Probleme beim Betrieb von InfluxDB auf.

1. Daten löschen

Es gibt eine Reihe von Daten mit Transaktionen:

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

Ergebnis:

Ich sende einen Befehl zum Löschen von Daten:

DELETE FROM transactions WHERE symbol=’USDT’

Darüber hinaus beantrage ich die Wiederherstellung bereits gelöschter Daten. Und Influx gibt anstelle einer leeren Antwort ein Datenelement zurück, das entfernt werden sollte.

Ich versuche, die gesamte Tabelle zu löschen:

DROP MEASUREMENT transactions

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

SHOW MEASUREMENTS

Ich sehe die Tabelle nicht in der Liste, aber die neue Datenabfrage gibt immer noch denselben Satz von Transaktionen zurück.

Bei mir ist das Problem nur einmal aufgetreten, da es sich bei dem Löschfall um einen Einzelfall handelt. Aber dieses Verhalten der Datenbank passt eindeutig nicht in den Rahmen „richtiger“ Arbeit. Später wurde Github als offen befunden Fahrkarte fast ein Jahr alt zu diesem Thema.

Infolgedessen half die Entfernung und anschließende Wiederherstellung der gesamten Datenbank.

2. Gleitkommazahlen

Mathematische Berechnungen mit den integrierten Funktionen von InfluxDB führen zu Präzisionsfehlern. Nicht, dass es etwas Ungewöhnliches war, aber unangenehm.

In meinem Fall haben die Daten eine finanzielle Komponente und ich möchte diese mit hoher Genauigkeit verarbeiten. Aus diesem Grund planen wir, auf kontinuierliche Abfragen zu verzichten.

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

Der Dienst verfügt über eine Tabelle mit täglichen Transaktionsstatistiken. Für jeden Tag müssen Sie alle Transaktionen für diesen Tag gruppieren. Der Tag beginnt jedoch für jeden Benutzer zu einer anderen Zeit, daher ist der Satz an Transaktionen unterschiedlich. UTC ist 37-Optionen Schichten, für die Sie Daten aggregieren möchten.

In InfluxDB können Sie bei der Gruppierung nach Zeit zusätzlich eine Verschiebung angeben, beispielsweise für die Moskauer Zeit (UTC + 3):

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

Das Abfrageergebnis wird jedoch falsch sein. Aus irgendeinem Grund beginnen die nach Tagen gruppierten Daten bereits im Jahr 1677 (InfluxDB unterstützt offiziell eine Zeitspanne 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 mit Vergleichen von InfluxDB und anderen Datenbanken. Auf den ersten Blick sahen sie wie Marketingmaterialien aus, aber jetzt denke ich, dass darin etwas Wahres steckt.

Lassen Sie mich Ihnen meinen Fall erzählen.

Der Dienst stellt eine API-Methode bereit, die Statistiken für die letzten XNUMX Stunden zurückgibt. Während der Berechnungen fragt die Methode die Datenbank dreimal mit den 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

Erklärung:

1. In der ersten Anfrage erhalten wir für jeden Coin die aktuellsten Punkte mit Marktdaten. In meinem Fall acht Punkte für acht Münzen.
2. Die zweite Anfrage erhält einen neuesten Punkt.
3. Der dritte fordert eine Liste der Transaktionen der letzten XNUMX Stunden an, es können mehrere Hundert sein.

Lassen Sie mich klarstellen, dass in InfluxDB automatisch ein Index nach Tags und nach Zeit erstellt wird, was Abfragen beschleunigt. In der ersten Anfrage Symbol ist ein Tag.

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

Gleichzeitig verursachte der NodeJs-Prozess überhaupt keine Last.

Die Ausführungsgeschwindigkeit verschlechterte sich bereits um 7–10 RPS: Wenn ein Client innerhalb von 200 ms eine Antwort erhalten konnte, mussten 10 Clients eine Sekunde warten. 25 RPS – die Grenze, unter der die Stabilität litt, 500 Fehler wurden an die Clients zurückgegeben.

Bei einer solchen Leistung ist es unmöglich, Influx in unserem Projekt zu verwenden. Darüber hinaus können in einem Projekt, bei dem die Überwachung vielen Clients demonstriert werden muss, ähnliche Probleme auftreten und der Metrikserver überlastet sein.

Abschluss

Die wichtigste Schlussfolgerung aus den gesammelten Erfahrungen ist, dass man eine unbekannte Technologie nicht ohne ausreichende Analyse in ein Projekt aufnehmen kann. Eine einfache Überprüfung offener Tickets auf Github könnte Hinweise darauf liefern, InfluxDB nicht als Hauptdatenspeicher zu verwenden.

Eigentlich sollte InfluxDB gut zu den Aufgaben meines Projekts passen, aber wie die Praxis gezeigt hat, wird diese Datenbank den Anforderungen nicht gerecht und bringt einiges durcheinander.

Version 2.0.0-beta ist bereits im Projekt-Repository zu finden, es bleibt zu hoffen, dass es in der zweiten Version deutliche Verbesserungen geben wird. In der Zwischenzeit werde ich die TimescaleDB-Dokumentation studieren.

Source: habr.com