für das Kennenlernen der Rahmenbedingungen in einem Haus und das Herumexperimentieren ist eine Datenlooging in kurzen Zeitabständen meiner Meinung nach prima. Langfristig betrachtet führt es jedoch zu zu vielen Daten und schlechter Performance.
Um die Datenmenge klein zu halten und trotzdem auch Langfrist Vergleiche durchführen zu können, wäre es Prima wenn das Loggen der Daten in kurzen Zeitabständen erfolgt, und dann später mittels Script diese Datenmenge ausgedünnt wird. Also statt 30 Sekunden Werte nur noch alle 5 Minuten.
Also ich nutze eine MYSQL-DB und die hat jetzt ungefähr 600MB ohne auch nur den Hauch von Performanceeinschränkungen.
Ich sehe beim Housekeeping das Problem, das man nicht einfach 4/5 Minutenwerten löschen sollte, sondern aus 5 Werten ein arithmetischen Mittelwert bilden sollte. Sonst verliert man Spitzen, Ausreißer und ähnliches.
Man muss sich immer die Frage stellen, was sind mir die Daten Wert und was kostet ein GB Speicher ???
und da kommt man schnell zum Schluß das es nicht sinnvoll ist die geloggten Daten zu strippen aber die Schnapschüsse der letzten Party in 10MPixel in RAW Format aufzuheben…
OT: Da aber viele hier mit Performance Probleme haben, könnte ich mir mal überlegen, ob ich nicht ein Loggingservice aufmache, wo ihr dann eure „zu vielen“ Daten speichern könnt…
der Speicherplatz ist auch nicht mein Problem ;-). Ich möchte nur vorbeugen und bin mit der IPS Lösung ansonsten auch sehr zufrieden.
Welche Auswertungen sind langfristig wirklich von Interesse? Vielleicht Verbrauchsgegenüberstellungen (ev. Temperaturbereinigt) Verbrauch August letztes Jahr / dieses Jahr oder eigentlich alles was Anomalien aufzeigen könnte (defekte Geräte…). Dafür sind die Spitzen eventuel nicht so wichtig, bzw bei den Zählern ganz unwichtig…
Ein paar Gig Speicherplatz sind definitiv kein Problem.
Eine unkontrolliert wachsende Datenbank ist aber eines. Egal wie groß die nun wann ist.
Hausautomatisation MUSS autark laufen, im unbeaufsichtigten Betrieb darf es keine möglichen Gefahrenstellen durch Performance oder Platzprobleme geben.
Drum hab ich in der Vergangenheit auch immer die RRD Lösung bevorzugt.
Das muß man nur einmal definieren, was man genau braucht, bzw. das System verkraftet und dann NIE WIEDER drüber nachdenken.
Konstante Performance durch Reorganisation und Datenagregierung geschieht vollautomatisch im Hintergrund.
Genau die Frage, welche Daten langfristig von Interesse sind, ist der springende Punkt.
Wenn ich Daten lösche, fehlen diese mir veilleicht später…bei einer tollen neuen Idee…
Ein Anwendungsfall, den ich habe ist, das ich Graphen übereinander legen will, also August 2011 / August 2011 um Verbräuche oder Annomalien besser finden zu können.
Dafür benötige ich die Werte in der gleichen Zeiteinteilung wie die Aktuellen.
Für den autarken und sicheren Betrieb läuft meine DB nicht auf der IPS-Maschine…gebe also max. Logmüll, wenn die DB abschmiert…
Nun ja, wir wollen das gleiche:) Danke für Dein Post bb.
Heute läuft bei mir täglich das Löschscript für Variablen, dir mir egal sind.
Jetzt eine IPS integrierte DB Reorganisation, die getriggert einmal die Woche laufen kann - und schon sind wir einen Schritt weiter. Heute benutze ich SQL Lite zum komprimieren - vielleicht lässt sich so etwas in IPS integrieren?
Für langfristige Auswertungen macht es schon Sinn, das die verbleibenden Daten möglichst einen identischen oder nur gering abweichenden Zeitstempel behalten. Was meint Paresy oder Steiner dazu?
ich würde wie Frank auch die MySql-DB wählen, zumal ich damit gute Erfahrungen gemacht habe. Auch kann man ja Teile der DB in eine Sicherungs-DB schreiben und damit die Größe reguleiren. Dadurch kann man wie beschrieben z.B. Vorjahreswerte mit heutigen vergleichen. Zumal man diesen Dienst auch noch auf einen anderen Rechner auslagern könnte.
Klar kann man das durch eine externe Datenbank lösen. Sehr gut sogar.
Ab diesem Punkt muß man sich aber um alles selbst kümmern, einschließlich Charting und Visualisierung.
Die ganzen schönen Cummunity und IPS Build-In Lösungen welche immer mehr werden kann man dann nicht nutzen.
Und genau die verlocken schon sehr zur internen Datenbank zu greifen.