Konzeptionelle Frage - Datenabgleich

[MyRealName]

Ohne jetzt den ganzen Strang zu lesen, meine Lösung für ein Mobiles Bestellwesen für Aussendienstler und ein autonomes POS ist folgendes :

Tabellen wie Produkte und Kunden kriegen ein Feld LU (LastUpdate, Datetime) und auf der Abgleichseite (also der mobilen app oder dem pos speicher ich mir für jede Tabelle (sind ja eh nicht viele) einfach nur wann ich dasletzte Mal nachgefragt habe.
Beim Sync sage ich dann nur

Tabelle: Produkte
LastUpdate: 13.02.2018 14:15:23.758 (also mit millisekunden eben)

und zurück kommen allen Zeilen aus der Tabelle, die einen LU timestamp haben, der neuer ist.

Das Ganze mache ich mit RealThinClient (RealThinClient.com), da kann ich ganze DataSets komprimiert übermitteln.
Auf der Clientseite geht das dann mit einem Batchmove (Append/Update) in meine lokale Tabelle.

Das nutze ich so seit 2 Jahren und alles ohne Probleme.

Hoffe, dass es hilft.

[TigerLilly]

@MyRealName:
Das ist aber eine Einbahn, oder? Die Updates gehen immer raus zum Pos + nie zurück?

@HobbyCoder:
Das führt bei mehreren Usern + etwas mehr Traffic zu Deadlocks. Never leave the commit to the user. Da öffnet einer den Satz zum Bearbeiten + geht Mittagessen, dann steht bald alles.

Ob es genügt, sich nur den Zeitstempel und die letzte Änderung zu merken oder ob man auch alle Zwischenversionen braucht, ist eine Frage der Anforderungen. Wenn ich zB in meiner App ein Änderungsprotokoll mitführen möchte, dann ist es wichtig, dass ich von den anderen Standorten nicht nur die letzte Änderung bekomme, sondern chronologisch alle Änderungen davor auch. Oder Kennzahlen etc.

[Hobbycoder]

Zitat von TigerLilly:

@HobbyCoder:
Das führt bei mehreren Usern + etwas mehr Traffic zu Deadlocks. Never leave the commit to the user. Da öffnet einer den Satz zum Bearbeiten + geht Mittagessen, dann steht bald alles.

Dagegen kann ja Clientseitig (IDLE-Time) was unternehmen. Das gleiche Problem hast du ja auch bei einfachen DB‘s an nur einem Standort.
Wenn ein User den Datensatz bearbeitet, er nicht gelockt wird und er dann zu Mittag geht, kann in der Zeit ja ein anderer diesen Datensatz ebenfalls bearbeiten. Kommt der erste Mitarbeiter vom Mittag zurück und speichert, überschreibt er die Daten vom zweiten Mtarbeiter.

Dann lieber eine Benachrichtigung in der Art: „Datensatz bei xyz in Bearbeitung“. Habe ich so in Nähe zu allen Programmen von mir, und Userbeschwerden gab‘s noch nie.

[TigerLilly]

Optimistic locking vs pessimistic locking. Der TE wollte ja konzeptionellen Input.

Wenn´s für dich funktioniert ist es eh super. Ich sag nur: Je höher die Concurrency und/oder je höher die Benutzerzahl und/oder je höher die Komplexität der DB-Struktur ist, desto weniger funktioniert das Locken im Voraus.

Zitat:

Wenn ein User den Datensatz bearbeitet, er nicht gelockt wird und er dann zu Mittag geht, kann in der Zeit ja ein anderer diesen Datensatz ebenfalls bearbeiten. Kommt der erste Mitarbeiter vom Mittag zurück und speichert, überschreibt er die Daten vom zweiten Mtarbeiter.

Nein, nein. Die Änderung erkennst du ja + kannst entsprechend reagieren, zB mergen.

[IBExpert]

Moin,

mit der Erfahrung einer von uns implementierten Async Multimaster Replikation mit ca. 160 Server in Deutschland
in diversen Städten verteilt, auf denen innerhalb von 24 Stunden ca 1,5 bis 2 Millionen neue oder geänderte
Datensätze entstehen, geb ich einfach auch mal meinen Senf dazu (auch wenn das alles mit Firebird und
nicht mit mysql implementiert wurde).

-Wir benutzen 64 Bit Integer als PK und für jeden FK und in jeder Tabelle heisst das PK Feld immer ID
(vereinfacht nachher sehr viel)

-Integer ist schon eng, bei 24/7 Betrieb mit einer Transaktion pro Sekunde und wie wir alle wissen 86400
and den meisten Tagen hält ein 32 bit Integer zwar ca 130 Jahre bis zum Überlauf, aber bei 10 pro Sekunde
sind das nur noch 13 Jahre. 100 pro Sekunde dann nicht mal 1,5 Jahre. Beim 64 Bit kannst du 4 Mrd Werte pro
Sekunde verbraten und das hält immer noch 130 Jahre. Geiz ist nicht wirklich geil ....

-Alle Tabellen werden aus einer Quelle (also nur ein Firebird Generator) gefüllt

-An jedem Standort wird bei Auslieferung eine Boxnummer festgelegt und die mit 10 Mrd multipliziert ist der
Startwert für den Generator. Das reicht für ca 1,5 Mrd Standorte ....

-Bitte niemals auch nur drüber nachdenken, das für irgendwas Eindeutiges Timestamps geeignet sind (Sommerzeit und
Winterzeit Umstellung ist die einfachste Problematik dabei, die kann man über utc lösen, aber auflösung in ms ist
schon unter last sehr eng), unter Last sind 1000 Datensätze pro Sekunde nicht viel und der normale Timer insbesondere
unetr windows hat eine wesentlich miesere Auflösung als 1ms.

-Replikationskonflikte kann man asynchron nur dokumentieren, ähnlich wie Notes das macht. Auflösen kann man die
mit Regeln (wer zuletzt speichert hat gewonnen oder ähnlich)

-Inserts sind einfach zu replizieren, updates eher nicht: Einfaches Beispiel Artikellagerbestand, 2 Standorte
verringern den um 1 und weil internet down ist weiss keiner vom anderen. Besser Insert in Bestandsveränderungstabellen
lassen sich zeitnah zu einem Gesamtbestand konsolidieren, Startwert 10 vom zeitpunkt x, zugang +1 and zeitpunkt y
standort a, zugang +5 and zeitpunkt z standort b usw, wenn alle Standorte repliziert sind kann man dann 10+1+6=16
zusammenrechnen auf dem führenden System und den Wert in die Tabelle schreiben und die Bestandveränderungen löschen .
Dafür sollte die Datenbank 100% sauber Transaktionsfähig sein, sonst hast du eh nur datenmüll

-Bei 2 Standorten ist die Problematik noch relativ simpel, wenn man erkennen will, das einer Offline ist, bei 160
Standorten ist es fast immer so, das irgendwo ein Router hängt, dsl tot ist, ein Bagger kabel aus dem Boden gerissen
hat usw. Wichtig ist für unseren Kunden dabei, das an jedem Standort auch offline gearbeitet werden kann und sobald
das wieder online geht, möglichst schnell repliziert wird.

-Wir implementieren das mit Triggern, die immer dann wenn der replikationsuser was macht, inaktiv sind (das gilt für
alle Trigger). Massenoperationen (delete from tab oder ähnliches) können direkt in eine Replikationslog
Tabelle eingetragen werden, dann macht das der Replikationsuser an jedem Standort per skript ohne das es
über die Leitung gehen muss

-Wir bevorzugen lieber mehrere kleinere Tabellen als Monster mit hundetren Feldern

-über die in Firebird existierende Technik execute statement on external können wir auch Blob Inhalte replizieren,
die Technik eignet sich auch für synchrone transaktionechte Replikation

-Lösungen wie ibreplicator versprechen mehr als sie halten, ob die in mysql eingebaute replikation was taugt
weiss ich nicht, aber die war mal bekannt dafür das die nur funktioniert wenn die db komplett in den
Arbeitsspeicher passt .... Bei uns hat die zentrale DB 290 GB und wächst täglich weiter, wäre also
technisch anspruchsvoll, das im RAM zu haben ...

-Für den Delphi Programmierer,der die Backoffice Anwendung dafür schreibt, ist das alles transparent, er muss
sich nicht drum kümmern, was wann von wo nach wo geht. Das überwachen wir für den Endkunden automatisiert
und wir verteilen auch Metadatenupdates über ibexpert Techniken, weil wir per reverse ssh tunnel auf
jeden Standort direkt mit ibexpert kommen. Firebird läuft an fast allen Standorten unter linux, mit
MSSQL basierender Replikation hätte der Kunde schon ohne Hardware 2-3 mio an Microsoft überweisen dürfen,
die von uns gelieferte hardware/software kombination kostet keine 1000 € pro Standort.

-Die Beschriebung geht wahrscheinlich weit über das hinaus, was du im Moment umsetzen willst, aber
sicherlich helfen da einige Aspekte, vermeidbare Fehler eben auch nicht zu machen. Ansonsten viel
Spaß bei der Umsetzung ....

Gruß

Holger

[p80286]

Zitat von jobo:

Zitat von p80286:

..
Da bin ich ganz anderer Meinung.
..

Nein, bist Du nicht. Natürlich muss eine praktikable Lösung für den Kunden rauskommen.
Ich wollte nur zum Ausdruck bringen, das es 2 verschiedene Probleme sind, die nicht unbedingt durch den gleichen, superschlauen Algorithmus zu lösen sind.

OK in Zukunft halt ich mich raus Wenn Du geantwortet hast, wird eh ne Doublette draus!

Aber im Ernst, ich hab gerade Holgers Beitrag gelesen. Das "führende System" ist ein guter Ansatz. istzwar willkürlich aber erleichtert einiges.

Gruß
K-H

[Hobbycoder]

Zitat von TigerLilly:

Der TE wollte ja konzeptionellen Input.

Und? Was ich geschrieben habe ist (wenn auch sehr detailiert) imho ein Konzeptvorschlag?

Und mit ein bisschen Fantasie ließe sich das in optimistic Locking verändern. Kann ja jeder so machen wie er will. Ich wollte ihm lediglich eine Möglichkeit unterbreiten.

[QuickAndDirty]

Zitat von IBExpert:

Moin,

-Alle Tabellen werden aus einer Quelle (also nur ein Firebird Generator) gefüllt

Ich finde das soweit sehr gut! Aber warum nur einen Generator? Welchen Vorteil bietet das? Was spricht dagegen für jedes AUTOINC-Feld einen eigenen Generator zu benutzen?

[himitsu]

Die Idee hinter "nur einen Generator" ist ganz einfach.
Du kannst nur über die ID jeden Datensatz in der Datenbank identifizieren.

Aber Tabelle+ID als Identifikator ist auch nicht ungewöhnlich.

[jobo]

Gegeben seien folgende Daten mit PK und FK. Wie sieht die Beziehung aus? Wer oder was hält Dich von einem Join ab, der gar nicht die richtigen Felder nutzt? Würde ein falscher Join wenigstens an einem lückenhaften Ergebnis sichtbar?

1 1 hobbycoder
2 2 himitsu
3 3 jobo

1 1 Köln
2 2 Bonn
3 3 Rom

1 1 ADV
2 2 BDV
3 3 CDV

statt dessen diese Daten, so könnte man es besser finden:

1 11 hobbycoder
2 12 himitzu
3 13 jobo

4 1 Köln
5 2 Bonn
6 3 Rom

7 1 ADV
8 2 BDV
9 3 EDV

Tatsächlich sähen sie wohl eher so aus:

1 11 hobbycoder
4 12 himitzu
7 13 jobo

2 1 Köln
5 4 Bonn
8 7 Rom

3 1 ADV
6 4 BDV
9 7 EDV

Letztlich auch egal wie sie aussehen. Technische Schlüssel haben keine Bedeutung, außer ihrer Eindeutigkeit.

Wenn man über Synchronisation usw. redet, eignen sich Sequenzen durch ihrere Konfigurierbarkeit außerdem, um in abgeschotteten oder nur teilweise Online Systemen autarke, aber ins Gesamtsystem passende ID zu generieren.

Am Ende ist man vielleicht bei UUID.