Laden...

Welche Methode zum synchronisieren von Datenbanken hat sich bewährt?

Erstellt von Davaaron vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.972 Views
D
Davaaron Themenstarter:in
106 Beiträge seit 2016
vor 5 Jahren
Welche Methode zum synchronisieren von Datenbanken hat sich bewährt?

Hi,

ich habe mehrere lokale und eine remote Datenbank (RDB). Die RDB soll als zentrale Datenbank für alle Clients dienen, d.h. auf dieser sind alle Daten vorhanden. Die Clients haben zusätzlich eine lokale Datenbank. Nun gilt es, die zwei Datenbank zu synchronisieren und ich frage mich: Welche der tausenden Möglichkeiten, die es da so gibt, haben sich denn eurer Meinung nach etabliert oder bewährt?
Leider konnte ich keine richtige Frage auf meine Antwort finden...

Es sollen viele Provider möglich sein, also auch jene, die keine Replikation anbieten.
Daher war meine Überlegung, das ganze per Web API zu lösen: Die Clients nutzen die Web API des Servers für die RDB.

Aber wie geht der umgekehrte Weg? Angenommen, es ändert sich etwas am Datenbankschema. Soll ich dann per Broadcast ein .sql Skript verschicken? Das funktioniert aufgrund der Providersache ja nicht (z.B. MySQL != PostGres, das heißt manche Befehle sind verschieden).
Wie führe ich die Migration auf Clientseite durch?

Ebenso dachte ich bereits an Trigger.. denn eigentlich immer dann, wenn Datensätze oder Schemata geändert werden, soll diese Änderung kommuniziert werden.

Könnt ihr mir ein paar Tipps geben? Vielleicht auch gerne mit minimalistischen Beispielen falls ihr wollt, könnt oder einfach Lust und Laune habt?

Es geht hier erstmal vielmehr um das Konzept.

16.806 Beiträge seit 2008
vor 5 Jahren

Welche der tausenden Möglichkeiten, die es da so gibt, haben sich denn eurer Meinung nach etabliert oder bewährt?
Leider konnte ich keine richtige Frage auf meine Antwort finden...

Weil man das nicht tun sollte, wenn es vermeidbar ist.
Das Duplizieren einer Datenbank bzw. das Synchronisieren auf diesem Wege sollte immer das absolut letzte Mittel sein: wieso brauchst Du es?
Was ist die genaue Anforderung? Warum muss jeder Client die ganze DB haben?

Genau sowas versucht man aufgrund von Synchronisationsprobleme und Race Conditions auf jede erdenkliche Art zu vermeiden.
Neben der Komplexität gibt es natürlich Apsekte von Security, Scaling, DevOps und Co....

D
Davaaron Themenstarter:in
106 Beiträge seit 2016
vor 5 Jahren

Ok ich sehe schon. Es reicht aus, wenn die Clients nur die Daten bekommen, die sie auch brauchen. Das heisst, ich muss in meiner Datenbank für alle Einträge einen Bezug zum Client herstellen, Also Tabelle anlegen wo der Server alle Clients speichert mit Name und Id beispielsweise? Oder pro Client eine Datenbank? Hmmm

Durch die lokale Kopie will ich es dem Client ermöglichen, offline zu arbeiten, wenn der Server nicht erreichbar sein sollte. Besteht dann wieder eine Verbindung, wird synchronisiert.

T
2.219 Beiträge seit 2008
vor 5 Jahren

Die Frage ist doch, welche Daten die Client benötigen.
Wenn die Clients ihre eigenen Datenbestände haben, musst du wenigstens nicht alle Daten an alle Clients verteilen.
Gerade wenn Clients z.B. gleiche Daten bekommen und diese wieder gesynct werden müssen, wird es spaßig dies umzusetzen wenn X Clients die gleichen Daten bearbeitet haben.

Bei einem unserer Projekte werden z.B. den Clients fertige Sqlite Datenbanken geliefert.
Diese können dann aber Informationen der Clients enthalten, die dann wieder zurück geliefert werden müssen.
Je nach Datenmenge sprechen wir da von einigenMB bis GB an Daten, die beim Client laden und teils auch wieder an den Server gesendet werden müssen.
Diese werden dann vor dem Versand an den Client per 7zip gepackt um die Datenmenge gering zu halten.

Dazu werden die entsprechenden Einträge beim Client auch noch als bearbeitet vermerkt, damit nicht alles wieder an den Server gesendet werden muss.
Alleine diese Umsetzung hat ewig gedauert und ist auch fehleranfällig.
Dies kann dann von Verbindungsproblemen bei der übertragung wegen schlechten Netzen/WLAN bis hin zu veralteten Datenbanken von Clients die ewig nicht geupdatet wurden.
Hier kommt also nochmal die Versionierung der Daten als weiteres Problem auf dich zu.

Wie Abt schon sagt, wenn nicht wirklich nötig würde ich es auch nicht empfehlen es umzusetzen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

