Spezialist gesucht: Synchronisation von SQL-Datenbanken für flottes mobiles Arbeiten

[kexbox]

ANZEIGE

Hallo in die Runde,

meine Branchensoftware nutzt zwei Datenbestände: Einerseits werden Dokumente als PDF- und Docx-Datei abgespeichert. Die sonstigen Daten liegen in einer SQL-Datenbank.

Es stellt sich mir nun die Herausforderung, von verschiedenen Orten gleichzeitig darauf zuzugreifen zu müssen, das auch mit teils schlechter Internetverbindung (Abbrüche, hohe Latenz). Lösungen wie RDP scheiden daher aus, weil es extrem nervig bei der Nutzung ist. Damit unterscheide ich mich auch von den üblichen Nutzern dieser Software, weswegen es für mein Problem keine Lösung von der Stange gibt.

Meine Idee: Der mobile Arbeitsplatz hat die SQL-Datenbank (und natürlich die Docx- und PDF-Dateien) lokal dabei und synchronisiert entweder regelmäßig oder nur auf Anforderung die Änderungen mit einem zentralen Server. Damit ist der Datenzugriff stets flott, dennoch arbeiten alle - wenn auch leicht verzögert - auf dem gleichen Datenbestand.

So eine Lösung muss natürlich Hand und Fuß haben, darf mir nicht meine Datenbank zerschießen. Hat jemand einen Tipp, wer sowas kann?

 

[Langstreckenpendler]

Das ist erstmal nichts was ohne irgendwelche Vorbedingungen out of the box geht.
Datenbankverbindungen mit Verbindungsabbrüchen sind noch schlechter als eine wieder herzustellende RDP-Verbindung.

Generell muss sowas konzeptionell in der Software bzw. Datenbankstruktur bedacht werden, nur in wenigen Fällen (bei fehlenden Änderungen auf einer Seite) geht eine Synchronisation nach einer Offline-Phase problemlos, wenn die Datenbestände (bzw. Teile davon) nicht vorab gesperrt wurden.

Daher erstmal 2 Fragen:
1. Welchen SQL-Server nutzt Du?
2. Nutzt Du alleine den Datenbestand oder arbeitet im Büro noch jemand zeitgleich (schreibend) mit den Daten während Du unterwegs bist?

Die Dateispiegelung geht z.B. per rsync, auch unter Windows. Die Anpassung der Pfade müsste - so die Dateien nicht auch in der Datenbank abgelegt sind durch ein Stück Software erfolgen.

 

[kexbox]

Danke für Deine Antwort.

1. Gupta SQLBase
2. Ja, es soll an beiden Standorten gearbeitet werden können. Ein gleichzeitiges Arbeiten in einer Akte ist aber eher nicht der Fall. Wenn doch, dann soll eben der aktuellste Datensatz zählen


Die Synchronisation der statischen Dateien ist wohl das kleinste Problem hier, jep.

 

[marcus67]

Am Ende ist das eher eine typische RDP Anwendung.

Beim Remotezugriff auf Datenbanken und auch deren Synchronisation, sind die großen Latenzzeiten der WAN Verbindungen immer ein Problem.

 

[marcus67]

Ich kenne jetzt Gupta nicht. Die "großen" Enterprise SQL Datenbanken (Oracle, MS SQL ...) unterstützen alle verteilte Datenhaltung ohne zusätzliche Tools. Dabei synchronisiert die Datenbank selbst die unterschiedlichen Speicherorte. Das setzt aber durchaus ordentliche WAN Bandbreiten voraus, da dies nicht immer sparsam erfolgt.

 

[Langstreckenpendler]

Danke für Deine Antwort.

1. Gupta SQLBase
2. Ja, es soll an beiden Standorten gearbeitet werden können. Ein gleichzeitiges Arbeiten in einer Akte ist aber eher nicht der Fall. Wenn doch, dann soll eben der aktuellste Datensatz zählen


Die Synchronisation der statischen Dateien ist wohl das kleinste Problem hier, jep.

Das mit dem aktuellsten Datensatz ist bereits ein Thema, was datenbankseitig vorhanden sein muss („Modified_Date“), wenn es in beide Richtungen gehen muss (das ist die Aussage Deines des ersten Satzes).
Und so ein Datenabgleich muss nicht nur mitbekommen, wenn ein Datensatz geändert wurde sondern auch, wenn ein neuer Datensatz erstellt wurde oder auch wenn einer gelöscht wurde. Mit der passenden Bandbreite schafft man es aber innerhalb derselben Datenbankserver-Software, dass es mehr als eine Maschine ist - aber das ist eine reine Online-Funktionalität.

