[DISKUSSION] Timeseries manipulieren / bearbeiten?

[StefanW]

Verehrte Foristen,

es ist nicht so, dass so eine Funktion nicht sinnhaft und wünschenswert ist, ich wünsche mir eine solche Bereinigungsfunktion auch.

Aber wir haben an die 500 kleine, mittlere und größere Wünsche auf unserer internen Long-List (diese Bereinigungsfunktion steht auch drauf).

Demgegenüber steht leider ein begrenztes Budget das es uns nicht erlaubt, alle Wünsche zeitnah abzubilden. Gerne würde ich noch ein Dutzend Programmierer einstellen, aber das würden uns die Nutzer nicht bezahlen wollen. Also müssen wir haushalten und das bedeutet priorisieren über die Zeit.

Es gibt nunmal einige Wünsche mit "älteren Rechten" und diese müssen wir vorrangig bedienen. Ich möchte hier an vergangene Diskussionen erinnern, in denen uns vorgeworfen wurde, dass wir frühere Versprechen nicht - oder nicht schnell genug - eingelöst haben. Unser Argument, dass wir dafür andere Leistungsmerkmale sehr viel besser ausgeführt haben, als das je geplant war und zusätzlich noch eine Menge "nachträglicher Extrawünsche" auf dem Weg umgesetzt hätten, wollten die Kritiker nicht gelten lassen.

Nehmen wir als Beispiel InstantVisu, DMX-V2-Erweiterung oder Lighting-Engine. Das sind Funktionen, die bereits ordentlich verspätet sind und von einer sehr großen Mehrheit gewünscht werden. Wer erklärt dieser Mehrheit nun, dass sie nun nochmal zwei bis vier Wochen warten müssen, weil - schon wieder - ein extra Feature "rein kommen muss". In einem anderen Portal wurden potentielle Kunden erst vor kurzem gewarnt, dass zwar jeder Kunde beim Timberwolf Server für Upgrades bezahlen soll, aber anschließend würde nur eine kleine Gruppe von Freaks über die Features bestimmen und Otto-Normalkunde geht unter. Das stimmt so nicht, weil wir immer große Abstimmungen machen, an denen jeder einfach teilnehmen kann, aber wenn ich solche Diskussionen wie diese hier sehe, dann verstehe ich den Kern solcher Vorwürfe schon und möchte daher nochmal auf die Interessenlage der überwiegenden Mehrheit hinweisen.

Gerne könnt Ihr über die Ausgestaltung dieses Leistungsmerkmales diskutieren. Ich will nur nicht dass der Eindruck entsteht, dass wir uns diesem Wunsch dann gleich im nächsten Monat annehmen werden, weil da wollten wir weiter an der ersten Version der InstantVisu arbeiten.

lg

Stefan

[Parsley]

Moin zusammen,

eine schöne Diskussion!

Mir gefällt der Ansatz von Yves:

Zunächst würde ich den Funktionsumfang genau definieren, welcher abgedeckt werden soll. Ich habe jetzt die alten Diskussionen dazu nicht nochmal gelesen aber AFAIR war der Anwendungsfall immer die Bereinigung der Timeseries.

Nennen wir die Funktion mal "Timeseries-Plausibilisierung". Damit könnte das so wie der bekannte Verknüpfungsassitent aussehen, in welchem als Input die gewünschte Timerseries-DB selektiert wird. Als Hauptfunktion gibt es nun zwei Optionen: "Entferne Werte grösser als" und "Entferne Werte kleiner als"

• Der Vorschlag passt in das bisherige Erscheinungsbild des TWS
• Er dürfte DAU-sicher sein.
• Er lässt sich in einzelnen Entwicklungsstufen modular um weitere Filter erweitern.

Neben den bisherigen Vorschlägen...

• Werte größer als X entfernen
• Werte kleiner als X entfernen
• Werte zwischen Zeitpunkten X und Y entfernen

