[Konzept-Frage]Datenstrom verarbeiten und in DB schreiben

[Dennis89]

Hallo zusammen,

ich habe eine neue Aufgabe und bitte um eure Ratschläge.
Es gibt eine Maschine, an der werden zwei Mikrokontroller Stellmotoren steuern, die Einfluss auf das Maschinenverhalten haben. Ich habe einen Linux-Server, auf diesem läuft InfluxDB, Grafana und ein weiteres webbasiertes Programm, dass aber unabhängig von diesen Daten hier ist. Stand jetzt lade ich die Maschinendaten manuell auf den Server, die werden verarbeitet, in die DB geschrieben und mit Grafana dargestellt.

In Zukunft bekomme ich einen Datenstrom via OPC UA an den Server. Jede Sekunde kommen von unterschiedlichen Sensoren Werte an. Anhand einiger Werte will ich, je nach dem, wie die zueinander stehen, den Mikrokontroller via HTTP Befehle senden. Weiters sollen alle Werte in die DB geschrieben werden.

Ich stelle mir jetzt die Frage, was ist sinnvoller. Die Daten in die DB zu schreiben und separat eine DB-Abfrage des letzten Eintrags zu machen und dann die Stellmotoren zu steuern. Erst steuern und dann in die DB? Da die Werte eh nur jede Sekunde kommen und das System träge ist, muss ich nicht innerhalb einer 1/10 Sekunde reagieren.

Mir geht es auch darum, schreibe ich ein Programm und arbeite mit '`threading` und/oder `async` oder schreibe ich zwei separate Programme? Wie geht man da vor?
Kann ich irgendwie im Vorfeld herausfinden, ob mein Server das alles verarbeiten kann, von der Leistung? Gibt es mit zu vielen Lesezugriff auf die DB Probleme? (Ich glaube in diesem Bereich, ist meist viel mehr möglich, als ich immer denke. Mir fehlt da allerdings die Erfahrung und das soll stabil laufen)

Wenn es ganz andere Ansätze gibt, bin ich offen für alles. Letztendlich müssen meine zwei Stellmotoren geregelt werden, die Daten sollen in die Datenbank und ein Live-Dashboard mit Grafana wäre super.

Vielen Dank schon mal!

Grüße
Dennis

[grubenfox]

Ich stelle mir jetzt die Frage, was ist sinnvoller. Die Daten in die DB zu schreiben und separat eine DB-Abfrage des letzten Eintrags zu machen und dann die Stellmotoren zu steuern. Erst steuern und dann in die DB? Da die Werte eh nur jede Sekunde kommen und das System träge ist, muss ich nicht innerhalb einer 1/10 Sekunde reagieren.

Also das "separat eine DB-Abfrage des letzten Eintrags zu machen" erscheint mir jedenfalls sehr sinnlos zu sein. Die Daten gehen ja weder beim schreiben in die DB, noch beim ansteuern der Motoren irgendwie verloren.
Für alles weitere fehlt mir nun auch die Erfahrung. Wenn es nur eine Handvoll Daten sind, die da sekündlich kommen und verarbeitet werden müssen, dann würde ich denken "das passt schon irgendwie".

Auch wenn ich hier bei manchen Servern so 2-3mal pro Minute Daten abhole bzw. versende, dann sind auf der anderen Seite nur Menschen dran die mit den Daten arbeiten und keine Stellmotoren. Da ist eine Minute mehr oder weniger nicht systemkritisch.

[Dennis89]

Danke für deine Antwort.
Ich verstehe nicht, wieso das aus deiner Sicht sinnlos ist? Also ja, wenn alles ein Programm macht, dann ist es sinnlos, weil die Daten schon da sind. Wenn ich aber, so war es gemeint, ein separates Programm ausführe, dass die Motoren steuert, dann bekommt das die Werte über die DB-Abfrage. Der Teil greift schon etwas auf den nächsten Absatz vor. War eventuell nicht ganz ordentlich formuliert.

