Wie Messwerte sinnvoll komprimieren und in Datenbank schreiben (Influxdb 2)

[Rach78]

Hallo, ich habe hier Messwerte Temperatur etwa im 5 Minuten Abstand

Jetzt möchte ich diese Messwerte von der Auflösung her verkleinen zB nur jede Stunde den Mittelwert abspeichern.
Das geht in InfluxDB auch.

Er macht dann quasi Blöcke zu jeweils eine Stunde und speichert zB den Mittelwert den die Temperaturen zwischen 15 und 16 Uhr hatten ab.
Mein Problem ist jetzt nur der Zeitstempel. In der Default Einstellung würde er diesen Mittelwert den Zeitstempel mit 16Uhr verpassen, was für mich als "Neuling" jetzt erstmal irgendwie merkwürdig ist weil es ist ja der Mittelwert zwischen 15 und 16Uhr. Wäre es nicht sinniger als Zeitstempel 15:30 herzunehmen? Oder ist es "normal" dass das so gemacht wird?

Ich denke jetzt auch weiter zB wenn ich mir den Wochendurchschnitt abspeichern will. Dann würde er als Zeitstempel ja ebenfalls Mon 0:00 hernehmen. Für mich ist das wenig nachvollziehbar.

Oder ist das normal und man verschiebt nacher einfach nur die X Achse entsprechend sodass der Mittelwert auch Zeitlich in die Mitte fällt?

Mit

aggregateWindow(every: 1h, fn: mean)

Würde er jeweils die Mittelwerte aus jedem 1h Block bilden.
Mit timeSrc: "_start" könnte man als Timestamp die startzeit statt die endzeit nehmen.
Aber dann wäre der Unterschied nur der dass sich 15:00 auf die Daten von 15 bis 16 Uhr beziehen. Und nicht dass 16Uhr meint die Daten zwischen 15 und 16. "Letzteres" ist aber das Standardverhalten.
Ist das so praxis?

 

[madmax2010]

schau mal nach influxdb downsampling.

Edit: nvm.. hat du vermutlich schon gelesen.
Es gibt X Downsampling Methoden der Mittelwert passt bei vielen am besten.
Bei Temperaturen im Raum, ist ja eine eher geringere Änderungsrate zu erwarten. Bei CPU / Traffic verlierst du durch einen Mittelwert Lastspitzen nicht komplett.Wenn du bspw. um 15:40 100x mehr last als sonst hast,sieht man das in einem einzelnen Sample nicht

Ich denke jetzt auch weiter zB wenn ich mir den Wochendurchschnitt abspeichern will. Dann würde er als Zeitstempel ja ebenfalls Mon 0:00 hernehmen. Für mich ist das wenig nachvollziehbar.

du musst eine Sinnvolle Auflösung nehmen. Jeder Fall ist anders

 

[Rach78]

du musst eine Sinnvolle Auflösung nehmen. Jeder Fall ist anders

Ich will später durchaus auch tägliche Temperaturmittelwerte haben. Nur wie gesagt nach dem Downsampling habe ich da immer als Zeitstempel dann das Ende als Zeit.

Auch bei meinen Gaswerten ist das nicht Ideal. Man muss es halt wissen dass 15Uhr eigentlich 14-15Uhr meint...

Als Anfänger würde ich halt sagen dass der Durchschnitt von 0 bis 8Uhr am besten den Zeitstempel 4Uhr bekommen sollte da er in der Mitte auch liegt...

 

[abcddcba]

Ist das so praxis?

fuer mich ist das so sinnvoll, deine Einheit sind ja Zeitfenster, _start und _stop bekommst du da ja nach wie vor. Was du danach damit machst ist dann doch dir ueberlassen, oder nicht? Du kannst doch jederzeit noch eine Spalte fuer deinen gewuenschten Timestamp mit 15:30 hinzufuegen, wenn dir das lieber ist.
Oder verstehe ich dein Ziel falsch?

 

[simpsonsfan]

Man muss es halt wissen dass 15Uhr eigentlich 14-15Uhr meint...

Als Anfänger würde ich halt sagen dass der Durchschnitt von 0 bis 8Uhr am besten den Zeitstempel 4Uhr bekommen sollte da er in der Mitte auch liegt...