...hätte ich einen weiteren Vorschlag:
Für MQTT subscriptions gibt es derzeit noch keinen Sendefilter, sodass ich aktuell alle Daten eines MQTT-Sensors in eine TS schreibe. Das werden auf die Dauer zu viele Werte sein... Außerdem gibt es ja scheinbar je nach "Sammelleidenschaft" der Kunden schon den einen oder anderen TWS, der an seine Speichergrenzen kommt. Daher würde ich mir auch Filter zur Auswahl wünschen, mit denen die Daten "ausgedünnt" werden können. Z.B. aufeinander folgende Werte mit einem Delta kleiner als X alle bis auf einen entfernen. Die Frage ist, ob sich so eine nachträgliche Bereinigung ausreichend performant umsätzen lässt.

Außerdem würde ich zur Auswahl stellen, ob als Output eine neue bereinigte TS angelegt werden soll, oder ob direkt die existierende bearbeitet werden soll. (Dicke rote Warnung dran, "wie viel ist 3+4?" eintragen lassen damit nicht versehentlich "ok" geklickt wird und dann sollte jeder wissen, was er mit seinen Daten tut. )

[Parsley]

Moin Stefan,

danke für deinen Post. Ich sehe dieses Feature genau wie du als nicht dringend an. Ich habe auch das Gefühl, dass hier in Thread mehrere es so sehen, dass diese Disskussion hilft dieses Feature genauer zu spezifizieren ohne ihm eine hohe Dringlichkeit zuzusprechen. Also alles gut.

Der MQTT Sendefilter wäre wie gesagt sinnvoll, aber eigentlich wollte ich nur kurz sagen: Ich freue mich schon auf die Visu!

[Dragonos2000]

So wirklich dringlich sehe ich es auch nicht- kommt halt eher selten vor, dass mal Bedarf zum Eingreifen besteht, vor allem wenn alles eingerichtet ist und einige Zeit stabil gelaufen ist. Sicher auch kein Fehler, generell eine Gültigkeitsprüfung des Wertebereichs zu konfigurieren (bspw. bei Modbus Profilen), um solche Fehler von vornherein zu reduzieren, die falsche Werte in die Timeseries schreiben könnten...

[Parsley]

Sicher auch kein Fehler, generell eine Gültigkeitsprüfung des Wertebereichs zu konfigurieren (bspw. bei Modbus Profilen), ...

...oder bei MQTT *duck* *wegrenn* (Sorry )

[starwarsfan]

Hallo miteinander

Außerdem würde ich zur Auswahl stellen, ob als Output eine neue bereinigte TS angelegt werden soll, oder ob direkt die existierende bearbeitet werden soll. (Dicke rote Warnung dran, "wie viel ist 3+4?" eintragen lassen damit nicht versehentlich "ok" geklickt wird und dann sollte jeder wissen, was er mit seinen Daten tut. )

Und genau das sollte es eben nicht geben! Wozu? Das ist IMHO überflüssig, birgt dennoch das Risiko für den Support und bedingt schlussendlich intern ein wesentlich komplexeres Vorgehen beim bearbeiten ein und derselben TS-DB, als wenn diese lediglich gelesen, gefiltert und in eine andere TS-DB geschrieben werden soll.

[StefanW]

nicht[/b] geben! Wozu? Das ist IMHO überflüssig, birgt dennoch das Risiko für den Support und bedingt schlussendlich intern ein wesentlich komplexeres Vorgehen beim bearbeiten ein und derselben TS-DB, als wenn diese lediglich gelesen, gefiltert und in eine andere TS-DB geschrieben werden soll.

Ich fürchte, es ist nicht so einfach, wie Ihr Euch das vorstellt.

Die Influx-DB ist insbesondere deshalb so gut (und geeignet für ein Embedded Device wie den TWS) weil diese eine extreme verlustfreie Kompression bis 98% hat. Dies kommt dadurch, dass von Datensatz zu Datensatz einer Zeitserie nur die Veränderungen in wenigen Bits gespeichert werden. Im Extrem bedeutet das, wenn exakt alle 5 Minuten ein Wert kommt und dieser keine Änderung zum vorhergehenden Wert aufweist, dann reicht es zwei Bits mit 00 zu speichern. Die erste Null steht für keine Abweichung beim Intervall und die zweite Null steht für keine Abweichung beim Wert. Es wird nicht genau so gemacht, aber gibt eine Idee wie das mit der Kompression geht.

Diese Kompression passiert nicht laufend, sondern in Intervallen. Wird sehr viel in eine Zeitserie geschrieben, landet das erstmal unkomprimiert auf der Platte und wird dann später über Kompressionsläufe in die eigentliche DB gepackt.

Wird nun eine TS komplett einmal neu geschrieben, dann haben wir letztlich eine komplette Zeitserie mit nicht komprimierten Daten und das kann auf kleinen TWS dann zu einem Problem führen, weil ein 16 GB TWS hat nur 5 GB frei und wenn 3 oder 4 GB durch Zeitserien vollgeschrieben sind und man will sowas mit einer großen Zeitserie machen, dann könnte das zum Vollschreiben der Platte usw. führen. Klar. kann man alles abfangen, aber muss gemacht und getestet werden.

Ich bitte darum uns zu glauben, es ist schon ein bisserl aufwändig. Darum auch der Vorschlag von unserem Entwickler, dass die Bereinigung in der originalen Zeitserie ausgeführt wird.

lg

Stefan

PS: Ich stecke gerade Beintief in mehreren Projekten, ich kann hier nicht so teilnehmen, will aber auch nicht, dass Dinge konstruiert werden, die zu einer Massenoperation führen können, die auf den kleinen Devices schwierig werden.

[Sensej]

Darum auch der Vorschlag von unserem Entwickler, dass die Bereinigung in der originalen Zeitserie ausgeführt wird.

Ja, bin auch der gleichen Meinung.
Alle Operationen an der originalen TS durchführen und nicht zuerst eine Kopie der TS erstellen oder sichern, exportieren und importieren usw.
Dies alles wird nicht benötigt, wenn man nur paar Datensätze löschen oder ändern will, sondern macht die Entwicklung nur aufwendiger.
MfG Juri

[Sensej]

Sollen grundsätzlich solche Wertwiederholungen entfernt werden? Das wäre wieder eine andere Funktionalität und ist schwerer umsetzbar.

Wieso schwerer?
ne, schwerer ist es nicht. Die Datensätze mit gleichen Werten müssen genauso behandelt werden, wie alle anderen.

MfG Juri

[starwarsfan]

Hallo miteinander

Alle Operationen an der originalen TS durchführen und nicht zuerst eine Kopie der TS erstellen oder sichern, exportieren und importieren usw.
Dies alles wird nicht benötigt, wenn man nur paar Datensätze löschen oder ändern will, sondern macht die Entwicklung nur aufwendiger.

Das sehe ich definitiv anders. In meinem Vorschlag gibt es keine Kopie der DB, es gibt keinen Export und auch keinen Import. Das ist gelinde gesagt ein lesen, filtern und schreiben in eine neue TS, von daher definitiv einfacher u/o sicherer, als das an der vorhandenen DB zu machen. Dabei wäre es mir sehr viel wichtiger, die Originaldaten noch zu haben und nicht direkt daran herumzuoperieren. Wenn diese einmal ausgedünnt sind, ist Schluss mit lustig.

Das einzige Argument ist das von Stefan genannte bzgl. dem potentiellen Platz-Problem und das ist natürlich essentiell wichtig, ohne Frage.

Aber wie auch immer, wir sind hier beim Brainstorming und schon allein aus diesem Grund finde ich es extrem produktiv, verschiedene Optionen zu besprechen. Ganz egal wie das Resultat dann ausssehen wird. Stefan und seine Jungs haben bisher immer geniale Lösungen geliefert. Wird schon werden.