InfluxdB Daten Aggregation/Reduktion und Zeitstempel?

[Pete0815]

Hallo,
für private Zwecke der Hausautomatisierung nutze ich seit Kurzem eine InfluxdB für die Speicherung von Sensorwerten. Die Performance durch die Speicherung in zeitlicher Abfolge habe ich bereits positiv bemerkt. Jedoch ist es nicht wirklich sinnvoll zB Sensordaten die alle paar Sekunden (zB Stromverbrauchsleistung) geliefert werden über einen ganzen Monat oder sogar später Jahr abzufragen und damit Berechnungen durchzuführen.

Nun würde es mir reichen, wenn die Daten auf zB 1h komprimiert werden. Hierzu müßte ich über 1h Das Integral bilden, ok. Aber das Ergebnis wiederum in die Datenbank zurück schreiben und ggf. alle Sekundenwerte löschen. Bzgl. des Konzeptes ist der Zeitstempel für mich ein Problem. InfluxDB speichert, soweit ich es weiß, automatisch den Zeitstempel und dieser ist auch nicht "manipulierbar". Wenn ich mir also später zB auch mal ein Diagramm ansehe ist es wichtig, dass der Zeitstempel des Integrals für 1h auch den Zeitstempel besitzt dieser Stunde. Selbes Problem bzgl. Woche und Monat. Tage kann ich noch direkt in der Abfrage bewältigen auch wenn es auf die Performance geht.

Lasse ich eine Berechnung zyklisch jede Stunde ausführen zum Komprimieren bin ich mit dem Zeitstempel der Speicherung auf jeden Fall in der nächsten angebrochenen Stunde.

Lässt sich sowas als mit einer solchen Datenbank gar nicht realisieren?

Thx!

 

[Dukel]

Sowas kann Influx DB von sich aus und du musst nichts anpassen.
InfluxDB Data Retention
Manage your database using InfluxQL | InfluxDB OSS 1.8 Documentation

 

[Pete0815]

Vielen Dank! Hilft mir sehr und knobel da ständig am Konzept und ob dies überhaupt sinnvoll möglich ist.
Aktuell grübel ich über:
-Bekomme ich 2 Datenbanken (Shortterm + Longterm) ans das System angebunden für Datenein und ausgabe aber auch ins Backupkonzept automatisiert integriert.
- Für die kontinuierliche Daten Aggregation ist explizit der Datenpunkt zu definieren. Bleibt also für immer die Notwendigkeit die Datenpunkte manuell zu pflegen in der Konfiguration, damit sie auch im Langzeitarchiv landen und nicht einfach im Kurzzeitarchiv gelöscht werden.

 

[Pete0815]

Hi,
habe nun 2 Datenbanken realisiert mit influxDB (shorterm + longterm) und lasse durch eine Continuous Query die Daten verdichtet in die Longterm Datenbank schreiben. Funktioniert fast gut. Problem ist ähnlich wie am Anfang. In Shortterm stehen die Sensordaten in W(att). Durch Nutzung der Aggregationsfunktionen lasse ich bei der Verdichtung zu Longterm das Integral bilden und das Ergebnis in kWh eintragen. Jetzt kommt der Zeitstempel wieder ins Spiel. Die Zeitperiode zur Verdichtung (zB 15 Minuten) bildet das Integral von "Jetzt" bis "Jetzt"-15Minuten. Der Zeitstempel in der Datenbank longterm wird aber zu Begin der 15Minuten übernommen also "Jetzt"-15Minuten. Die Produktion oder der Verbrauch hat zu diesem Wert aber er "Jetzt" statt gefunden. Somit eine Verfälschung. Bei 15M evtl. zu vernachlässigen aber setzt man größere Zeitperioden (Wochen, Monate) werden die Folgen erheblich.

Habt ihr dazu eine Idee?
Die Continuous Query lautet:

CREATE CONTINUOUS QUERY "15mPWRACGes" ON "longterm"
BEGIN
SELECT INTEGRAL("value") /3600000 AS value
INTO longterm.autogen."javascript.0.scriptEnabled.PV.WRPACges"
FROM shortterm.autogen."javascript.0.scriptEnabled.PV.WRPACges"
GROUP BY time(15m),*
END


Allgemein ist das doch generell ein Problem bei der Verdichtung. Bilde ich zB auch Summen oder Mittelwerte ändert sich durch diese Art der Verdichtung die Sichtweise auf die Daten im Bezug zum Zeitstempel. Ursprünglich zeigen Einträge in der Datenbank Werte für den Zeitraum vor Ihnen oder genau zu diesem Zeitpunkt. Nach der Verdichtung entsprechen die Werte aber der Zeit nach dem Zeitstempel. Wechsel von "Report/Bericht" zur "Vorhersage" Sichtweise. Mmmh

 

[Walter]

Das Problem hast Du ja jetzt auch schon. In der aktuellen DB werden die Werte ja auch nicht in Millionestelsekunden Genauigkeit eingetragen, auch da wird ja in Wirklichkeit also schon verdichtet?

Man muss sich halt einmal klar werden, auf welcher Zeitebene man verdichten will, nicht zu grob und nicht zu fein, es ist immer ein Abwägen von Speicherplatz/Performance und Genauigkeit.

 

[Pete0815]

Ich sag mal Jaein. Die ursprüngliche Genauigkeit hängt mit der Abtastrate (Stützstellen) und benötigten Zeit für eine Verarbeitung zusammen. Das ist ein Geschichte aus der Messung heraus.

Den Fehler/Ungenauigkeit durch die jetzige Verdichtung bekomme ich aber nicht durch die Messung sondern durch eine Verschiebung der Messdaten auf der Zeitachse. Würde man den Zeitstempel des letzten Datenbankeintrages übernehmen (und nicht den Ersten) für die Verdichtung ist der zusätzliche Fehler durch die Verdichtung gleich Null.

Den Unterschied finde ich erheblich und wirft für mich die Frage auf, ob man deswegen diese Aggregate Kalkulationen so überhaupt bei einer Verdichtung nutzen sollte/kann. Bzw. Ob ich hier einen Fehler in der Umsetzung mache und es wesentlich besser zu lösen ist.

Habe hierzu etwas für einen Offset für den Zeitstempel Grouped By gefunden, aber wenn ich es richtig verstehe, beeinträchtigt dass nicht nur den Zeitstempel sondern auch die Datenerfassung beim Verdichten. Somit denke ich nicht wirklich hilfreich in diesem Fall.

 

[6a5h4]

Ich habe auch so ein Problem festgestellt. Ich bilde eine Monatssumme (von >=2023-07-01 00:00:00 bis < 2023-08-01 00:00:00) in einer monatlichen DB ab und leider wird für den Zeitstempel der Zeitstempel des ersten Datensatzes genutzt, obwohl man am 2023-08-01 um 02:02:42 Uhr speichert, wird der Zeitstempel des ersten Datensatzes genommen (2023-07-01 00:00:00) --- warum das denn?? Es hätte "2023-08-01 02:02:42" drin stehen müssen. In der graphischen Darstellung bei Grafana ergibt sich einen Versatz um einen Monat nach vorn! (2023-06) --- völlig daneben und inakzeptabel! Sowas geht gar nicht. Es kann doch nicht sein, das ich jetzt einen Workaround basteln muss ( zusätzliches Feld mit String YYYY-MM ) um Monat für Monat auseinander halten und in Grafana richtig darstellen zu können. Und ja, ich benutze und bleibe bei InfluxQL, und für den monatlichen Zyklus arbeitet ein BASH-Skript und macht den notwendigen INSERT, da INFLUXQL keine Zeiteinheit (MONAT) kennt. 4 Wochen ist nicht ein Monat... passt net. Traurig, das eine Zeitreihendatenbank, deren steckenpferd die Zeitreihen sind, sich solch gravierende Schnitzer leistet. NEIN, ich werde nicht zu FLUX wechseln. Das ist KEINE Option... Hat jetzt noch jemand eine Lösung, eine Ursachenbekämpfung?