Tricks & Tipps zum Datenmanagement in IP-Symcon

Ich will an dieser Stelle mal meine Erfahrungen mit der IPS-Datenbank zum Besten geben. Gerade bei IP-Symcon – Neueinsteigern – so liest man es des Öfteren im Forum – korreliert der Unsicherheitsgrad bei diesem Thema mit der Größe der Logging-DB.

Nun bin ich weder Programmierer noch DB-Experte, kann also nur mit empirischen Erfahrungen dienen.

Was ist/tut eigentlich die Logging-DB?

Die in IPS verwendete Datenbank ist eine  SQLite-Datenbank, die die Nutzdaten im File „logging.db“ speichert. SQLite ist eine freie Software (public domain) und wird vorwiegend embedded (z. B. auch in Mobiltelefonen) eingesetzt. Sie dient in der IP-Symcon-Umgebung ausschließlich dazu, Variablen-Inhalte zu speichern (hierzu muß in den Eigenschaften einer Variable die Option „Datenbank-Logging aktivieren“ gesetzt sein). IPS-Systemparameter selbst (z.B. alle im Objektbaum vorhandenen Objekte, die Objektbaum-Struktur selbst, die konfigurierten Objekteigenschaften) werden nicht in der Logging-DB gespeichert, diese findet man in der „settings.xml„. Wir haben es also ausschließlich mit Nutzdaten zu tun. Die Logging-DB liegt in diesem Pfad: „C:\IP-Symcon\db\logging.db“.

Wie kommen die Nutzdaten in die Logging-DB?

Die Nutzdaten, die von IPS an die SQLite-DB geliefert werden, werden nicht direkt in die DB geschrieben, sondern in ein Cache-File, das „logging.db-journal“ heißt. Alle 60 sec. werden die Daten aus dem Cache-File in die Logging-DB geschrieben und das Cache-File leert sich (kann man direkt im Filebrowser beobachten). Die Größe des Cache-Files ist natürlich stark von der zu loggenden Datenmenge abhängig, bei mir sind es ca. 100-200kb (was vermutlich relativ viel ist -> ich logge recht viele Variablen in kleinen Intervallen). Diesen Prozeß kann man via IPS überwachen (siehe dazu Beispiel-Script unten) und sich bei Bedarf Warnungen ausgeben/schicken lassen. In den Stable-Versionen von IPS hatte ich hier noch keine Probleme erlebt, da ich aber auch Beta-Tester bin, gab es in Beta-Versionen von IPS tatsächlich schon Probleme. Diese äußerten sich darin, das die Cache-Daten nicht in die Logging-DB übertragen wurden. Die Folge ist, dass das Journal-File wächst und wächst und…. . Das Problem macht sich dann bemerkbar, wenn IPS neu gestartet werden soll: der Start dauert wesentlich länger (>10 Minuten sind nicht ungewöhnlich) als gewöhnlich. Das liegt daran, das die SQLite-DB beim IPS-Start versucht,  ein nicht geleert vorgefundenes Journal-File in die Logging-DB zu überführen. Wenn das Journalfile also schon einige Tage vollgelaufen ist (ist mir passiert), kann das schon mal 30 Min und länger dauern. Man sollte in dieser Phase keinesfalls IPS via Taskmanager „abschießen“, die Daten aus dem Journal-File werden dann höchstwahrscheinlich verloren gehen (ist mir ebenfalls passiert). In der Regel ist die SQLite-DB in der Lage, alle Daten in die Logging-DB zu überführen und damit zu retten.

Da man als unerfahrener User damit nicht rechnet, ist man wohl eher geneigt, IPS via Taskmanager abzuschießen und damit ggf. wichtige Loggingdaten zu vernichten.  Genau hier setzt mein Script an: es überwacht die Schreibintervalle der Logging-DB. Ist der letzte Schreibvorgang (also die Übertragung der Journal-Daten in die Logging-DB durch IPS) länger als xxMinuten her, schickt mir IPS eine Mal, ein Pop-Up auf alle Webfrontends etc. etc. . Das lenkt die Aufmerksamkeit auf die richtige Stelle und ich laufe nicht Gefahr, durch unüberlegte Aktionen Logging-Daten zu verlieren.

