Fragen zu den Datentypen und Protokollierung der Zeitserien des TW-Servers

[jockel]

Ja, aber das muss ich am Wochenende erst heraussuchen.

[Robert_Mini]

Danke!

[Robert_Mini]

habe nun einen Artikel dazu in der knowledge base angelegt:
3.4 Speicherbedarf von Zeitreihen (app.php/kb/viewarticle?a=32).

Bräuchte zur Vervollständigung noch den Speicherbedarf je knx-Telegramm, das gespeichert wird.

Lg
Robert

[StefanW]

Hallo Robert,

der Richtwert von 14 Byte pro Datenpunkt gilt für KNX Telegramme beim Logging gleichermaßen wie für Zeitreihen von Werten.

Ganz genau kann man das nicht berechnen, weil die Influx-DB sehr effizient komprimiert. In unseren Versuchen haben sich diese 14 Byte pro Speicherpunkt für Zeitstempel, Wert und Attribute als der durchschnittlicher Wert ergeben.

lg

Stefan

[StefanW]

Hallo Robert,

Danke für Deine Arbeit, habe mir noch erlaubt, den Beitrag über die Zeitreihen zu überarbeiten, ich hoffe Du bist damit einverstanden.

lg

Stefan

[Chris M.]

der Richtwert von 14 Byte pro Datenpunkt gilt für KNX Telegramme beim Logging gleichermaßen wie für Zeitreihen von Werten.

Die Frage nach dem Speicherverbrauch kommt immer wieder, was ich gut verstehen kann.

=> Vorschlag für neues Feature: Könnte der TW nicht hochrechnen (Summe über alle Datenpunkte * 14 Byte * Rate) und irgendwo anzeigen: "Hochrechnung: aktueller Speicherbedarf 123 kB/Tag" o.ä.?

[Robert_Mini]

Danke für Deine Arbeit, habe mir noch erlaubt, den Beitrag über die Zeitreihen zu überarbeiten, ich hoffe Du bist damit einverstanden.

Kein Problem. Ihr seid der Hersteller und ich bin froh, wenn der Inhalt von euch und der Community (zwecks Verständlichkeit) quergelesen werden.

Eventuell habe ich das Thema Datenspeicherung bisher auch falsch verstanden. Ich dachte, dass dies Teil der Komprimierung ist, dass gleiche Werte mit unterschiedlichen Zeitstempel innerhalb einer timeseries ignoriert werden. Laut deinem Text muss man dafür aber selbst sorgen, in dem man “bei Änderung” in der Regel angibt.

Muss mir deinen Text nochmal genau lesen, da für mich der Inhalt nicht mehr nur Zeitreihen betrifft sondern auch das Telegramm-Logging. Dann passt zumindest der Titel des Kapitels nicht mehr ganz und eventuell die Überschriften.

Robert

[StefanW]

Könnte der TW nicht hochrechnen (Summe über alle Datenpunkte * 14 Byte * Rate) und irgendwo anzeigen: "Hochrechnung: aktueller Speicherbedarf 123 kB/Tag" o.ä.?

Die Rate kennen wir ja nicht.

- Bei KNX kommt das Paket wenn es kommt, das ist woanders eingestellt
- Überall wo die Rate von der Änderung des Wertes abhängt, können wir das gar nicht prognostizieren.

Was wir aber eines Tages einbauen werden, dass ist eine Überwachung des Speicherplatzes und des Zuwachses und eine Prediktion, wann es zuviel wird bzw. dann eben eine automatische Löschung. Aber ehrlich gesagt, dürfte das Problem erst in einigen Jahren bei 5% der Kunden auftreten, daher ist das heute keine wichtige Sache.

lg

Stefan

[Robert_Mini]

Mir würde hier schon reichen, wenn der belegte Speicher als Zeitreihe existieren würde.
Da kann jeder, den das Thema interessiert, selbst grob hochrechnen.
Darauf könnte später auch die Prediktion basieren.

Robert

[jockel]

Mir würde hier schon reichen, wenn der belegte Speicher als Zeitreihe existieren würde.

Ja, das halte ich für eine gute Idee. In Postgresql könnte man so etwas als View in der Datenbank selbst realisieren, keine Ahnung, ob es bei Influx etwas ähnliches gibt.

Hinzugefügt nach 1 Stunde 28 Minuten 7 Sekunden:

Kannst du noch posten, wieviele 1wire Messungen das bei dir sind?

Jetzt habe ich mal etwas mit grep gespielt und komme auf folgende Anzahl an Items in der Influx Datenbank
Dimmer: 22
Switcht: 153
Rollershutter: 36
Number 206
Color: 12

In den "Number" Items sind auch die 1-Wire Sensoren enthalten, zusätzlich aber auch andere Zahlenwerte. Alle Werte erden bei jeder Änderung und zusätzlich noch mindestens 1x pro Tag gespeichert. Installiert habe ich influx Mitte Januar 2017. In der Zwischenzeit sind noch einige Items hinzugekommen und auch weggefallen, aber gegenüber der Gesamtmenge wohl zu vernachlässigen. Damit belegt das Verzeichnis mit dem Datenbank aktuell 245MB auf der Festplatte (du). Das schließ dann aber auch den gesamten Overhead mit ein

Zum Vergleich meine PostgreSQL Datenbank. Darin sind zur Zeit 481 Items gespeichert. Die Datenbank hat schon einige Migrationen hinter sich, erst MySQL, dann SQLite und seit August 2017 PostgreSQL. Die ältesten Einträge sind von Dezember 2014, die Fluktuation dürfte merkbar größer sein als bei der Influx Konfiguration. Auch in PostgreSQL werden alle Werte bei Änderung und 1x täglich gespeichert. Damit ist die Datenbank aktuell, laut PostgreSQL query, 1365 MB groß.