Seite 1 von 1

Speicherbedarf / Komprimierung von Zeitserien

Verfasst: So Mai 24, 2020 11:43 am
von Robert_Mini
Hallo zusammen!

Ich hätte eine Frage bezüglich der Zeitserien: Ich schreibe mehrere Zeitserie mit Regenmengen. Die Monatssumme übernehme ich in der Logik nur 1x/Stunde. Im Zusammenspiel mit "c" on change sind dann aber die Lücken relativ lange.
Daher habe ich nun einen Trigger mit 10min ergänzt. Damit schreibt die Logik aber den gleichen Wert zwischendurch.

Wie macht das die influx Datenbank?
Werten die gleichen Werte zu mehreren Zeitpunkten komprimiert oder braucht die Zeitserie für Monat den gleichen Speicher wie die Zeitserie für den Tageszaehler, die alle Werte schreibt, d.h. gleiche Anzahl an Werten wie der Monatszähler, aber deutlich weniger gleiche Werte?

Wenn nein: @StefanW: Ist da längerfristig sowas wie eine (manuelle) Datenreduktion geplant zB. lösche Zwischenwerte < 1h Intervall o.ä.?

lg
Robert

Re: Speicherbedarf / Komprimierung von Zeitserien

Verfasst: So Mai 24, 2020 6:20 pm
von StefanW
Hallo Robert,
Robert_Mini hat geschrieben: So Mai 24, 2020 11:43 amIch hätte eine Frage bezüglich der Zeitserien: Ich schreibe mehrere Zeitserie mit Regenmengen. Die Monatssumme übernehme ich in der Logik nur 1x/Stunde. Im Zusammenspiel mit "c" on change sind dann aber die Lücken relativ lange. Daher habe ich nun einen Trigger mit 10min ergänzt. Damit schreibt die Logik aber den gleichen Wert zwischendurch. Wie macht das die influx Datenbank?
die Kompression der Zeitserien sind sehr effektiv, sie betragen weit über 95 %.

Erreicht wird dies unter anderem, weil von einem "Datensatz" zum nächsten jeweils nur die Differenzen gespeichert werden, nicht die Absolutwerte.
Ähnlich wie bei der Bewegtbildkompression, bei der nach einem Keyframe (welches das vollständige Bild beinhaltet) für das nächste Duzend Bilder nur die Unterschiede von Bild zu Bild gespeichert werden.

Bei Zeitserien wird somit der Unterschied im zeitlichen Intervall und im Wert zum vorhergehenden Eintrag abgelegt. Beispielsweise würde dann ein zeitlich exakt eingehaltener Intervall mit einem einzigen Bit ("0" für keine Änderung am Intervall) gespeichert und wenn der neue Wert zugleich dem alten entspricht, dann ist diese Differenz ebenfalls in mit nur einem Bit abspeicherbar ("0" für keine Änderung zum vorhergehenden Wert).

==> Gleiche Werte in gleichen Intervallen würden im Datenstrom damit nur zwei Bit benötigen.

Ob es exakt so in der Influx DB umgesetzt wurde kann ich nicht beschwören, aber so ähnlich wurde dies vor ein paar Jahren in einem Blogeintrag von Influx erklärt. Man hatte sich das aus dem Gorilla-Projekt von Facebook abgeschaut. Es wird modifiziert sein, aber dürfte in die Richtung gehen.

Differenzen in Intervall und Wert werden dann mit so wenig Bits wie möglich dargestellt, so dass auch leicht abweichende Werte sehr komprimiert gespeichert werden.

Kurz: Du musst Dir keine Sorgen machen.

Robert_Mini hat geschrieben: So Mai 24, 2020 11:43 amIst da längerfristig sowas wie eine (manuelle) Datenreduktion geplant zB. lösche Zwischenwerte < 1h Intervall o.ä.?
Wir entwickeln derzeit verschiedene Mechanismen der Kürzung von Zeitserien und selektiven Löschungen.

Das wurde und wird auch bereits im Produkt eingeführt.

- Mit der "V 1.6 IP 1" haben wir eine dreistufige Kürzung des KNX Logs bei knappen SSD-Speicher eingeführt. Das geschieht im Hintergrund vollautomatisch.

- Mit der "V1.6 IP3" - die in der letzten Mai Woche erscheinen sollte - wird die Zeitserien-DB für Dok-Mode-Daten auf 30 Tage gekürzt. Dies stellt einen automatischen Bereinigungsprozess dar.

- Ebenfalls eingeführt wird mit der "V1.6 IP3" auch eine Anzeige des Datenvolumens der von den Zeitseriendatenbanken genutzt wird. Damit kann jeder sehen, ob er sich den Grenzen seiner SSD nähert, was bei den aller wenigsten der Fall sein sollte.

- Künftig steht noch das Update auf eine neue Influx-DB Engine an, die schon seit Monaten im Labortest und auch bei einigen Kunden Im Testeinsatz ist. Hierdurch erfolgen Bereinigungen effektiver mit weniger Speicherplatz. Ich denke das wird mit den Insider Previews zur 2.0 eingeführt.

Ebenfalls bereits begonnene Entwicklungen sind das Kürzen bzw. Verdichten von Zeitreihen. Genaues zu Umsetzung und Mechanismus kann ich noch nicht sagen, weil Details noch erarbeitet werden müssen. Das muss sehr sauber und im laufenden Betrieb und ohne Störung erfolgen, was nicht trivial ist.

lg

Stefan