Versionierung eines Datensatzes in einem RDBMS mithilfe von Initialen und Deltas

Question

Ich arbeite an einem System, das entfernte Datensätze mithilfe von Initialen und Deltas spiegelt.Wenn eine Initiale eintrifft, löscht sie massenhaft alles Vorhandene und fügt massenhaft die neuen Daten ein.Wenn ein Delta eingeht, leistet das System eine Menge Arbeit, um es in Aktualisierungen, Einfügungen und Löschungen zu übersetzen.Initialen und Deltas werden in langen Transaktionen verarbeitet, um die Datenintegrität zu gewährleisten.

Leider lässt sich die aktuelle Lösung nicht sehr gut skalieren.Die Transaktionen sind so umfangreich und dauern so lange, dass unser RDBMS aufgrund verschiedener Konfliktprobleme ins Stocken gerät.Außerdem gibt es keinen guten Prüfpfad für die Anwendung der Deltas, wodurch es schwierig wird, Probleme zu beheben, die dazu führen, dass die lokale und die Remote-Version des Datensatzes nicht mehr synchron sind.

Eine Idee besteht darin, die Initialen und Deltas in Transaktionen überhaupt nicht auszuführen und stattdessen jedem Datensatz eine Versionsnummer hinzuzufügen, die angibt, von welchem ​​Delta oder Initial er stammt.Sobald ein Initial- oder Delta-Datensatz erfolgreich geladen wurde, kann die Anwendung benachrichtigt werden, dass eine neue Version des Datensatzes verfügbar ist.

Damit bleibt nur noch die Frage offen, wie genau eine Ansicht eines Datensatzes bis zu einer bestimmten Version aus der Anfangsversion und den Deltas zusammengestellt werden soll.(Apples TimeMachine macht etwas Ähnliches und verwendet Hardlinks im Dateisystem, um eine „Ansicht“ eines bestimmten Zeitpunkts zu erstellen.)

Hat jemand Erfahrung mit der Lösung dieser Art von Problem oder der Implementierung dieser speziellen Lösung?

Danke!

Answer 1

Danke an diejenigen, die es versucht haben.

Für alle anderen, die hier landen: Ich teste eine Lösung, die jeder fraglichen Tabelle eine Spalte „dataset_version_id“ und „dataset_version_verb“ hinzufügt.Eine korrelierte Unterabfrage innerhalb einer gespeicherten Prozedur wird dann verwendet, um beim Abrufen bestimmter Datensätze die aktuelle dataset_version_id abzurufen.Wenn die neueste Version des Datensatzes das dataset_version_verb von „delete“ hat, wird es durch eine WHERE-Klausel aus den Ergebnissen herausgefiltert.

Dieser Ansatz hat bisher eine durchschnittliche Leistungseinbuße von ca. 80 % zur Folge, was für unsere Zwecke akzeptabel sein dürfte.

Answer 2

über eine Writer- und mehrere Reader-Datenbanken verfügen.Sie senden den Schreibvorgang an die eine Datenbank und lassen die exakt gleichen Änderungen an alle anderen Datenbanken weitergeben.Die Leserdatenbanken werden schließlich konsistent sein und die Aktualisierungszeit ist sehr schnell.Ich habe dies in Umgebungen gesehen, in denen mehr als 1 Million Seitenaufrufe pro Tag erzielt wurden.Es ist sehr skalierbar.Sie können sogar einen Hardware-Router vor alle gelesenen Datenbanken stellen, um deren Last auszugleichen.