Du schriebst oben, dass es Verbindungsabbrüche etc. gibt, also keine Online-Funktionalität.

Das ist der schwierige Teil, da es eine Art Offline-Funktionalität braucht, d.h. die Verbindung der Datenbanken nicht permanent ist und der Datenabgleich nicht im Hintergrund durch den Datenbankserver z.B. unmittelbar im Rahmen der (Datenbank-)Transaktion erfolgen kann und bei jeder Wiederherstellung der Synchronisation Konflikte auftreten können.
Denn problematisch wird es, wenn in einem solchen Offline-Szenario zwischen 2 Synchronisierungen auf beiden Seiten neue Datensätze erstellt werden, deswegen ist es ein Software-Thema. Dafür müsste es entweder Schlüsselbereiche für den Primary Key in einen einzelnen Tabellen oder eine Standort-ID als Bestandteil des Primary Keys geben - auf alle Fälle eine Lösung, wie sichergestellt ist, dass nicht dieselben Schlüssel auf beiden Seiten zeitgleich erstellt werden bzw. eine Lösungsmöglichkeit für den Konfliktfall.

Es gibt solche Lösungen z.B. für MS SQL Server bzw. vielmehr Azure (also der Cloud-hosted SQL-Server)

What is SQL Data Sync

In this article, a base concept of how the SQL Data Sync service works will be explained as well as what the requirements and limitations are.

www.sqlshack.com

Eventuell geht noch DBMoto

https://informationstore.dscallards.com/dbMotoV6_dsheet.pdf

Allerdings ist in der Neuzeit - das Produkt heißt inzwischen Syniti Data Replication - kein SQLBase mehr aufgeführt.

Syniti Data Replication funktioniert einfach | HiT Software Deutschland und Österreich

Syniti Data Replication (DBMoto) vereinfacht Datenreplikation, Erfassen von Datenänderungen, zwischen gängigen Datenbanken, Analytik-Systemen, Big Data.

www.hitsw.de

 

[kexbox]

Hier Listen sie es noch:

Gupta SQLBaseTopics

sdrhelp.syniti.com

Das klingt spannend! Also: habt ihr eine Empfehlung, wer sowas betreut?

 

[kexbox]

Am Ende ist das eher eine typische RDP Anwendung.

Beim Remotezugriff auf Datenbanken und auch deren Synchronisation, sind die großen Latenzzeiten der WAN Verbindungen immer ein Problem.

Tastenkombination STRG+A, um Text in Word zu markieren. Und die Wartezeit, bis man es in Word sieht. Leider ist RDP (und ich habe auch Rustdesk probiert) da nicht brauchbar. Das wäre natürlich die einfachste Lösung gewesen. Daher die Idee mit den lokalen Datenbeständen, die sich regelmäßig abgleichen, wenn wieder mehr Bandbreite vorhanden ist (die gesamte Datenbank ist nur rund 100 MB groß, wächst pro Jahr um 30 MB)

 

[marcus67]

Was für WAN Verbindungen/VPN nutzt Ihr denn? Wir haben früher häufig RDP über eine VPN Verbindung über LTE aus Südafrika genutzt. Das war nicht toll, aber gut nutzbar.

 

[kexbox]

Was für WAN Verbindungen/VPN nutzt Ihr denn? Wir haben früher häufig RDP über eine VPN Verbindung über LTE aus Südafrika genutzt. Das war nicht toll, aber gut nutzbar.

Wireguard. Über LTE ist das bei gutem Netz kein Ding. Aber bei schlechtem Netz eben sehr wohl (z.B. bin ich in einer Woche für ein paar Tage mit einem Ping von ~ 500 ms "gesegnet")

 

[Hauptmann Fuchs]

Wireguard. Über LTE ist das bei gutem Netz kein Ding. Aber bei schlechtem Netz eben sehr wohl (z.B. bin ich in einer Woche für ein paar Tage mit einem Ping von ~ 500 ms "gesegnet")

@marcus67 meinte wohl eher welche Verbindung du im Büro hast, ob Wireguard oder OpenVPN (CPU auf dem Server vorausgesetzt, was in deinem Fall vielleicht einen NAS ist) ist egal für die Latenz.

Wenn du aber angebunden bist von Vodafone Unitymedia und deren etwas entäuschende Peerings (= ihre Verbindungen nach andere Provider), dann kann es sehr wohl sein dass die Verbindungen etwas lahm sind, da sie über exotische Routen laufen. Eventuell steigert auch CGNAT noch mal die Latenz, bis jetzt noch keinen Hotel gehabt wo IPv6 funktioniert seitdem ich meinen eigenen Server umgestellt habe.

 