Grüße
Dennis

[grubenfox]

Ah, ja... ich war komplett bei "alles ein Programm". Wenn es das nicht ist bzw. wird, dann war meine Antwort hier der sinnlose Teil.

[sparrow]

@Dennis89: Ich mag es, Probleme immer aus der realen Welt heraus zu betrachten. Meistens ergibt sich dann schon eine Lösung und die Prioritäten fallen in eine "natürliche" Reihenfolge.

Wie kritisch ist der Prozess? Und wie kritisch sind die einzelnen Teile davon?
Ist es ok, dass nichts mehr gesteuert wird, wenn die Datenbank ausfällt?
Ist es wichtig, dass auf keinen Fall gesteuert wird, wenn es nicht auch in der Datenbank gelogt wird?

Den Weg über die Datenbank in die Steuerung würde ich vermeiden. Wenn du die Daten eingehend schon in der Verarbeitung hast, solltest du die auch gleich verteilen und nicht die Datenbank pollen. Auch wenn ich nicht weiß, ob InfluxDB da auch Trigger aussenden kann.

[noisefloor]

Hallo,

ich denke auch, dass der Ansatz bzw. die Fragen von @sparrow relevant für das Vorgehen sind: wer soll von wem abhängen bzw. gibt es überhaupt Abhängigkeiten? Wenn es keine gibt, kann man das ganze parallel machen, also man empfängt die Daten und schiebt diese in zwei Queues, aus der sich DB und Steuerung bedienen.

Gruß, noisefloor

[Dennis89]

Danke für die Antworten.

Der Ausfall der Datenbank sollte die Steuerung nicht beeinflußen. Okay damit hat sich das schon erledigt. Ich empfange die Daten und arbeite mit Qeues.
Es wäre natürlich schön, dass die Steuerung mit den Daten der Datenbank nachvollziehbar ist. Allerdings die Steuerung auszuschalten, weil die Datenbank nicht funktioniert, würde zur Folge haben, dass im besten Fall ein Mechaniker von Hand steuert und im schlechtesten Fall läuft sie in eine Störung und fährt herunter. Das ist nicht schön und kostet Geld (und Nerven).

Dann arbeite ich mit `threading`, es sei denn es gibt einen Grund, warum ich `async` oder `processing` verwenden sollte. Da müsste ich mich erst einarbeiten, daher bevorzuge ich das, was ich schon mal gemacht habe.


Danke und Grüße
Dennis

[imonbln]

Wenn es ganz andere Ansätze gibt, bin ich offen für alles. Letztendlich müssen meine zwei Stellmotoren geregelt werden, die Daten sollen in die Datenbank und ein Live-Dashboard mit Grafana wäre super.

Ich würde die Daten in einem Programm empfangen und dort ein Observer-Pattern (auch bekannt als Publisher/Subscriber) implementieren.
Die Subscriber könnten anschließend in einzelnen Workern laufen, wodurch du direkt ein Design erhältst, das offen für Erweiterungen ist.

[noisefloor]

Hallo,

...es sei denn es gibt einen Grund, warum ich `async` ...

`async` würde ja nur gehen, wenn die HTTP-Request und Datenbankanbindung async... await untersützen würden. Bei Request kein Problem, bei der Datenbank müsstest du mal in der Doku des Datenbankmoduls deiner Wahl nachschauen. Wobei ich hier auch nicht so wirklich einen Grund sehe, warum man `async` nehmen sollte.

Gruß, noisefloor

[Dennis89]

Dankeschön!

Die Beschreibung von @imonbln hört sich gut an. Ich werde mal schauen was ich zu den Schlagwörtern im Netz finde.

@noisefloor Ich bin froh, dass du keinen wirklichen Grund siehst. Wenn das mit den einzelnen `Worker` klappt, dann hat sich die Frage geklärt.


Grüße
Dennis