D
Davaaron Themenstarter:in
106 Beiträge seit 2016
vor 5 Jahren

So ähnlich wie du es beschrieben hast, hatte ich das auch schon im Kopf und wäre auch glaube ich so mein Weg gewesen..
Jedes Problem, das nicht gelöst, sondern nur reduziert werden kann, ist fürchterlich, so wie dieses Spektakel. Aber leider fällt mir auch keine andere Möglichkeit ein, wie man den Client offline fähig halten kann.

T
708 Beiträge seit 2008
vor 5 Jahren

Die Problematik kenne ich zur genüge!

Die Frage ist aber: Wird diese Offline-Fähigkeit wirklich benötigt oder ist das nur ein theoretischer Fallback, den der Kunde gerne hätte?

Denn, wie häufig fällt die Internetverbindung tatsächlich aus?
Sind die Geschäftsprozesse wirklich nicht temporär offline durchführbar? (Lagerentnahme mit Entnahmeschein [so wie früher auch]).

Kritisches Thema sind meist Abrechnungssysteme (Kassen). Was kostet ein USB-UMTS-Stick? Oder einen Hotspot mit dem Handy aufzumachen?

Eine Sache gibt es, die mir AdHoc einfällt, wo es wirklich nicht anders geht:
Wartung bei Großkonzernen, die in der Forschung tätig sind. Neben jeglicher Art von Kameras (also Smartphones) ist auch meist keine Netzwerk-/Internetverbindung erlaubt.
Dort sucht der Mitarbeiter den Wartungsauftrag raus, macht ihn offline verfügbar und sperrt diesen im online-System.
Kommt er vom Kunden zurück, kann er problemlos diesen Auftrag aufgrund seiner Sperre wieder zurücksynchronisieren.

16.806 Beiträge seit 2008
vor 5 Jahren

Wartung bei Großkonzernen, die in der Forschung tätig sind. Neben jeglicher Art von Kameras (also Smartphones) ist auch meist keine Netzwerk-/Internetverbindung erlaubt.

Auch das ist - wie zB bei Maschinenbauern und Automobilkonzernen - ein rein politsches Thema.
Die einzigen Systeme in DE, die per Gesetz in ein seperates System müssen, sind Behörden und Energieversorger (und dort auch nur die Prio 1 Systeme).
Ich kenn da auch so ein medizinisches Unternehmen, das ein Netz Offline hat und die gesamte Forschungsdatenbank auf einem USB Stick (unverschlüsselt) von A nach B trägt...

Und viele Unternehmen haben leider die letzten 15 Jahre verpasst und daher immer noch solche Anforderungen, die nicht mehr zeitgemäß sind obwohl es schon lang bessere Systeme und Technologien, die dazu noch eine höhere Sicherheit haben, gibt.

Die in den meisten Fällen optimale Lösung ist immer noch, dass die Datenbank vollkommen isoliert ist und der Client gar keine Abhängigkeit zu irgendeiner Datenbanktechnologie hat und zB via REST nur die Daten bekommt, die er benötigt.

D
Davaaron Themenstarter:in
106 Beiträge seit 2016
vor 5 Jahren

Wird diese Offline-Fähigkeit wirklich benötigt oder ist das nur ein theoretischer Fallback, den der Kunde gerne hätte?

Es ist wirklich notwendig. Bei einem Netzwerkausfall können zu große wirtschaftliche Schäden entstehen, weil das System nicht mehr arbeiten kann.

Denn, wie häufig fällt die Internetverbindung tatsächlich aus?

Nicht oft, wobei es da auch auf die regionalen Bedingungen ankommt. Deutsches Internet ist im Vergleich zum europäischen Internet im Bezug auf Kosten, Schnelligkeit und Ausbau nur mittelmäßig.
Und wie gesagt: Obwohl man davon ausgehen kann, dass ein Ausfall nicht oft vorkommt, sind die Schäden jedoch zu hoch, um auf ein Fallback zu verzichten.

Die in den meisten Fällen optimale Lösung ist immer noch, dass die Datenbank vollkommen isoliert ist und der Client gar keine Abhängigkeit zu irgendeiner Datenbanktechnologie hat und zB via REST nur die Daten bekommt, die er benötigt.

Der Remote-Server soll auch durch eine API erreichbar sein.

16.806 Beiträge seit 2008
vor 5 Jahren

Es ist wirklich notwendig. Bei einem Netzwerkausfall können zu große wirtschaftliche Schäden entstehen, weil das System nicht mehr arbeiten kann.

Wenn ihr an nem Tropf hängt, dann würde ich eine etablierte Lösung kaufen statt sie selbst zu "basteln"....
Selbst kann man in einer Enterprise Größe das ja mit 1-2 Mann kaum leisten.

T
708 Beiträge seit 2008
vor 5 Jahren

Auch das ist - wie zB bei Maschinenbauern und Automobilkonzernen - ein rein politsches Thema.

Das spielt doch überhaupt keine Rolle.
Wenn Dein (potentieller) Kunde sagt, Du darfst das nicht, dann hältst Du Dich daran oder suchst Dir einen anderen Kunden (Bzw. der Kunde einen anderen Dienstleister).

Und ob ein Unternehmen sich noch im Dornröschenschlaf befindet, ändert ebenfalls nichts an der Tatsache, dass er nun mal am längeren Hebel sitzt.
Die allermeisten Spendenorganisationen haben in der Satzung stehen, dass die Daten im eigenen Haus verbleiben müssen. Also keine Cloud, teilweise keine Remote-Zugänge, niemals externe Datensicherungen, usw.
Ob das sinnvoll ist, steht auf einem anderen Blatt. Aber wenn Du nur Cloud aus dem Homeoffice anbietest, bist Du als Dienstleister raus.

Obwohl man davon ausgehen kann, dass ein Ausfall nicht oft vorkommt, sind die Schäden jedoch zu hoch, um auf ein Fallback zu verzichten.

Kommt alles auf den Prozess an!

Wir haben Lösungen, die nur die essenziellen Daten offline vorhalten, bis die Software wieder online ist. Z.B. einen Verkauf. Wenn der Kunde den Artikel in der Hand hält, ist dieser per se lagerhaltungstechnisch auch verfügbar. Ist man wieder online, wird die Entnahme verbucht.
Alles andere geht eben für diese Zeit nicht oder muss auf Papier erfasst und nachgepflegt werden.
Ist ja auch eine Sache des Aufwandes, die der Kunde zu zahlen hat.

Der "große wirtschaftlicher Schaden" kann immer und überall entstehen, wie man schon häufiger mal an Tankstellen gesehen hat. Da verwechselt der Fallback mal eben einen Punkt mit einem Komma und der Sprit kostet nur noch 1,49 Cent 😁

Ist aber auch alles sehr theoretisch, da wir/ich nicht weiß was das System letztendlich können soll.

16.806 Beiträge seit 2008
vor 5 Jahren

Wenn Dein (potentieller) Kunde sagt, Du darfst das nicht, dann hältst Du Dich daran oder suchst Dir einen anderen Kunden (Bzw. der Kunde einen anderen Dienstleister).

D.h. wenn Dein Kunde pauschal eine Anforderung hat, die Du selbst als unsicher einstufst, dann machst Du das? Du bückst Dich also immer, weil der Kunde das will? Da tick ich anders 😉 Ich mache das mit Herzblut gerne, wenn ich es auch vertreten kann. Ich kann kein Projekt ordentlich machen, an das ich nicht glaube oder zweifle.
Auch als Anbieter darf man ruhig seine Kunden beraten. Und am Ende muss man auch entscheiden, ob der Kunde zu einem passt - und nicht nur umgekehrt.

Ja, das ist manchmal nicht einfach - gebe ich zu.

Und ob ein Unternehmen sich noch im Dornröschenschlaf befindet, ändert ebenfalls nichts an der Tatsache, dass er nun mal am längeren Hebel sitzt.

Kommt drauf an.
Bist Du in der Situation auf den Kunde angewiesen: Ja.
Bist Du nicht auf ihn angewiesen: nein.

Hört sich arrogant an; aber nur weil ein Kunde was will heisst das noch lange nicht, dass das sinnvoll ist oder man sich daran die Hände verbrennen will/soll.
Hab auch schon Projekte abgelehnt, weil der Kunde einfach quatsch will.

Ansonsten stimme ich Deinem Beitrag zu.

D
Davaaron Themenstarter:in
106 Beiträge seit 2016
vor 5 Jahren

Ok danke für die Hinweise.

Ich werde mal sehen wie es sich entwickelt.. 😃

T
708 Beiträge seit 2008
vor 5 Jahren

D.h. wenn Dein Kunde pauschal eine Anforderung hat, die Du selbst als unsicher einstufst, dann machst Du das? Du bückst Dich also immer, weil der Kunde das will?

Das ist natürlich arg pauschalisiert.
Weder springe ich von der Brücke, noch erfinde ich das Rad neu 8)

Ist man in der komfortablen Situation Interessenten ablehnen zu können, sollte man das durchaus tun, wenn man selbst keinen Nutzen daraus zieht. In einem Angestelltenverhältnis geht das jedoch nicht immer.

Manches muss man auch einfach als Herausforderung ansehen 😁

Natürlich habe ich schon potentiell unsichere Umsetzungen abgelehnt, aber auch (für teilweise viel Geld) vollkommen sinnlose/überflüssige Dinge umgesetzt.
Dabei agiere ich transparent und weise den Kunden auf meine Bedenken hin. Mehrfach. Möchte er das trotzdem, gibt es selten Gründe das abzulehnen und ihn zum Mitbewerbern zu schicken.

Bin mir aber sicher, dass wir uns da im Großen und Ganzen ohnehin recht einig sind 🙂