Datenbankwartung und Doku

Hallo

ich hab mich in den letzten Tagen recht viel mit der IPS internen Datenbank gespielt, und erwäge evtl. darauf umzusteigen.

Ein paar Fragen konnte ich mir aber trotz intensiver Forum und Dokusuche nicht beantworten.
Gibt viele Posts zu übervollen und defekten DB, aber wie man die ordentlich in Schuß halt ist leider kaum was zu finden.

  1. Werden die agregierten Werte ( Stunde/Tag/Monat/Jahr) automatisch berechnet, oder muß ich das irgendwie antriggern ?

  2. Wie werden diese berechnet ? (mean oder median) Aus welchen welchen Daten werden höher verdichtete Aggregationen berechnet ?

  3. mit welchem Zeitstempel kommen die in die DB ?

  4. Wie wird man die Einzelwerte wieder los? Geht das echt nur händisch oder gibts da eine Automatik ?

  5. Kann ich irgendwie automatisch bestimmen wann und wie agregiert, bzw. die Einzelwerte gelöscht werden ?

  6. Was passiert genau wenn man „AC_ReAggregateVariable“ aufruft ?

  7. Wenn man Einzlwerte löscht, muß man dann die DB reorganisieren damit sie wieder klein wird? Wenn ja Wie ?

  8. Ist die überhaupt schon für Produktiveinsatz gedacht, oder noch immer play as will ?

  9. Gibts da irgendwo ein best-practice oder einen Vorschlag vom IPS Team zu der ganzen Thematik.

Wäre wirklich gut wenn Doku und Empfehlungen dazu etwas überarbeitet würden. Die interen DB ist schön, aber wertlos wenn man nur Daten reinschmeißt und nicht weiß bzw. bestimmen kann was weiter passiert.
Gibt so viele abschreckende Meldungen hier zu übervollen und langsamen DB.
Das gehört geklärt.

danke im Voraus
bb

Ich werde versuchen einige deiner Fragen zu beantworten. Teilweise gewollt unkonkret.

  1. Es passiert alles automatisch, fortlaufend und resourcenschonend.
  2. Es ist ein von der Dauer gewichteter Durschnittswert (Standard). Es ist das positive Delta zum vorherigen Wert (Zähler).
  3. time()
  4. Es ist zur Zeit keine Automatik vorgesehen. Die Stundenansicht nutzt diese Daten für die schöne, detaillierte Ansicht.
  5. Nein. Speicherplatz kostet heutzutage nichts mehr. Alles andere passiert automatisch und transparent im Hintergrund.
  6. Die alten Aggregierten Daten werden gelöscht und mit den Einzeldaten werden die Daten neu berechnet. Das kostet viel Zeit und Ressourcen und ist nur in Ausnahmefällen erforderlich. (z.B. wenn falsche, einzelne Daten aus der DB gelöscht wurden)
  7. 42
  8. SQLite sieht diese Funktion nicht vor. Deine logging.db wird niemals kleiner werden. Macht somit 5) überflüssig.
  9. Wir nutzen diese schon seit über einem Jahr produktiv. Wir haben während der 2.3 und jetzt auch für die 2.4 immer an der Performace gearbeitet, um keine langen Ladezeiten trotz vieler Daten zu gewährleisten.
  10. Den Haken in der Variable setzen und den Rest im WebFront genießen. Mehr gibt es nicht.

Mehr Info:
-Die AC_* Funktionen werden wir vermutlich erst zur 2.5 offiziell Dokumentieren und für eigene Funktionen freigeben. Solange kannst du Sie gerne nutzen, musst aber mit etwaigen Änderungen rechnen.

-Die Datenbankgröße hat weniger mit der Performance zu tun, als die Tatsache, dass bei zu vielen, zu schnell geloggten Variablen die Festplatte mehr belastet wird, und somit länger zum Abarbeiten der Anfragen braucht.

-Wird ein Wert mit einem Intervall von <30Sek durchgängig geloggt, erhöht sich die Ladezeit der Graphen für diese spezielle Variable in der Stundenansicht erheblich. Diese wird aus den Rohdaten erstellt, um mehr Details zu bieten. Die Aggregation steigt entsprechend der Menge der Rohwerte.

Grüße,
paresy

Hier ist eine Empfehlung durch Euch sicher hilfreich.
Zum Beispiel Temperaturen, Feuchte oder ähnliches alle 60 Sekunden.
Zähler Daten ebenfalls Minütlich…

Ich nutze zBsp die Wirkleistung meines eHZ die alle 5 sec. berechnet wird, im Ipod beim Schalten der Lichter als direkte Anzeige um auch die Energie zu veranschaulichen.

Diese Info ist aber bereits 5 Minuten später in diesem Detailgrad nicht mehr von Interesse und könnte in großen Teilen entfernt werden.

Hi paresy

Danke für die Erklärung, das ist doch schon mal was und hilft für weitere Entscheidungen gut weiter.