Eben. Man muss halt wissen, wie man es definiert hat, dann ist es ganz egal. Jeder Wert bezieht sich immer auf ein Intervall. Ob der Wert "Zeitstempel" jetzt am Ende, in der Mitte, am Anfang des Intervalls oder 3,28h später liegt, ist dann wumpe.

Ich finde es zumindest ebenfalls nachvollziehbar, wenn der Zeitstempel am Ende des Intervalls liegt, denn vorher konnte der Wert unmöglich generiert werden. Somit auch gut argumentierbar.

 

[BeBur]

Persönlich finde ich den Zeitstempel-Mittelwert herzunehmen am seltsamsten. Da treten vermutlich auch Unregelmäßigkeiten auf, je nach Auflösung (also Sekunden, Millisekunden, ...). Bei einem Zeitpunkt/Zeitstempel würde ich auch eher nicht einen Mittelwert vermuten, weil das ein aus den Daten abgeleiteter/berechneter Wert ist und ein Zeitstempel sich eher auf konkrete Ereignisse bezieht (Start der Messungen / Ende der Messungen). Dann sagt der Mittelwert ja auch gar nichts über den Zeitraum aus, die Information fehlt komplett und muss vermutet werden und da sehe ich Potential für fiese Bugs. Zuletzt frage ich mich, ob die Information überhaupt benötigt wird. Interessant ist doch eher der Zeitraum der Messungen und der Abstand der Messungen zueinander.
Fazit: Lass es einfach so und speichere ggf. noch mehr Informationen ab, falls gewünscht.

 

[Rach78]

Das problem ist halt wenn ich das ganze visualisiere ich den Datenpunkt halt an der falschen Stelle habe. Wenn ich zB die Durchschnittstemperatur für den Monat Januar nehme, setzt er mir als Timestamp den 1. Februar 0:00Uhr.

Frage mich halt ob das "normal" ist und in der Praxis dann einfach die Achse verschoben wird damit er mittig im Diagramm auftaucht.
Theoretisch müsste ich die Zeit Achse also x, dann ja um 15 Tage verschieben

 

[TorenAltair]

Ich finde die Vorgehensweise des Programms sinnig. Der Mittelwert wird ja um 16 Uhr, bzw. am 1.2. gebildet und nicht um 15.30 Uhr oder am 15. Januar. Sonst würden ja rein datenlogisch zukünftige Werte mit einfliessen.

 

[simpsonsfan]

@Rach78 Ja, würde eher sagen, du visualisierst hier falsch.
Evtl. solltest du da auch nicht einfach ein linear verbundenes XY-Diagramm nehmen, sondern lieber eine Stufenfunktion.
Heißt, für den ganzen Januar ist deine Linie (waagrecht) auf dem Januarwert, am ersten Februar springt sie dann auf den Februarwert usw.

Ist aber ja eher nachgelagert. Der Timestamp für die Mittelwerte ist so schon sinnvoll.

 

[BeBur]

Das problem ist halt wenn ich das ganze visualisiere ich den Datenpunkt halt an der falschen Stelle habe. Wenn ich zB die Durchschnittstemperatur für den Monat Januar nehme, setzt er mir als Timestamp den 1. Februar 0:00Uhr.

Generell ist es selten so, dass die komplette Programmlogik in der Datenbank abgebildet wird. Es ist üblich, dass die Software sich Daten aus der Datenbank zieht und diese dann für den jeweiligen Anwendungsfall aufbereitet bevor sie angezeigt werden.
Wenn du aber schon weißt, dass du sonst die Achse um einen Monat verschieben musst, dann speicher in der Datenbank doch einfach den Startzeitpunkt ab. Das hast du ja selber schon als Alternative beschrieben. Oder einfach das, was für deinen Fall sinnvoll ist.

 

[kuddlmuddl]

Nur als zusätzliche Ideen:
Du könntest noch einige wenige weitere Werte erhalten, wie zB
min, max, Median, Mittelwert, Standardabweichung, Quartile, Histogramme, ...
Je nachdem, was du hinterher vor hast kann vieles davon spannend sein.

 

[Rach78]

Ich finde die Vorgehensweise des Programms sinnig. Der Mittelwert wird ja um 16 Uhr, bzw. am 1.2. gebildet und nicht um 15.30 Uhr oder am 15. Januar. Sonst würden ja rein datenlogisch zukünftige Werte mit einfliessen.

