Welche Datenbank nehmt Ihr für Langzeitaufzeichnungen?

[ttrepper]

Hi all,

welche Datenbanken (bzw. Typen) nehmt Ihr für Langzeitaufzeichnungen?
(RDBMS, Key-Value, etc) Welche Software hat sich für Auswertungen bewährt?

Herzlichen Dank & lb. Gr.
Thomas

[supermaz]

Also ich logge alles von OpenHAB nach MySQL. Die Datenbank ist gut, stabil und kostet nichts und ich hatte sie sowieso schon laufen.

[multimedia]

Hallo Thomas,

Schau doch mal das neue proServX an. Das Softwarepackage für Synology ist kostenlos im proServ support Forum. Es basiert übrigens auf openHAB.
Vermutlich hast Du schon alles was du brauchst, denn du hast doch schon einen proServ.
Siehe hier: https://knx-user-forum.de/proserv/39...-synology.html

Viele Grüsse
Christian

PS: Du kannst die Software auch auf jedem anderen Rechner laufen lassen, für die Synology haben wir halt zusätzlich ein Package gemacht.

[tkuehne]

bei mir läuft mariaDB (mysql-fork) auf meiner Synology-NAS. Dort lasse ich alles reinloggen. Datenquellen zur Zeit openHAB (Wärmepumpenwerte von luxtronic2, KNX-Kenngrößen) und volkszähler (Stromverbrauch/Zählerstänge).

[makki]

rrdtool

Makki

[ttrepper]

Danke allen schonmal. Was habt Ihr ungefähr für einen Speicherverbrauch? (Ganz grob XXX Einträge entsprechen YYY MB/GB o.ä)

[Chris M.]

Keine Ahnung, hab bei meinen RRDs noch nicht nachgesehen.
Aber: RRD ist darauf hin optimiert Langzeitaufzeichnungen zu machen. Und das mit konstantem Speicherverbrauch

(Trick: zeitlich hierachische Datenspeicherung mit geeigneter Reduzierung der alten Daten)

[wuestenfuchs]

Die Daten werden bei mir über das WireGate erfasst und per SNMP bzw. ein eigenes Plugin an Zabbix (ist ein Monitoring-Tool) geschickt und dort langzeitgespeichert (30 Tage Einzelwerte, danach - vorerst - 10 Jahre stündliche min/max/avg-Werte). So kann ich recht einfach übersichtliche Auswertungen erstellen.
Datenverbrauch kann ich nicht sagen, da ich mit der selben Instanz von Zabbix auch meine IT-Infrastruktur überwache.

Aufgezeichent werden Temperatur, Helligkeit, Betriebsstunden, Stromverbrauch, Stromaufnahme, Stromverbrauch pro Monat, Bus-Statistiken, Alarme und ausgewählte Stati (An/Aus)... insgesamt rund 350 items.

[knxfindichgut]

Ich benutze gerne InfluxDB, eignet sich sehr gut für die Speicherung von Messwerten und hat eine gute Schnittstelle zu Grafana. Andere passende Möglichkeit, wie schon vorher erwähnt: rrdtool
Grüße,
Stefan

[heckmannju]

Ich benutze gerne InfluxDB, eignet sich sehr gut für die Speicherung von Messwerten und hat eine gute Schnittstelle zu Grafana. Andere passende Möglichkeit, wie schon vorher erwähnt: rrdtool
Grüße,
Stefan

Und was ist der Vorteil von InfluxDB das sich die für die Speicherung der Messerte eignet?

[knxfindichgut]

sieh mal unter https://influxdata.com/time-series-platform/influxdb/ und https://influxdata.com/what-is-time-series-data/ nach, da findest du das Wichtigste zu time-series-data
Grüße, Stefan

[heckmannju]

Hi,
läuft das auf einem kleinerne System wie einem PI überhaut

laut https://docs.influxdata.com/influxdb...rdware_sizing/ Low load recommendations

• CPU: 2-4
• RAM: 2-4 GB
• IOPS: 500

nee spass... ich hab schon gesehen das es hier bei um 5000 writes pro sec geht. Was sind den die anforderungen im Hausbereich. Schätze mal 1-2 writes pro sekunde wird da schon viel sein.

Wieviel Resourchen RAM/CPU braucht den die garafanaDB in disem Fall so über den Daumen?

Viele Grüsse
Jürgen

[evolution]

Was sind den die anforderungen im Hausbereich. Schätze mal 1-2 writes pro sekunde wird da schon viel sein.

Beim KNX-Bus geht man vereinfacht von max. 50 Datenpakete/Sekunde aus. Bei der Aufzeichung der Daten von x Linien müsste man die max. anfallende Datenflut mit x multiplizieren. Diese Überschlagsrechnung der max. Datenmenge im peak würde ich zur Bestimmung der Schreibleistung und Rechenleistung heranziehen, auch wenn man im EFH durchschnittlich meist nicht über 1-3 Telegramme/Sekunde kommt.

[heckmannju]

At evolution das ist ein Fehler den viele beim sizing machen die unrealistischen Fälle nehmen. Ausserdem musste ich mit deinem Ansatz auch noch alle weitern Möglichkeiten aus denken. Wo sonst noch Daten herkommen könnten. Im Prinzip reicht es mir aber von jemanden der sowas hat zu wissen vievil cpu und Ram der DB Prozess braucht.
VG juergen

[evolution]

At evolution das ist ein Fehler den viele beim sizing machen die unrealistischen Fälle nehmen.

Unrealistisch ist das nicht, nur das maximal mögliche. Wenn die durchschnittliche Telegrammrate e.g. 1 Telegramm/Sekunde beträgt und die durchschnittliche Buslast somit bei grob 2% liegt, heisst das noch lange nicht, dass dies durchgängig ist. Im Gegenteil - oftmals liegt die max. Buslast bei mehr als 60% (oder gar 80%) in der Spitze. Man mag doch auch die Daten wegschreiben können, die über den Durchschnittswert hinaus gehen. Lediglich bei der Größe der DB kann man vom Durchschnitt (+Reserve) ausgehen.