Nur in einem Punkt kann ich nicht zustimmen.
Mit dem Argument „Plattenplatz kostet nix“ sich um die Aufgabe des Cleanup zu drücken ist nicht legitim.
Große Dateien sind IMMER ein Quell von Ärger. Sei es bei Datensicherung, defekten Platten, reorganisation usw. Wie man lesen kann dauert reagregieren ja auch umso länger je größer der Datenbestanad ist.

Hier solltet ihr euch noch was überlegen, oder zumindest eine Guidline zur Selbsthilfe (kleine Script oder Toolsammlung) rausgeben.

schöne Grüße und Danke
bb

sehr interessant diese Diskussion! Danke an Bernhard für die Fragen, danke an paresy für die Antworten. Auch ich mach mir langsam Gedanken um meinen Datenbestand. Mein Ziel ist es, bestimmte Daten (Wetter, Verbrauchsdaten) langfristig vorzuhalten. Mit langfristig meine ich 10 Jahre und mehr. Hört sich sicherlich extrem an, ist es m.E. aber gar nicht wenn man mal ins Detail geht: Je länger die Daten zurück liegen, desto höher können sie verdichtet sein. Mich interessiert bei Klimadaten nicht die Temperatur am 01.03.1998 um 14:03Uhr sondern z.B. maximal die Tageshöchst- und Tiefstwerte. Noch interessanter werden hier eher solche Sachen wie Monatsmittel, -max und -min, das durchschnittliche Maxi- und Minimum etc etc. Nur um das Thema historische Daten mal anzureißen.

Das mal kurz zur Einleitung.

Nun produziere ich täglich 5MB Logging-Daten. Gefühlt würde ich sagen: 70% davon sind Daten die ich historisch betrachten möchte (also langfristig).
Dast würde bei 10 Jahren Aufzeichnungszeitraum eine Datenbank-Größe von knapp 20GB erzeugen. Aber nur wenn die produzierte Datenmenge konstant bleibt. Glaub ich eher weniger.
Genau hier hab ich so meine Zweifel ob dan dann noch händelbar ist, sinnvoll sicher nicht. In DWH-Umgebungen (mit deutlich grösseren Datenmengen) ist man daher gewzungen, sich recht zeitig um die Histiriserung von Daten zu kümmern: Daten werden entweder mit zunehmendem Alter verdichtet oder ausgelagert. Oder Beides.

Worauf ich hinaus will: so oder so ähnlich wird es den meisten IPS.Nutzern früher oder später gehen. Meine Befürchtung wäre hier dass wenn systemseitig keine Vorkehrungen diesbezüglich getroffene weden kommen über kurz oder lang eine Menge User in Bedrängnis weil Sie ihre Datenmengen nicht mehr gemanaged bekommen. Sei es nun durch die schiere Größe (z.B. Backup) oder durch Performance.

Da ich ein sehr präventiv agierender Mensch bin (meistens :D) würde ich mir wünschen das vom Hersteller hier über Kurz oder Mittel ein Lösungsansatz angeboten wird, nicht zuletzt auch auf Grund der Argumentation von Bernhard.

Wie seht Ihr das?

Als Lösungsansatz könnte ich mir vorstellen:

  • [li]verdichte daten der Variable xy, die Älter sind als 3 Monate nach Regel z[]Lösche Daten der Variable cz die älter sind als 6 Monate
    [/li][li]verdichte Daten der Variable h und lege mit Maximum, Minimum, maximalen Durchschnitt, minmalen Durchschnitt pro Tag ab
    [/li][li]Verdichte Daten der Variable r nach 12 Monaten auf Tagessummen[
    ]verdichte Daten der variable d nach 12 Monaten auf Monatssumme
    [/li][li]etc etc
    [/li]

Hm, das ist aber nicht immer gewünscht, wie ja bereits mehrfach ausgeführt. Ist das bei geschicktem Datenbankaufbau nicht doch machbar, z.B. primitiv gedacht Tabellennamen mit Jahreszahl vorangestellt oder vielleicht ein Datenbankfile pro Jahr? SQL bietet da doch massig Möglichkeiten, und unterstützt bspw. CREATE und DELETE TABLE, ATTACH und DETACH Database etc.:rolleyes:

Speicher ist eigentlich kein Thema mehr also beunruhigt mich die Größe der DB nicht. Es würde mich absolut nicht stören wenn das Ding mal 200GB hätte :slight_smile:

Performance ist doch keine Funktion der DB Größe oder ? Performance wird doch eher über die Anzahl (gleichzeitiger) Zugriffe und die darunterliegende Physik beeinflusst.

Weitere DB Funktionen interessieren mich deshalb nur im Zusammenhang mit dem ersetzen von Daten. Meine Sensoren schreiben manchmal Mist (Stromausfall, Zähler Reset auf Null und schon haben wir das Problem)
und ich würde das dann ganz gerne Bereinigen. Das Löschen von Daten ist da nur ein schlechter Ersatz.

Da das Lizenzmodell für IPS auch Variablen abhängig ist könnte mein nächster Wunsch zu einem Problem werden : Ich würde gerne ARRAYS mit Variablen in die Datenbank ablegen (An Text Files kann ich mich nur schwer gewöhnen)

Also lassen wir uns mal überraschen : Nach dem Release ist vor dem Release :slight_smile:

wenn man kein Backup macht kann ich das nachvollziehen. Ich mache aber täglich Backups. So ist das Geschrei meinerseits nach einem GAU eher homöophatisch (habs im letzten halben Jahr 2-3 Mal gebraucht).
Aber - um mal bei deinem Szenario mit 200GB zu bleiben: da bräuchte man - je nach Backup-Konzept - locker 6TB Platz, nur für die DB… DAS ist m.E. übertrieben.

Hm, das kann man auch anders sehen. IP-Symcon läuft mit Minimalanforderungen auch auf einer SSD anstandslos und wunderbar leise. Da ist jedoch angesichts der Preise Speicherplatz immer ein Thema.:frowning:

Ich möchte mich dieser Diskussion anschließen und meine Erfahrungen mit geloggten Daten mitteilen.

Als Netzwerker in einem sehr großen Netz setzen wir Überwachungssoftware unterschiedlichster Firmen ein. Als Service Provider ist es Pflicht seine Verfügbarkeit (availability) nach zuhalten. Was bedeutet das wir jedes Interface Pollen, snmp Daten abfragen und Speichen ect.

Hierbei kommen sehr große Datenmengen zusammen die lange Abgefragt werden müssen.

Je mehr Daten verfügbar sind und abgefragt werden desto mehr geht die Performance in den Keller wen man sich in der Live DB aufhält.

Ich möchte die Strategie eines nahmen haften Herstellers hier mal kurz verdeutlichen.

Es existieren nicht nur 1 sondern mehre Datenbanken parallel.

  1. Die live Daten (echtzeit, Steuerung ect.) mit den Produktivdaten bis zu einer Woche. Also die ganz normalen Daten wie jetzt auch.

  2. Daten die gesammelt werden durch Sensoren oder durch logging/polling wie auch immer kommen wen sie älter sind als eine Woche in die DB Woche.

  3. Daten die älter sind als eine Woche von der DB Woche in die DB Monat.

bis hin zu DB Jahr.

Die Tabellen sind dabei gleich nur halt in verschiedene Datenbanken.
Wen ich mir jetzt nun einen Grafen anschauen möchte holt er sich jetzt entweder die Daten aus der Woche bei Wochenansicht >> Monat bei Monatsansicht usw.

Das hat den vor teil das die Hauptdatenbank nicht mit den geloggten Datensammlungen belastet wird.

Und ein Daten löschen ist nicht erforderlich.
Das Komprimieren der Daten erfolgt automatisch wen sie die Instanz wechseln.

Hoffe bin nicht am Thema vorbeigeschossen

Gruß Nick

Hmm…ich beschäftige mich beruflich auch viel mit Datenbanken. Das Problem bei der horizontalen Teilung einer DB ist doch „wie erfährt die Applikation wo welche Daten sind ?“.

Ich bin mir nicht sicher ob man IPS ein Regelwerk mitgeben kann, wann welche DB angesprochen werden soll…

Hallo Leute,

Auch ich habe mir über das „Langzeitlogging“ meiner Daten Gedanken gemacht. Ich bin zu folgenden Grundsätzen gekommen.

  • keine Abhängigkeit von einem Hersteller
  • OpenSource Produkte

Und meine Lösung sieht aktuell wie folgt aus:

  • Logging 7 Tage in IPS, ein Skript löscht täglich ältere Daten.

  • IPS schreibt die Variablen in eine MySQL-Datenbank auf einem anderen Host.

  • jede Stunde errechnet ein Script auf dem Logging-Host die min,max,avg Werte der Variablen der letzten Stunde und schreibt diese in eine extra Tabelle.

  • einmal am Tag errechnet ein weiteres Skript die Tageswerte und schreibt diese in eine weitere Tabelle.

  • nach festgelegten Verfallsdaten werden diese RAW- und Stundenwerte gelöscht. Tageswerte bleiben immer erhalten.

  • visualisiert werden die Daten über Highcharts, leider noch nicht ganz fertig :wink:

Grüße

Andreas

Hi,

also ich möchte mich der Fraktion „Speicherplatz ist wertvolles Gut“ anschließen.

Zum einen werden große Datenbanken auf Dauer unhandlich und zum anderen bin ich der Meinung das den Anwendern hier mehr möglichkeiten gegeben werden sollten.

Ich würde mich freuen wenn es irgendwann nativ die Option gäbe anstelle SQ Lite MySQL einzusetzten.

Genauso fäne ich es toll wenn IPS bei der Logging Konfiguration auch eine Gültigkeitsdauer der Daten ermöglichen würde.

Ich logge viele Daten die maximal 1-2 Wochen interessant sind, da wär es schön wenn automatisch die ältesten Werte wieder aus der Datenbank fallen würden.

So ein konfigurierbarer Cleanup filter wäre toll.

Gruß Martin

Hallo Andreas,

verstehe ich da richtig: du liest alle 7 Tage die logging.db uaus und schreibst die Daten in eine mysql-DB? Ich habe mehr und mehr Gefallen an der IPS-eigenen DB gefunden, nur würde ich auch nach einer gewissen Zeit die Daten in einer externen DB sichern.