Ja das stimmt schon. Das Problem ist halt nur dass man dann den 1.2 0:00 als Timestamp hat für den Mittelwert Januar. Das müsste man dann nacher wieder verschieben was Aufwand bedeutet und vielleicht andere Probleme nach sich zieht von denen ich jetzt noch nicht weiß dass ich sie haben werde. Werde daher jetzt erstmal die Option timeScr: "_start" benutzen dann setzt er mir hier den 1.1 0:00 sprich den Anfang. Zumindest für die Darstellung wo es dann später nicht auf Tage ankommt sondern nur Monate macht es mehr Sinn weil es mir dann erspart die ganze Geschichte jedesmal noch um einen Monat wieder zu verschieben. Mir die Tage anzuschauen macht ja ohnehin kein Sinn bei einem Messwert den ich nur in der Auflösung einmal pro Monat habe. Durch timeSrc: "_start" würde es dann auch so sein dass der ganze Januar diesen Wert hätte und erst im folge Monat dann durch den neuen Wert abgelöst wird.

Werde die Rohwerte aber auch vorerst behalten falls ich merken sollte dass das doch eine doofe Idee war. Spiele da im Moment ja noch etwas rum.

Es kommt wohl drauf an was man speichert. Bei absoluten Zählerständen für Januar wäre es vermutlich dumm hier den startwert herzunehmen sondern da würde es dann wieder besser passen mit dem Endwert. Hier wäre die aggregationwindow funktion dann aber auch ohnehin nur "last". Also alles ignorieren bis auf den letzten Wert der im Zeitfenster liegt.

 

[r0b0t]

Möglicherweise handelt es sich nur um ein Denkproblem. Vielleicht hilft folgende Vorstellung weiter. Eine Verallgemeinerung deines Falles wäre die Darstellung des gleitenden Durchschnitts der letzten n Messwerte in einer Zeitreihe. Wie sähe da die Zuordnung von Mittelwerten zu Zeitpunkten aus?

Nehmen wir mal an, du hast einen Temperaturwert zu jeder vollen Stunde. Zur Darstellung eines Diagramms oder einer Kurve, die den gleitenden Durchschnitt der jeweils letzten 24 Werte darstellt, berechnest du jeweils den Mittelwert der letzen 24 Messwerte und ordnest ihn jeweils dem Zeitpunkt des letzten Messwertes zu. Klar, dass dann der letzte dargestellte Wert um 0:00 Uhr das Datum des aktuellen Tages bekommt, obwohl 23 der Messwerte, die in den Durchschnitt einfließen vom Vortag stammen. Aber im Fall des gleitenden Durchschnitts wäre dies die sinnvollste Wahl des darzustellenden Zeitpunkts. Jede Verschiebung dieses Zeitpunkts auf der Zeitachse würde nur Verwirrung stiften.

Um nun vom allgemeinen Fall des gleitenden Durchschnitts zu deinem Scenario zurückzukommen, in dem du etwa nur die Werte zur Uhrzeit um 0:00 Uhr betrachtest, ist deine Darstellung dann einfach nur ein Spezialfall des allgemeinen Falles des gleitenden Durchschnitts. Somit ergibt sich der zu wählende Zeitpunkt einfach aus dem Übergang vom allgemeinen Fall zum Spezialfall und umgekehrt.

 

[Rach78]

Ja das stimmt. Der letzte Zählerstand für den Januar kann ja auch erst mit Abschluss des Januars und Anfang des Februar bestimmt werden.
Habe mir jetzt grad überlegt daher einfach nur in der Darstellung die Achse dann um einen Monat zu verschieben. Dann kann der Timestamp in der Datenbank so bleiben wie influxdb ihn auch Standardmäßig setzt. Und die Zuordnung geschieht dann aus dem Kontext.
Im Grunde steht in der Datenbank dann in dem Fall halt der Zählerstand wie er am 1.2 um 0:00 war.
Den Monatsverbrauch muss ich mir dann Anhand der Differenz vom Zählerstand vom 1.1 um 0.00 und 1.2 um 0.00 errechnen um zu wissen wieviel im Januar verbraucht wurde..
Zumindest bei Zählerständen macht das so schonmal Sinn.