[Nitus]

Wireguard. Über LTE ist das bei gutem Netz kein Ding. Aber bei schlechtem Netz eben sehr wohl (z.B. bin ich in einer Woche für ein paar Tage mit einem Ping von ~ 500 ms "gesegnet")

500ms Ping bei LTE? Nutzt Du einen LTE-Router oder hast Du die LTE-Verbindung über das Handy freiegeben?

Entweder warst Du da in einer sehr vollen Zelle und/oder hast einen schlechten mobilen LTE-Router. Leider beherrschen nicht alle Router Carrier-Aggregation bzw. verhalten sich nicht immer sauber in Bezug auf die Lastverteilung der Basisstation.

 

[spremmse]

Das klingt spannend! Also: habt ihr eine Empfehlung, wer sowas betreut?

Diese Frage kann ich dir leider nicht beantworten, aber würde dir nahelegen, das durchaus mal beim Hersteller deiner Branchensoftware anzusprechen (falls nicht ohnehin schon geschehen?).
Die hier angesprochenen Lösungen basieren scheinbar alle auf dem inkrementellen Synchronisieren von Diffs, was bei manchen Datenbankdesigns auch durchaus zu Problemen führen kann (hatte Langstreckenpendler ja bereits angesprochen).
Hinzu kommt ja auch die Herausforderung, die Lösung zwischen eine bestehende Datenbankverbindung zwischen lokaler Software und Datenbankserver zu klemmen, heißt also die Konfiguration muss nochmal neu gesetzt werden - aber vielleicht ist das bei Advoware ohnehin Teil der Anwenderkonfiguration?

Vor diesem Hintergrund würde ich zuerst die Hersteller der beiden Lösungen kontaktieren - und schauen ob die Integrationspartner haben oder sogar selbst sind.

Außerdem würde ich mir an deiner Stelle auch noch folgende Lösungen anschauen: https://symmetricds.org/ - weiß aber nicht inwiefern dass mit eurem System kompatibel ist.

Am ende des Tages ist und bleibt die Herausforderung das Lösen von Konflikten und Kollisionen von offline veränderten Datensätzen. Gut, dass du bereits eine klare Vorstellung hast welche Regeln hier anzuwenden sind. Fraglich bleibt ob sich das so automatisieren lässt, und wie ihr mit Spezialfällen umgeht (z.B. einer Tabelle mit Nutzereinstellungen die außer Sync gelandet ist).

 

[Hauptmann Fuchs]

500ms Ping bei LTE? Nutzt Du einen LTE-Router oder hast Du die LTE-Verbindung über das Handy freiegeben?

Na ja, 500ms Ping nach wo? Nach Hause (in Deutschland, von LA aus), zum ersten Hop oder zu irgendeinen Server an der anderen Seite der Erde?

 

[Nitus]

Wenn du aber angebunden bist von Vodafone Unitymedia und deren etwas entäuschende Peerings (= ihre Verbindungen nach andere Provider), dann kann es sehr wohl sein dass die Verbindungen etwas lahm sind, da sie über exotische Routen laufen. Eventuell steigert auch CGNAT noch mal die Latenz, bis jetzt noch keinen Hotel gehabt wo IPv6 funktioniert seitdem ich meinen eigenen Server umgestellt habe.

Keiner der deutschen Netzbetreiber dürfte ein derart schlechtes Peeringkonzept haben, dass es zu 500ms Latenz bei einem Ping aus den deutschen Mobilfunknetzen zu einem deutschen Festnetz-Internet-Anschluss kommen kann. Hier kann das Problem eigentlich nur auf der Luftschnittstelle gelegen haben. Suboptimale Routings würden zu wenigen Millisekunden mehr Roundtrip Time fühen aber nicht zu einer halben Sekunde.

 

[marcus67]

500ms ist schon sehr viel.

Gerade nachgesehen:
DE-Südafrika Kabel -> Glasfaser (in ZA) 175ms
DE-Südafrika Kabel -> LTE 230ms
DE-DE DSL -> LTE 150ms
DE-DE Kabel -> Kabel 17ms

Jeweils Host zu Host über IPSec.

Selbst über die 230ms kann man mit RDP noch zufriedenstellend arbeiten. Die 175ms funktionieren schon sehr gut. 17ms ist wie lokal.

 

[spremmse]

500ms ist schon sehr viel.

Gerade nachgesehen:
DE-Südafrika Kabel -> Glasfaser (in ZA) 175ms
DE-Südafrika Kabel -> LTE 230ms
DE-DE DSL -> LTE 150ms
DE-DE Kabel -> Kabel 17ms

Jeweils Host zu Host über IPSec.

Selbst über die 230ms kann man mit RDP noch zufriedenstellend arbeiten. Die 175ms funktionieren schon sehr gut. 17ms ist wie lokal.

Wenn ich das richtig sehe hat OP nie behauptet dass die 500ms bei LTE auftreten, außerdem sind für den beschrieben use case ja round-trip Latenzen im VPN ausschlaggebend. Da landet man dann schnell im Bereich mehrerer Sekunden!

Stell dir mal ein anderes Szenario vor, z.B.: US-midwest 3G - Server an einem regulären Firmenstandort in DE hinter router, firewall etc., dann den ganzen spaß wieder zurück. Das schaffst du kaum unter 2 Sekunden, und dann auch noch alles innerhalb des VPN mit handshakes etc..

Das Netzwerk ist das Netzwerk, daran können wir nix ändern, genau so wenig wie an der Voraussetzung sicherer Datenspeicherung und -übertragung.

Der OP hat nun zwei Hebel das Problem zu lösen: Endgerät oder Serverseitig.
Für die meisten Anwendungen würde ich hier Serverseitig viel Spielraum sehen, z.B. mit dem Server in ein Rechenzentrum zu ziehen, welches direkt an einen großen Knoten angeschlossen ist, oder auf eine distributed Lösung zu gehen. Moderne Anwendungen werden ja ohnehin so gebaut. Für das bestehende System mag das aber nicht funktionieren, vielleicht auch aus Sicherheitsgründen.
Das lokale Zwischenspeichern ist hier eben der andere Vektor und bring weitere Vorteile, insbesondere wird es so möglich vollständig offline zu arbeiten, also auch im Flieger, im Wald etc.. Außerdem ist bei der von mir beispielhaft beschriebenen Kette das 3G-Endgerät das mit abstand schwächste Glied, wir haben hier also den größten Hebel.

Wäre ich damit betraut eine Softwarelösung unter diesen Requirements zu designen würde ich vermutlich andere Wege gehen. Innerhalb bestehender Systeme muss man nunmal Lösungen finden die nicht ganz straightforward sind. Auf biegen und brechen Latenzzeiten gewinnen, nur um die Requirements zu umgehen und doch RDP zu ermöglichen halte ich professionell betrachtet nicht für sinnvoll.

 

[marcus67]

Wenn ich das richtig sehe hat OP nie behauptet dass die 500ms bei LTE auftreten, außerdem sind für den beschrieben use case ja round-trip Latenzen im VPN ausschlaggebend. Da landet man dann schnell im Bereich mehrerer Sekunden!

Nur um das klarzustellen: Meine Zeiten waren roundtrip komplett durch das VPN. Die reinen Ping Latenzen sind natürlich noch kleiner.

 

[kexbox]

Wo tritt so eine Latenz oder auch mal ein mehrsekündiger Totalausfall auf: In der Bahn, s. dazu oben das Video. An der Stellschraube lässt sich also leider nicht drehen.

Der Softwarehersteller hat eine Lösung für mobiles Arbeiten: RDP. Das ist hier nur leider nicht tauglich.

 

[marcus67]

Ich fürchte da wird nicht viel zu machen sein. Klar, man könnte über verteilte Datenhaltung komplett offline arbeiten.

Unter diesen Umständen ist dann aber das Risiko von Problemen bei der Synchronisierung der Datenbestände sehr groß.

Es geht ja nicht nur um evtl. Kollisionen wenn Datensätze an mehreren Stellen bearbeitet werden. Auch interne Sequenzen und Zähler können Offline u.U. nicht mehr zusammengeführt werden Daher wird u.U. auch eine gezielte Synchronisation sobald wieder eine stabile Internetverbindung vorhanden ist, nicht helfen.

 

[spremmse]

Weil ich das Thema grundsätzlich ganz interessant finde, hier der Ansatz den ich wählen würde wenn ich ein solches System von Grund auf entwerfen müsste:

Eine Art Offline-Modus, welche die gesamte Datenbank in einem lokalen State vorhält und (z.B.) auf Knopfdruck aktualisiert. Dieser State verhält sich hin zum Client wie eine normale Datenbank (basiert eventuell auch auf einer) - aber anstatt den lokalen State als "echte" Datenbank mit der Remote DB am Server zu synchronisieren werden zusätzlich alle Transaktionen abgespeichert, quasi wie eine Art Migration. Wird nun synchronisiert, werden der Reihe nach alle bearbeiteten Einträge nach neueren Updates Überprüft, und sollte keines vorliegen wird die Transaktion persistiert. Anschließend wird der lokale State auf den Stand der remote vollständig aktualisiert.

Im groben und ganzen ist das ein Design Pattern nachdem viele moderne Cloud-Apps ihre Offline-Modi gestalten, allerdings über simplere States und nicht über eine ganze Datenbank.

Dieses Design u.U. nicht kompatibel mit dem gegebenen Client, wir kennen das aktuelle Datenbankdesign nicht - und zudem besteht das Risiko, dass zwischen Datenbankdaten und Filesystemdaten Referenzen kaputt gehen könnten. Zudem muss der Edge-Case geklärt werden falls eben doch ein jüngeres Update vorliegt, und zu guter letzt findet all das außerhalb des Clients statt, heißt der Client muss während der Synchronisation geschlossen sein, darf keinerlei eigene Caches oder Referenzen speichern. Und weil das nicht genug ist, müsste zudem auch noch das synchroniseren nach unten (Server -> Lokal) optimiert werden, damit nicht immer die ganze DB geladen werden muss.

Inwiefern Syniti und SymmetricDS ein solches Pattern abbilden können weiß ich nicht genau, müsste eben entsprechend geprüft werden. Ob es Systemhäuser gibt, die einem sowas für Individualsoftware einrichten wage ich zu bezweifeln, insbesondere wenn es sich um derart sensible Daten handelt.

Im Enterprise-Bereich wird sowas durchaus angeboten, z.B. bei Microsoft PowerApps https://learn.microsoft.com/en-us/power-apps/mobile/offline-capabilities

 

[EDFE]

Gupta SQLBase

Ich höre von diesem DBMS das erste Mal und habe es aus Interesse gegoogelt und mich zur Kontoerstellung motivieren lassen (lese bereits lang mit).

SQLBase scheint mir ein 1-tier DBMS zu sein wie z.B. auch das bekanntere SQLite. Aus eigener Erfahrung weiß ich, dass SQLite selbst mit wenig Clients schnell zu zicken anfängt, sobald ein Netzwerkdateisystem im Spiel ist.

Das ist keine Lösung, da SQLBase in dieser Kanzleisoftware embedded ist. Dennoch als Info: 2-tier und 3-tier DMBS wie PostgreSQL, MySQL, MongoDB usw. sind für Remotezugriffe deutlich besser gerüstet.

 

[spremmse]

Noch eines hinterhergeschoben - das Thema Replikation von SQL-Datenbanken kannte ich bisher hauptsächlich wenn es um das Thema Redundanz u. Failover geht. Mit Cloud-Nativen Datenbanken wird das momentan mehr und mehr zum Nischenthema, ob Replikationslösungen noch anderswo existieren ist mir nicht bekannt.
In der Softwarearchitektur designen wir bei mobilen Anwendungen üblicherweise das ganze System "Offline-First", und haben dann diese Probleme nicht. Ob Gupta hier eine geeignete Basis darstellt, ist nochmal eine andere Frage.

Mir stellt sich die Frage, ob es nicht mit Kanonen auf Spatzen geschossen ist, Patterns hochskalierter Anwendungsserver für die Offline-Fähigkeit einer kleinen Individualsoftware einzusetzen.

 

[marcus67]

Ich höre von diesem DBMS das erste Mal und habe es aus Interesse gegoogelt und mich zur Kontoerstellung motivieren lassen (lese bereits lang mit).

Das ist ein uraltes Ding mit Wurzeln in den 1980ern. Ist vergleichbar mit der alten Access DB von MS. Der größte Unterschied ist, dass es schon damals als Client/Server System entwickelt wurde.

 

[kexbox]

Ein kurzes Follow-Up zu diesem Thema:

Es ist nun in der Tat ein Server am heimischen DSL + RDP-Zugriff darauf geworden. Die Tipps zur Datenbanksynchronisation habe ich befolgt und habe von den Spezialisten stets Warnungen erhalten, dass das auf Dauer Probleme geben wird, was ich mir in der Alltagsarbeit nicht leisten will.

Wenn es mal mit der Bahn auf Reise geht, hat sich gezeigt, dass zumindest im ICE die Verbindung über das Handy (Telekom) als Hotspot deutlich performanter ist, als das Zug-Wifi (selbst bei niedriger Auslastung).