Schemaentwurf in influxdb

Question

Mein Anwendungsfall für influxDB ist das Speichern und Verarbeiten von Prozessdaten, die von verschiedenen SPSen kommen. Ich visualisiere diese Daten mit grafana. In einem ersten Pilotprojekt habe ich die Schemadesign-Richtlinien von influxDB verwendet, wobei ich einen generischen Messungsnamen verwendet habe und die verschiedenen Wertequellen mittels Tags getrennt habe.

Zum Beispiel, wenn ich 2 Pumpen in der ‚Säure‘ Pumpengruppe und 2 Pumpen im ‚caustic‘ Pumpengruppe, von denen mir den Druck Recond:

- pump_pressure {pump: pump_1, group: acid} 
- pump_pressure {pump: pump_2, group: acid} 
- pump_pressure {pump: pump_1, group: caustic} 
- pump_pressure {pump: pump_2, group: caustic} 

In meinem Anwendungsfall, das Ende -user möchte beispielsweise mit Grafana eigene Trends setzen können. Während diese Art der Datenaufzeichnung den Schemadesign-Richtlinien von influxDB entspricht (denke ich), ist sie für nicht technische Personen, die nicht gewohnt sind, mit SQL zu arbeiten und zu denken, sehr verwirrend.

Deshalb bin ich die Daten in der Art und Weise zu speichern versucht, dass sie verwendet werden, und ist die allgemeine Art und Weise in ähnlichen Produkten arbeiten (Historiker):

- ACID_pump_1_pressure 
- ACID_pump_2_pressure 
- CAUSTIC_pump_1_pressure 
- CAUSTIC_pump_2_pressure 

Dies würde es viel einfacher für den Endbenutzer, um Trends zu machen, wie 1 Messung = eine Datenquelle, und sie müssen sich nicht um where und group by Klauseln sorgen.

Kann mir jemand auf einige Hinweise hinweisen, was der Einfluss der letzteren auf influxDB Leistung und Speicher wäre. Nehmen die Daten auf diese Weise mehr Platz ein? Bitte beachten Sie, dass die letztere Methode zu einigen tausend Messungen führen kann, aber ihre Kardinalität wäre alle 1.

Answer 1

Es gibt keinen Grund, warum Sie das nicht tun können, wenn es passt Ihren Anwendungsfall besser. Die Richtlinien, mit denen Sie beginnen, sind vorhanden, da sie die volle Leistungsfähigkeit der Tagging-Funktion von InfluxDB ermöglichen.

Es gibt keine Auswirkungen auf die Leistung oder den Speicher. Intern erstellt InfluxDB eine neue Serie basierend auf jedem eindeutigen "Schlüssel", wobei der Schlüssel die Kombination aus Messungsname und Tag-Schlüssel/Wert-Paaren ist.

dh jedes davon ist eine separate Serie:

pump_pressure,pump=pump_1,group=acid 
pump_pressure,pump=pump_2,group=acid 
pump_pressure,pump=pump_1,group=caustic 
pump_pressure,pump=pump_2,group=caustic 

auch, jede davon ist eine separate Serie:

ACID_pump_1_pressure 
ACID_pump_2_pressure 
CAUSTIC_pump_1_pressure 
CAUSTIC_pump_2_pressure 

EDIT, Quelle: ich InfluxData arbeiten

EDIT 2, das heißt, ich stimme auch vollständig mit @srikanta und ich würde empfehlen, die Tags zu halten, sondern eine andere Lösung für die Interaktion mit den Benutzern der db (oder Erziehung) zu finden.

Answer 2

In der Tat können Sie mit diesem Ansatz gehen. Dies ist jedoch nicht skalierbar. Was passiert, wenn die Anzahl der verwendeten Pumpen steigt? Dieser Ansatz funktioniert auch dann, wenn die Anzahl der Pumpen der Anzahl der Zeitreihen entspricht. Es wird jedoch ein Schmerz zu verwalten.

Wenn das Problem, die Interaktion des nicht technischen Benutzers mit den SQL-Abfragen zu vermeiden, dann sollte ein anderer Ansatz in Betracht gezogen werden und nicht das "Schema" der Datenbank zu ändern.

Einige weitere Einblicke ->https://blog.zhaw.ch/icclab/influxdb-design-guidelines-to-avoid-performance-issues/