IPS-Überwachungsscript

(überwacht die Schreibintervalle der Logging-DB)

Script ist hierhin ausgelagert: Monitoring IPS Kernkomponenten

System-Performance

alle paar Wochen liest man im IPS-Forum neu aufkommende Diskussionen, ob und in wie weit die Größe der Logging-DB die IPS-Performance beeinflußt, wie groß die DB werden darf (ohne IPS auszubremsen), ob es nicht besser wäre, die Daten in eine („richtige“) SQL-DB auszulagern etc. etc.

Meine Erfahrungen zu dem Thema, kurz und knapp: keine Performance-Einbußen, keine Größenbeschränkungen, man muß nichts tun.

Für einen „Nicht-Experten“ ist das vielleicht schwer vorstellbar, es ist aber so: aus die Systemperformance von IPS hat die Größe der DB keinerlei Einfluß. Ein Freund aus dem IPS-Forum hatte – ohne es zu bemerken- eine DB-Größe von 13GB (!). Er hat keinerlei Geschwindigkeitseinbußen/-Änderungen – weder vor noch nach Verringerung der DB-Größe- feststellen können. Die einzige Auswirkung, die man im Zusammenhang mit der DB-Größe feststellen kann ist die Performance im Webfront: nämlich dann, wenn viele Daten über einen großen Zeitraum via Chart dargestellt werden sollen.

Dennoch hat eine stark wachsende Logging-DB einen Haken: bei der (täglichen) Datensicherung! Ich hatte im ersten IPS-Jahr recht inflationär alles geloggt, was nicht bei 3 auf den Bäumen war. Die Folge war eine Logging-DB von ca 1,2GB (nach 12 Monaten). Im Backup komprimiert waren das immer noch > 300MB. Wenn das täglich anfällt (ich halte Backups 30 Tage vor), kommt da Einiges zusammen. Also habe ich angefangen, mein Datenlogging sorgfältig zu überarbeiten.

Logging-Strategie

 grundsätzlich ist meine „Datenlogging-Strategie“ in 3 Punkte aufgeteilt

• temporäres Datenlogging (Daten werden ca 2-30 Tage vorgehalten)
• langfristiges Datenlogging (Daten werden nie gelöscht)
• kein Datenlogging

temporäres Datenlogging

temporäres Datenlogging wende ich in 2 Varianten an:

a) bei Anwendungen, deren Daten ich ganz sicher nur kurzfristig benötige (z.B. bei der Inbetriebnahme neuer Geräte, Logiken, Scripte), hier dient das Logging für einen gewissen Zeitraum der Überprüfung der Funktionalität. In der Regel schalte ich das Logging dann nach 1-2 Monaten wieder ab und lösche die Daten aus der Logging-DB via RS DB Analyzer.

b) bei Geräten oder Anwendungen, deren Daten ich regelmäßig, aber nicht historisch benötige, z.B. Daten von Bewegungsmeldern -> diese werden konsequent mit individuellen Vorhaltezeiträumen im RS DB Analyzer hinterlegt und jede Nacht vollautomatisch  aus der DB entfernt.

langfristiges Datenlogging

hier handelt es sich um Daten, die auch historisch benötigt werden. An erster Stelle stehen da bei mir meteorologische Messdaten (ich verwende IPS quasi nebenbei als Wetterstation) und Energieverbrauchsdaten (aktuell lese ich 13 Stromzähler aus und logge deren Daten).

kein Datenlogging

hört sich einfach und selbstverständlich an, ist es aber nicht! Gerade als Einsteiger kann man noch nicht beurteilen, welche Daten geloggt werden sollten und welche nicht. Auch habe ich immer weider festgestellt, dass ich munter d

Daten (über Monate) geloggt und anschließend festgestellt habe: schade Daten sind leider nicht in der richtigen Verdichtung/Einheit – what ever- geloggt, man fängt wieder von vorn an. Meine Empfehlung: lieber am Anfang zuviel loggen, löschen kann man jederzeit (umgekehrt wird’s schwierig).

Logging-Werte runden (Float)

Nicht schlecht habe ich gestaunt, als ich vor ein paar Tagen einige Variablen auf gerundete Werte umgestellt habe. Hierbei handelt es sich um Variablen, die alle 60 Sekunden geloggt werden. Die geloggten Werte sind in der Regel (aus Rohdaten errechnete) Durchschnittswerte und werden als Float mit allen Nachkommastellen geloggt. Allerdings haben die vielen Nachkommastellen nicht mal einen theoretischen Mehrwert. Und speicherplatzmäßig ist es egal, ob eine Float mit 2 Nachkommastellen oder mit 8 Nachkommastellen geloggt wird. Soweit stimmt das auch.

ABER: ein Durchschnittswert mit 8 Nachkommastellen (z.B. Luftfeuchte) verändert sich nach jeder Minute, ein solcher Wert ist nicht reproduzierbar und somit unique. Und damit wandert der auch garantiert jede Minute in die Datenbank und belegt Speicherplatz.

Rundet man einen solchen Wert auf praktische und sinnvolle Nachkommastellen (z.B. Luftfeuchte auf 0 Nachkommastellen, Temperatur auf 1 Nachkommastelle), ist die Wahrscheinlichkeit zweier oder mehrerer aufeinanderfolgender Daten mit identischen Werten sehr viel größer. In einem solchen Fall wird der Wert eben nur 1 Mal statt n-Mal in die DB geschrieben.

Beispiel: im ersten Bild sieht man eine Temperatur-Variable, deren Float-Wert ungebremst in die Datenbank geschoben wird. ca 1440 Werte pro Tag. Dann habe ich die Wertermittlung auf „gerundet, 1 Nachkommastelle“ umgestellt, seit dem fallen nur noch 200-300 Datensätze pro Tag an. Also eine Datenreduktion um 80%!

Monitoring

es ist immer besser, wenn man das, was im System passiert, auch sichtbar macht. Also habe ich mir eine statistische Überwachung meines IPS-Systems  gebaut: überwacht werden seit Mitte 2011 (ich hätte es gleich am ersten Tag machen sollen) die tägliche Anzahl der IPS-Instanzen, Variablen, Module, Ereignisse, Scripte, Links und Profile. Weiterhin wird täglich die Größe der Logging-DB in eine Variable geschrieben. Ausgewertet wird das via IPS-HighCharts (nach einer Integration der HighCharts durch KHC, an dieser Stelle nochmal herzlichen Dank dafür), kann man sich als „Wachstumsbaum“ hier live anschauen (Diagramm ganz unten).

IPS System-Monitoring Script:

Download ganz unten

Installation

• Script in IPS anlegen und Code aus dem Download reinkopieren
• alle benötigten Variablen in IPS anlegen (ensprechend den Variablen im Script-Konfigbereich, alle Variablen vom Typ „Integer„, Ausnahme: die Variablen „DB-Größe“ und „DB-Zuwachs“ sind vom Typ „Float“ , „DB-Zuwachs“ ist darüber hinaus eine Zähler-Variable)
• Variablen-ID’s im Konfigbereich des Scripts eintragen
• zyklisches Ereignis unterhalb dieses Scripts anlegen welches das Script einmal täglich startet (z.B. um 01:00 Uhr)
• bei Bedarf Links der Variablen ins Webfront legen, HighCharts-Auswertung hinzufügen etd etc. 

Datenbank-Größe (Filegröße) reduzieren

auch immer wieder gern im Forum zu lesen: ich hab viele Daten gelöscht, die Datenbank wird aber nicht kleiner!

Diese Feststellung ist fast richtig: die Datenbank reserviert den Speicherplatz auf der HDD, den sie für die Daten benötigt. Kommen mehr Daten dazu, wird logischerweise entsprechend mehr Platz reserviert. Umgekehrt ist es nicht so: beim Löschen von Daten bleibt nicht benötigter Speicherplatz weiterhin reserviert und wird mit nun neu hinzukommenden Daten aufgefüllt. Solange die neuen Daten und den alten Space passen, wächst die DB nicht weiter. Auch das kann man prima im „Wachstumsbaum“ meines Systems beobachten.

Hat man eine große Aufräumaktion hinter sich, möchte man aber vielleicht dennoch die DB-Größe (z.B. aus Platz- oder Handling-Gründen) reduzieren. Das geht grundsätzlich, IPS muß dazu herunter gefahren werden, die DB wird mittels externem Tool „komprimiert“ (ich habe eine starke Abneigung zu diesem Begriff in  diesem Kontext, verdichten finde ich deutlich besser), anschließend wird IPS wieder gestartet. Funktioniert in der Regel reibungslos.

Als Tool zum komprimieren/verdichten empfiehlt sich z.B. „sqlite shell“ (Kommandozeilen-Tool) oder das Firefox-PlugIn „SQLite Manager„. Bei letzterem verbindet man sich mit der IPS-Logging-DB (IPS vorher runterfahren!) und führt den Menüpunkt „Database/Compact Database“ aus, fertig!

Daten-Hygiene

einzelne Datensätze aus dem Bestand löschen

es kommt immer mal wieder vor, das man gezwungen ist, manuell einzelne Datensätze via Archive-Handler zu löschen. Entweder man vergisst das anschließende reaggregieren der Variable oder hält es nicht für so wichtig, oder, oder….

worauf ich hinaus will: es dauert nicht lang und man hat inkonsistente Daten (im Sinne von nicht stimmig – die Datenbank-Konsistenz ist hiervor unberührt). Da es sehr, sehr mühselig ist, jede Variable manuell neu zur Reaggregation anzustoßen, gibt es aus dem Doku-Bereich von IP-Symcon ein Script, welches nach Ausführung selbsttätig alle Variablen im System abklappert und deren Neuaggregation anstößt. Ich hatte dieses Script vor einigen Wochen laufen lassen: es hat ca. 2 Tage gebraucht, um alle Variablen durchzuhühnern. Natürlich beeinträchtigt das etwas die Performance von IPS, ich konnte aber noch mit leben.

verwaiste Daten in der IPS DB

löscht man Variablen (bei denen das Logging eingeschaltet war) aus dem Objektbaum, so bleiben dennoch die gelogten Daten in der DB erhalten. Das hat den Vorteil, dass man die Daten weiterhin nutzen kann, in dem man diese einer neuen Variable zuweist. In der Regel braucht man diese aber nicht mehr. Mit der Zeit sammelt sich Einiges an. Will man die Waisenkinder aus der DB löschen (via Archive-Handler), hat man gut zu tun, weil sich das Prozedere etwas unkomfortabel gestaltet: man kann immer nur einen Datensatz (entspricht den Daten einer Variable) löschen. 

Sehr viel komfortabler geht es mit dem RS AH Terminator… 

RS DB Analyzer

die Komplettlösung zum Datenmanagement in IP-Symcon ist der RS DB Analyzer. Mit seiner Hilfe kann man sich einen schnellen Überblick über alles verschaffen, was sich in der DB so rumtreibt: Variablen & Datensätze (meistens). Weiterhin kann man ein vollautomatisiertes Datenmanagement etablieren um so das Wachstum der IPS-DB drastisch zu minimieren. Weitere Infos zu Features und Projekt: klick