zur Projekt-Homepage: klick 

 

Changelog: 

2013-03-29 V 2.7
    Features

  • neues Modul „Record Reducer“: dünnt historische Loggingdaten auf max. 1 Datenstaz pro Stunde aus
  • leichtes optisches Tuning

    

 

In der aktuellen Betrachtung ist mir eine so feine zeitliche Auflösung von 60 Sekunden ganz recht, aber sein wir mal ehrlich: nach 2 Jahren interessieren mich bestenfalls noch Stundenwerte. Wenn überhaupt.

Warum also diese Datensätze auf der Festplatte verschimmeln lassen, wenn man sie auch entsorgen (besser: neudeutsch „recyclen„) kann? Also habe ich dem DB-Analyzer ein neues Modul spendiert, welches dieses Problem angeht.

 

Neues Modul: Record Reducer

Der Record Reducer kann den Datenbestand (und damit Platzbedarf) auf ein Bruchteil reduzieren, in dem er alle Datensätze einer vollen Stunde löscht – bis auf einen: den ersten Datensatz, der ihm auf seiner Reise durch die Zeit pro Stunde begegnet,  lässt er leben.

 

Was genau macht das Ding eigentlich?

Eigentlich ganz einfach: aus der IPS-DB werden zunächst alle Einzeldatensätze ausgelesen. Dann geht der Reducer stundenweise diese Datensätze durch. Den ersten Datensatz einer Stunde lässt er stehen, den Rest löscht er. Die Löschungen sind übrigens im IPS-Systemprotokoll ausgewiesen. Sind 24h des ersten Tages durchgehühnert, gehts an den nächsten Tag. Solange, bis das Ende der vom User angegebenen Periode erreicht ist. Weiterhin wird nach jeder fertig abgearbeiteten Variable ein Eintrag in die Reaggregations-Queue vorgenommen, so dass man auch hier gleich loslegen kann. 

Dem Modul ist es auch egal, wie oft man Variablen/Zeiträume durch den Reducer jagt: es wird immer ein Datensatz pro Stunde stehen gelassen. „Unfälle“ sollten somit ausgeschlossen sein.

 

Licht und Schatten

Hört sich alles sehr gut an, gibts auch Nachteile?

Ja, die gibt es: in der IPS-DB sind zu jedem Datensatz neben dem eigentlichen Wert z.B. auch Aggregat-Werte hinterlegt. Diese Werte (Duration, Starttime, Endtime) bleiben auch nach einer Reaggregation unberührt. Ebenso gehen zum Beispiel Minimum- und Maximumwerte innerhalb der jeweiligen Stunde unwiederbringlich verloren. Falls man also Berechnungen mit Datenarrays via AC_Get…. anstellen will, sollte man sich vorher nochmal genau überlegen, ob die Datenreduktion derartige Vorhaben evtl. vereiteln kann.

Auch in der Stundensicht in den IPS-Charts sieht das dann etwas „merkwürdig“ aus: es wird bei Zähler – wie Standard-Variablen immer nur ein Segment im betrachteten Zeitraum dargestellt (nicht der Gesamte Zeitraum). Ab einer zeitlichen Auflösung der IPS-Charts von >Stunde sieht dann wieder alles normal aus.

 

Wann sollte man die Finger davon lassen?

Mindestens dann, wenn man sich nicht ganz im Klaren darüber ist, was in der DB passiert. Und wenn einem die historischen Daten wichtig sind. Ich werde z.B. keinesfalls meine metereologischen Daten anfassen, denn letztenendes bedeutet eine solche Reduktion auch Informationsverlust.

 

Hilfe – was will er von mir ? – die Bedienung

die Bedienung ist eigentlich recht einfach – sprach der Entwickler. Da diese Spezies aber meist mit verödeten Sozial-Synapsen im Elfenbeinturm sitzt, habe ich sicherheitshalber etwas Doku ins Tool eingebaut (links oben im WFE rotes Fragezeichen).

Dennoch behaupte ich: es ist einfach zu bedienen: Start- und Enddatum der Reducing-Aktion eingeben, die betreffenden Variablen per Haken in der Tabelle markieren, Button „Reducing“ klicken – fertig.

 

Leider gibts auch (mal wieder) ein Browserproblem: für die Eingabe der Datümer habe ich ein HTML5-Steuerelement verwendet. Das soll den Browser veranlassen, bei Bedarf u.A. einen Kalender für die Datumseingabe zu öffnen. Chrome (siehe Bild rechts) und Opera tun das auch brav, Firefox und IE nicht. Da ich von HTML nicht viel Ahnung habe, schiebe ich das Problem auf die Browser, ich nutze sowieso nur Chrome.

 

 

Ein Beispiel aus der Praxis

In meinem Beispiel habe ich mal probehalber 4 Variablen meiner Stromzähler beackert. Alle hatten je etwa 900.000 Datensätze angehäuft (alle werden seit 1.05.2011 im 60 Sekunden-Intervall geloggt). Als Löschzeitraum habe ich den 1.05.2011 bis 31.12.2011 angegeben.

Die Reducing-Aktion brachte eine Datenreduktion von 1,04 Mio Datensätzen. Hochgerechnet auf ein ganzes Jahr wäre das ein Einsparungspotenzial von ca 1,5 Mio Datensätzen (das entspricht etwa 120MB auf der Festplatte).

Überzeugt hat mich dann auch ein „Vorher-Nachher-Blick“ auf die Daten einer Variable (ArchiveHandler) und eine Zählervariable im IPS-Chart vor Reduktion/nach Reduktion + Reaggregation:

 

 

 

  

 

 

 

 

 

 

und nachdem ich die IPS-Datenbank komprimiert habe (am 29.03.2013) sind wieder 80MB frei geworden. Damit habe ich in den letzten 9 Monaten seit der Nutzung der DB-Analyzer-Features effktiv keinen Datenzuwachs in der IPS-Datenban! Und das,obwohl seit dem ca 50 geloggte Variablen (+25%) hinzugekommen sind. Live kann man sich das HighCharts-Diagramm hier anschauen.

 

 

Download

zur Projekt-Homepage: klick 

 


 

Getagged mit
 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

css.php