AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Software-Datenmodell Redesign - Möglichkeiten

Ein Thema von SusiT · begonnen am 1. Aug 2024 · letzter Beitrag vom 4. Aug 2024
Antwort Antwort
Seite 1 von 2  1 2   
SusiT

Registriert seit: 15. Mai 2014
40 Beiträge
 
#1

Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 08:19
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
  Mit Zitat antworten Zitat
Papaschlumpf73
Online

Registriert seit: 3. Mär 2014
Ort: Berlin
396 Beiträge
 
Delphi 12 Athens
 
#2

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 09:32
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?

Geändert von Papaschlumpf73 ( 1. Aug 2024 um 09:34 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.565 Beiträge
 
Delphi 11 Alexandria
 
#3

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 09:34
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
SusiT

Registriert seit: 15. Mai 2014
40 Beiträge
 
#4

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 11:03
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.

Geändert von SusiT ( 1. Aug 2024 um 11:08 Uhr)
  Mit Zitat antworten Zitat
Papaschlumpf73
Online

Registriert seit: 3. Mär 2014
Ort: Berlin
396 Beiträge
 
Delphi 12 Athens
 
#5

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 11:16
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.
  Mit Zitat antworten Zitat
SusiT

Registriert seit: 15. Mai 2014
40 Beiträge
 
#6

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 13:08
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?
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.565 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 15:11
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Papaschlumpf73
Online

Registriert seit: 3. Mär 2014
Ort: Berlin
396 Beiträge
 
Delphi 12 Athens
 
#8

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 15:12
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.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.381 Beiträge
 
Delphi 12 Athens
 
#9

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 1. Aug 2024, 17:10
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
SusiT

Registriert seit: 15. Mai 2014
40 Beiträge
 
#10

AW: Software-Datenmodell Redesign - Möglichkeiten

  Alt 2. Aug 2024, 10:46
@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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:00 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz