Software-Datenmodell Redesign - Möglichkeiten

[SusiT]

Hallo,

aktuell befinde ich mich in der Planung für eine Überarbeitung einer bestehenden Anwendung.
Die Anwendung läuft auf mehreren Clients im Netzwerk die ihre Daten von einem Dienst auf einem Server via TCP erhalten.
Der Dienst versendet die Events als ClientDataSet binary.

Bisher werden sämtliche Daten des Programmes in verschiedenen TClientDataSets gehalten.
Updates und Inserts werden mittels des empfangenen Event-ClientDataSets via Edit oder Append im jeweiligen ClientDataSet ergänzt.
Dieser Vorgang findet in einem gesonderten Thread statt, der ausschließlich für das Eventing verantwortlich ist.
Um die Anwendung Threadsafe zu gestalten werden TMultiReadExclusiveWriteSynchronizer Instanzen verwendet um den Zugriff auf die ClientDataSets zu managen.
Bei höheren Datenlasten (ca. 2 Update/Insert Events pro Sekunde) spürt man allerdings in der GUI das im Hintergrund einiges vor sich geht.

Die Anwendung wurde damals in Delphi 7 programmiert, später auf XE2 migriert und vor einem Jahr auf Delphi 10 Seattle.
Eine Migration auf Delphi 12.1 Athens ist für die Zukunft bereits geplant.

Da die Architektur mittlerweile schon gut 20 Jahre alt ist und mit ihren Aufgaben über die Zeit hinweg wuchs, wollte ich mich erkundigen ob es neuere, eventuell bessere Möglichkeiten gibt um die Daten in der Anwendung zu managen. Der Serverdienst muss nicht in diesem Format bestehen bleiben, hier besteht ebenfalls die Möglichkeit einer Überarbeitung.

Zu meiner Frage:

1. Gibt es modernere/praktischere Lösungen als die aktuell bestehende Architektur? Wenn ja, welche Möglichkeiten gibt es noch?

Ich bin über jede Möglichkeit/Anregung/Idee dankbar

[Papaschlumpf73]

Das klingt so, als müssten die Clients quasi live über alle Datensatzänderungen informiert werden. Eine Abholung der Daten durch die Clients (bei Bedarf) ist da wahrscheinlich nicht möglich, oder?

Kannst du bitte noch dazu schreiben, um wieviele Clients es sich handelt und wie groß die Datenmengen ungefähr sind?

[jaenicke]

Die wichtigste Frage:
Sollen es Bordmittel sein (FireDAC kann eine Menge) oder kann es auch ein gutes kommerzielles Framework sein (TMS hat da ein paar Sachen)?

Und dann gibt es noch mORMot als Open Source, das sehr viele Features hat, aber auch eine etwas steiler Lernkurve.

Dann kommt aber schon die nächste Frage:
Gibt es konkrete Probleme, wegen der eine Änderung angedacht ist? Oder geht es lediglich um eine Modernisierung der bestehenden Features? Oder wären weitere Features erwünscht?

Mit der Lösung von TMS wäre z.B. eine automatische Verteilung der Änderungen möglich.

[SusiT]

Korrekt, die Datenänderungen kommen vom Server. Dort gehen über andere Wege Daten ein, werden aufbereitet und in einer Datenbank gespeichert. Via einem internen Eventing-System werden
dann die geöffneten Clients mit den Datensätzen "versorgt". Somit ist ein "abholen" der Daten durch den Client nicht die beste Lösung.

Die Anzahl der geöffneten Clients variiert zwischen 1-20, mehr werden es nicht.
Bei der Größe der Datensätze gibt es Unterschiede, es können von 20 Datensätze/Stunde bis 5000 Datensätze/Stunde Daten eingehen. Das hängt von mehreren unterschiedlichen Faktoren ab.
Ein Datensatz hat laut Tabellendefinition ca. 4 Kilobyte. Natürlich gibt es noch weitere Tabellen die ebenfalls Änderungen erhalten und über das Eventing-System aktualisiert/ergänzt werden.

Wichtig dabei ist noch zu erwähnen, das jeder Client nicht unbedingt die selben Datensätze erhält, das ist abhängig von den Sichtrechten des jeweils angemeldeten Benutzers.
Die Selektierung der Events pro Benutzer/Client erfolgt aber bereits über das Event-System innerhalb der Datenbank, sodass die Insert/Update/Delete Events bereits aufbereitet in einer entsprechenden Tabelle vorliegen. Dieser Eintrag beinhaltet dann die Information welcher angemeldete Benutzer, welchen Datensatz aus welcher Tabelle "nachgeschoben" bekommt und ob es sich um ein Insert/Update/Delete handelt.


Es können sowohl Boardmittel als auch kommerzielle Produkte von Drittanbietern in Frage kommen. Boardmittel werden natürlich bevorzugt, sollte eine Drittanbieter-Lösung aber den Entwicklungsaufwand beschleunigen so ist diese auch von Interesse.


Generell ist eine Modernisierung angedacht da sich bei höherem Datendurchsatz (den gab es in unserer Anwendung früher nicht, aber die Anforderungen änderten sich über die Jahre)
die Anwendung in der Handhabung etwas verschlechtert, zum Teil verzögert sich das öffnen von weiteren Formularen die auf bestimmte ClientDataSets zugreifen da dieses gerade durch Update-Vorgänge geblockt sind. Da die Client PCs zum Teil auch etwas veraltet sein können, ist auch das Datenmanagement hinsichtlich des Arbeitsspeichers nicht zu vernachlässigen.

Im Optimalfall wäre da eine getrennte, Threadsafe Möglichkeit, sodass die Usability nicht unter der Datenlast leidet.

[Papaschlumpf73]

Dann würde ich im ersten Schritt prüfen, ob der Flaschenhals tatsächlich bei den Clients oder am Server ist. Wenn es nur die Clients sind, würde ich das ganze System nicht über den Haufen werfen, sondern nur die Verarbeitung der Datensatzänderungen auf den Clients optimieren. Never change a running system.

[SusiT]

Erstmal danke für eure schnellen Reaktionen und Anregungen.

Der Server sendet soweit zuverlässig und schnell, dort sehe ich soweit erstmal keine Probleme.

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

[jaenicke]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

Soweit ich weiß, gibt es das nicht.

Das hat aber auch den Hintergrund, dass du Locks bei einer eigenen Implementierung optimieren kannst, während eine allgemeine threadsichere Implementierung alles absichern müsste.

FireDAC ist z.B. bei reinen Lesezugriffen auf geklonte Datasets threadsafe.

Eine Idee zur Optimierung:
Halte einfach für jeden Client zwei DataSets vor. Eins ist das, das bei einer Anfrage geliefert wird, das andere bekommt ein Update. Nach dem Update tauschst du threadsicher die beiden DataSets aus.

Das hat den Vorteil, dass eine Datenanfrage immer schnell beantwortet wird, dafür eine im Moment der Anfrage eingespielte Datenänderung erst bei der nächsten Lieferung enthalten ist.

Ich bin gerade im Urlaub und schreibe am Handy. Insofern kann ich aktuell schlecht recherchieren.

[Papaschlumpf73]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?

Das kann ich mir kaum vorstellen. Ich würde die Datenaktualisierung auch immer nur seriell vornehmen. Wenn z.B. ein Datensatz geändert und kurz danach gelöscht wird (auf dem Server), und der Client verarbeitet die beiden Änderungen nicht seriell, könnte der Datensatz im Client zuerst gelöscht und dann... nicht mehr gefunden werden.

[Uwe Raabe]

Ich könnte mir vorstellen, dass ein Abrufen der Daten mit einer TFDQuery unter den FireDAC-Regeln für Multi-Threading mit anschließend synchronisierter Übergabe an ein TFDMemTable in den Hauptthread durch simples Zuweisen des Data Properties ein brauchbarer Ansatz wäre.

[SusiT]

@PapaSchlumpf73:

Da hast du vollkommen recht, dieses Szenario habe ich so nicht bedacht.

@jaenicke:

Die Idee für die Optimierung klingt einleuchtend. Im Grunde halte ich dann ein CDS in einem separaten Event-Thread welcher die Updates erhält und in sein CDS einfügt.
Nach dem erfolgreichen Einfügen könnte ich den kompletten Inhalt des CDS dann in das CDS im MainThread kopieren.

Wäre es auch möglich via CloneCursor die Anzeige im MainThread auf die im Event-Thread zu referenzieren? Im Grunde "lese" ich die Daten ja ausschließlich im MainThread um sie dort dem Benutzer zu präsentieren. Oder geht das mit herkömmlichen ClientDataSets nicht und ich müsste auf die FireDac Äquivalente umsteigen?


@Uwe Raabe:

Das ist so leider nicht möglich da die Clients keine direkte Verbindung zur Datenbank haben.