Überlegung auf Influx umzusteigen
-
@michl75 Mysql ist eine Datenbank, die alle Arten von Daten verarbeitet. Influxdb ist da spezieller und prädestiniert für Daten, wie sie von iobroker kommen. Also immer Timestamp & Wert. Vermutlich wird man im normalen Gebrauch keinen Unterschied merken und nur in Benchmarks sehen, wenn man die gegeneinander laufen lässt. Aber wenn es schon eine Datenbanksoftware gibt, die die Daten ideal verarbeiten kann, warum dann nicht die nehmen.
Gruß, Jürgen -
@michl75 In meinen Augen hast Du mit MySQL - da es die schon länger gibt - hast Du gute AddOns für Excel. Ich kenne zwar Grafana nicht, aber wenn auch MySQL verwenden kann und Du damit schon vertraut bist, würde ich dabei bleiben.
-
ok, danke für eure Antworten ... dann werde ich es auch bei MySQL belassen...
vielen Dank!
-
@michl75 said in Überlegung auf Influx umzusteigen:
Grundsätzlich ist doch eine Datenbank eine Datenbank, egal wie aufgebaut...
Jein.
MySQL/Maria -> relationales Datenbankmodell
Influx -> Zeitbasiertes Datenbankmodell
Influx hat sich auf zeitbasierte Messdaten und deren Verwaltung spezialisiert. Influx hat auch kein Problem mit der Auswertung großer Datenmengen bei gleichbleibender Performance.
Ich überlege gerade.... ich habe u.a. 15 Aqara-Sensoren. Die melden im Schnitt alle 10 Sekunden 2 Werte (Temp und Luftfeuchtigkeit).
2 Werte alle 10 Sekunden pro Minute machen bei 15 Sensoren insgesamt = 180 Werte pro Minute.
Macht 259.200 Werte am Tag oder 46.656.000 Werte in einem halben Jahr.
Mich interessiert aber nicht, wie der Wert am 08.09. um 08:40 Uhr war. Ich möchte Daten aggregieren... Zeitabschnitte, Min, Max, Mean pro Tag oder Monat... das kann Influx.
Jetzt habe ich noch ein paar Shellys, welche auch 2 Werte in 5 Sekunden melden. Und mein EVU-Kit für die Wallbox meldet 20 Werte im Sekundentakt.
Kennt jemand auf die Schnelle einen Weg, die Anzahl der Gesamtwerte in einer Influx-Datenbank in Flux-Syntax auszulesen?
-
@ftd
hast Du mal die Berechnungen von influxDB verifiziert?
Min/max etc. ist ja einfachster Kram. Aber Integrale bringen influxDB wohl schon an Grenzen. Habe mal versucht elektrische Leistungen (Watt) von Verbrauchern und Erzeugern zu verwenden und daraus elektrische Arbeit (kWh) für zB Tages/Wochen oder sogar Monatsverbräuche zu berechnen.
Dabei hat sich gezeigt, dass die Grenzen der Integration nicht gescheit angeben lassen und es immer zu einer Verschiebung der dann berücksichtigten Daten aus der Datenbank führt.
Lässt sich leicht mir influxDB-Studio und Excel oder nem Taschenrechner prüfen.Für konstante Verbraucher mit häufigen Einträgen in die Datenbank mag das zu vernachlässigen sein, aber schwankende große Verbraucher zeigen so ergebliche Fehler der Berechnung = unbrauchbar. Leider konnte auch das offizielle influxDB Forum nicht helfen wie man korrekt Integrale mit der influxDB berechnet. Finde ich sehr schade, da es für mich ein sehr naheliegender Anwendungsfall solcher zeitlich strukturierten Datenbanken ist.
Zum Thema Performance war influxDB allerdings in ersten Versuchen sehr vielversprechend und das geplante Gesamtprojekt würde niemals auf dem Raspberry mit MariaDB laufen: https://forum.iobroker.net/topic/38586/mysql-mariadb-influxdb-welche-db-zum-objekte-sichern/8?_=1631180605544
-
@ftd sagte in Überlegung auf Influx umzusteigen:
2 Werte alle 10 Sekunden pro Minute machen bei 15 Sensoren insgesamt = 180 Werte pro Minute.
Macht 259.200 Werte am Tag oder 46.656.000 Werte in einem halben Jahr.Ha, ich habe seit nicht einmal 3 Monaten eine Spielerei mit den Werten von meinem Debian und einer angeblich schnelleren Datenbank im Test - victoriametrics
Kennt jemand auf die Schnelle einen Weg, die Anzahl der Gesamtwerte in einer Influx-Datenbank in Flux-Syntax auszulesen?
Habe ich auch mal ewig gesucht und nix richtiges gefunden. Nur
- use database
- select count(*) from measurement
- dann alles addieren
-
Nur mal aus Interesse. Lasst Ihr die Datenbanken so dauerhaft laufen?
Gemäß Doku von influxdB habe ich die Werte in eine ShortTerm Datenbank laufen lassen und lasse diese automatisch per Aggregation auf für mich noch sinnvolle Zeitfenster (zB alle 15Minuten ein Wert) verdichten in eine LongTerm Datenbank. LongTerm ist dann die eigentliche Datenbank und ShorTerm nur ein Puffer der nicht gesichert wird etc.. Aber leider stoße ich wie gesagt genau dabei auf die Probleme einer Integralberechnung in der Aggregation. -
@ftd sagte in Überlegung auf Influx umzusteigen:
h habe u.a. 15 Aqara-Sensoren. Die melden im Schnitt alle 10 Sekunden 2 Werte (Temp und Luftfeuchtigkeit)
ich wollte mal fragen:alle 10 sek temp und luftfeuchtigkeit - was soll das bringen - diese info ist doch überdimensioniert
da wird doch viel performance und rechenzeit verbraucht und bringt bei einem normalen raum keinen mehrwert, im vergleich zu alle 20 min oder so
oder sehe ich das falsch ?
-
@liv-in-sky said in Überlegung auf Influx umzusteigen:
ich wollte mal fragen:alle 10 sek temp und luftfeuchtigkeit - was soll das bringen - diese info ist doch überdimensioniert
da wird doch viel performance und rechenzeit verbraucht und bringt bei einem normalen raum keinen mehrwert, im vergleich zu alle 20 min oder so
oder sehe ich das falsch ?
Naja, kann ich so erstmal nicht bestätigen... hier mal mein Proxmox-System mit dem ioBroker und Influx-Datenbank. Da laufen noch 8 andere Container... alle langweiligen sich.
Einen Mehrwert haben mehr Daten auch nicht immer. Eine Temperaturänderung von 20,1 auf 20,2 Grad innerhalb von 30 Sekunden interessiert mich nicht. Meistens aggregiere ich oder bilde gleitende Durchschnitte.
Der Influx Adapter steht bei jedem Wert auf:
Verzeichnisgröße nach rund 3 Jahren....
...@InfluxDB:/home# sudo du -sh /var/lib/influxdb 1.4G /var/lib/influxdbRetention-Policy 365 Tage. Wobei ich nicht alle Werte 1 Jahr aufhebe.
Hab letztens hier im Forum von jemand gelesen, dessen DB rund 60GB groß ist.
Solange die Performance stimmt, ist mir eigentlich egal, wieviele Werte in der Datenbank stehen oder wie oft Daten gespeichert werden. Seit 2 Wochen stelle ich rund 250 Aliase von Influx 1.8 auf Influx 2.0 um. Sowohl der NUC und der ioBroker haben mit 2 Datenbanken kein Problem. Ist ja nur ein zusätzlicher Container. Beide Influx-Container (1.8 und 2.0) haben im Schnitt eine 1-5% CPU-Auslastung. Die Auslastung steigt auf 10-20% während des eAuto-Ladens... da gibt es mehr Änderungen vom Smartmeter, PV, Speicher, etc. und ich schalte auf einem separatem Tablet eine Grafana-View ein, welche mir die 'Wallbox' mit 10 Sekunden-Refresh-Time zeigt. Beide Influx-Container haben 2GB RAM zugewiesen:
Schreibzugriffe auf die SSD? Hmm.... SSD Wearout steht auf 17% nach 3 Jahren.
Mehr kann ich dazu leider nicht sagen.
Hat jemand hat andere Erfahrungen vorzuweisen? -
Sehe ich genauso und da die Aqara Sensoren mit +-0,3°C / +-3% Genauigkeit messen macht auch so manch Anderes ganz wenig Sinn und die Aussagekraft solche Aufzeichnungen dann geht nicht nur gegen Null sondern führt auch zu Falschaussagen. Wobei die Aqara Sensoren hier schon häufig melden. Meine liegen grob bei jede 30 Minuten eine Meldung. Vermutungsweise werden sie auch nur häufiger etwas melden bei Änderungen. Bei eher statischen Raummessungen ist im Sinn der Batterielebensdauer weniger oft wohl mehr.
-
ich glaube, ich habe mich nicht richtig ausgedrückt
meine frage war im bezug zur thematik gedacht, welches datenbanken was können.
wenn man mit solchen datenmengen arbeitet, evtl einen raspi nutzt und dann noch solche berechnungen machen will, wird es eng - daher mein gedanke, ob das sinn macht bzw. das mit eingeplant gehört.
wenn man jedoch in ein performantes system investiert und spaß an solchen berechnungen hat, ist das grund genug, sich sowas einzurichten
sollte also keine kritik sein !
