Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

InfluxdB Daten Aggregation/Reduktion und Zeitstempel?

Dieses Thema im Forum "Andere Datenbankserver" wurde erstellt von Pete0815, 26 November 2020.

  1. Pete0815

    Pete0815 Benutzer

    Hallo,
    für private Zwecke der Hausautomatisierung nutze ich seit Kurzem eine InfluxdB für die Speicherung von Sensorwerten. Die Performance durch die Speicherung in zeitlicher Abfolge habe ich bereits positiv bemerkt. Jedoch ist es nicht wirklich sinnvoll zB Sensordaten die alle paar Sekunden (zB Stromverbrauchsleistung) geliefert werden über einen ganzen Monat oder sogar später Jahr abzufragen und damit Berechnungen durchzuführen.

    Nun würde es mir reichen, wenn die Daten auf zB 1h komprimiert werden. Hierzu müßte ich über 1h Das Integral bilden, ok. Aber das Ergebnis wiederum in die Datenbank zurück schreiben und ggf. alle Sekundenwerte löschen. Bzgl. des Konzeptes ist der Zeitstempel für mich ein Problem. InfluxDB speichert, soweit ich es weiß, automatisch den Zeitstempel und dieser ist auch nicht "manipulierbar". Wenn ich mir also später zB auch mal ein Diagramm ansehe ist es wichtig, dass der Zeitstempel des Integrals für 1h auch den Zeitstempel besitzt dieser Stunde. Selbes Problem bzgl. Woche und Monat. Tage kann ich noch direkt in der Abfrage bewältigen auch wenn es auf die Performance geht.

    Lasse ich eine Berechnung zyklisch jede Stunde ausführen zum Komprimieren bin ich mit dem Zeitstempel der Speicherung auf jeden Fall in der nächsten angebrochenen Stunde.

    Lässt sich sowas als mit einer solchen Datenbank gar nicht realisieren?

    Thx!
     
  2. Dukel

    Dukel Datenbank-Guru

    Pete0815 gefällt das.
  3. Pete0815

    Pete0815 Benutzer

    Vielen Dank! Hilft mir sehr und knobel da ständig am Konzept und ob dies überhaupt sinnvoll möglich ist.
    Aktuell grübel ich über:
    -Bekomme ich 2 Datenbanken (Shortterm + Longterm) ans das System angebunden für Datenein und ausgabe aber auch ins Backupkonzept automatisiert integriert.
    - Für die kontinuierliche Daten Aggregation ist explizit der Datenpunkt zu definieren. Bleibt also für immer die Notwendigkeit die Datenpunkte manuell zu pflegen in der Konfiguration, damit sie auch im Langzeitarchiv landen und nicht einfach im Kurzzeitarchiv gelöscht werden.
     
  4. Pete0815

    Pete0815 Benutzer

    Hi,
    habe nun 2 Datenbanken realisiert mit influxDB (shorterm + longterm) und lasse durch eine Continuous Query die Daten verdichtet in die Longterm Datenbank schreiben. Funktioniert fast gut. Problem ist ähnlich wie am Anfang. In Shortterm stehen die Sensordaten in W(att). Durch Nutzung der Aggregationsfunktionen lasse ich bei der Verdichtung zu Longterm das Integral bilden und das Ergebnis in kWh eintragen. Jetzt kommt der Zeitstempel wieder ins Spiel. Die Zeitperiode zur Verdichtung (zB 15 Minuten) bildet das Integral von "Jetzt" bis "Jetzt"-15Minuten. Der Zeitstempel in der Datenbank longterm wird aber zu Begin der 15Minuten übernommen also "Jetzt"-15Minuten. Die Produktion oder der Verbrauch hat zu diesem Wert aber er "Jetzt" statt gefunden. Somit eine Verfälschung. Bei 15M evtl. zu vernachlässigen aber setzt man größere Zeitperioden (Wochen, Monate) werden die Folgen erheblich.

    Habt ihr dazu eine Idee?
    Die Continuous Query lautet:

    CREATE CONTINUOUS QUERY "15mPWRACGes" ON "longterm"
    BEGIN
    SELECT INTEGRAL("value") /3600000 AS value
    INTO longterm.autogen."javascript.0.scriptEnabled.PV.WRPACges"
    FROM shortterm.autogen."javascript.0.scriptEnabled.PV.WRPACges"
    GROUP BY time(15m),*
    END


    Allgemein ist das doch generell ein Problem bei der Verdichtung. Bilde ich zB auch Summen oder Mittelwerte ändert sich durch diese Art der Verdichtung die Sichtweise auf die Daten im Bezug zum Zeitstempel. Ursprünglich zeigen Einträge in der Datenbank Werte für den Zeitraum vor Ihnen oder genau zu diesem Zeitpunkt. Nach der Verdichtung entsprechen die Werte aber der Zeit nach dem Zeitstempel. Wechsel von "Report/Bericht" zur "Vorhersage" Sichtweise. Mmmh
     
    Zuletzt bearbeitet: 29 November 2020
  5. Walter

    Walter Administrator Mitarbeiter

    Das Problem hast Du ja jetzt auch schon. In der aktuellen DB werden die Werte ja auch nicht in Millionestelsekunden Genauigkeit eingetragen, auch da wird ja in Wirklichkeit also schon verdichtet?

    Man muss sich halt einmal klar werden, auf welcher Zeitebene man verdichten will, nicht zu grob und nicht zu fein, es ist immer ein Abwägen von Speicherplatz/Performance und Genauigkeit.
     
  6. Pete0815

    Pete0815 Benutzer

    Ich sag mal Jaein. Die ursprüngliche Genauigkeit hängt mit der Abtastrate (Stützstellen) und benötigten Zeit für eine Verarbeitung zusammen. Das ist ein Geschichte aus der Messung heraus.

    Den Fehler/Ungenauigkeit durch die jetzige Verdichtung bekomme ich aber nicht durch die Messung sondern durch eine Verschiebung der Messdaten auf der Zeitachse. Würde man den Zeitstempel des letzten Datenbankeintrages übernehmen (und nicht den Ersten) für die Verdichtung ist der zusätzliche Fehler durch die Verdichtung gleich Null.

    Den Unterschied finde ich erheblich und wirft für mich die Frage auf, ob man deswegen diese Aggregate Kalkulationen so überhaupt bei einer Verdichtung nutzen sollte/kann. Bzw. Ob ich hier einen Fehler in der Umsetzung mache und es wesentlich besser zu lösen ist.

    Habe hierzu etwas für einen Offset für den Zeitstempel Grouped By gefunden, aber wenn ich es richtig verstehe, beeinträchtigt dass nicht nur den Zeitstempel sondern auch die Datenerfassung beim Verdichten. Somit denke ich nicht wirklich hilfreich in diesem Fall.
     
    Zuletzt bearbeitet: 29 November 2020
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden