Ansätze für Daten Synchronisation? (keine Threads)

[Kalfany]

Hallo,

ich wollte mal fragen ob es im Web irgendwo etwas gibt was sich mit Synchronisation und den möglichen Konflikten beschäftigt? (Auch was es alles für Konflikte geben kann) Und wie man die Datenstruktur Aufbaut oder Konflikte vermeidet, und auch wie die Abläufe bei der Synchronisation sind/sein sollten.

Mir gehts dabei um die Synchronisation von gleichen Daten zwischen verschiedenen "Geräten"/Clients die sich aber alle über eine gemeinsame Basis syncen (Server-DB). Wobei meine Synchronisation nicht "live" passieren soll, sondern per "manuellem" Abgleich.

Was auch sehr interesannt wäre, wie man den Sync schnell und ohne viel Overhead umsetzen kann. (z.B. erst alle Änderungen ermitteln und dann syncen oder anders?)

Wenn sich im Netz nichts dazu findet (ich hab nicht wirklich was gefunden, auch hier im Forum nicht) dann würde ich mich auch über ein Brainstorming hier im Thread freuen.

[mkinzler]

Suche mal nach Replikation

[Kalfany]

Ich hab jetzt mal ein bisschen rumgesucht, leider geht es bei fast allen Themen dann um technische Umsetzung (also welches DBMS, Komponenten ...) aber über die theoretische Herangehensweise hab ich nicht wirklich was gefunden

[Alter Mann]

Hallo,

wenn es den ein MS-SQL Server ist, so kann der ab 2005 selber synchronisieren.
Steht alles in der 'Online'-Dokumentation, wobei man sich laden kann.
Ansonsten auf gleicher Grundlage, aber ohne MS-SQL, bietet sich Sync-Framework an.
Kann jetzt aber nicht genau sagen ob es im Win7-SDK enthalten ist. Hatte es separat
geladen und installiert.

Viele Grüße

[s.h.a.r.k]

Ich werfe einfach mal SyncML in den Ring :wink:

[mkinzler]

Er möchte keine Lösungen sondern Theorie :zwinker:

[blackfin]

Theoretisch könntest du es so machen, dass jeder Datensatz ein "LastUpdateDate" mit sich führt.
Über diesen kannst du dann leicht ermitteln, welche Datensätze geupdated werden müssen.

[mkinzler]

Es kommt dabei auch darauf an, in welche Richtung und wieviele Pools es gibt (werden Änderungen gemacht, welche in die Datenbasis zurückgeschrieben werden müssen)

[Kalfany]

Zitat:

Zitat von Alter Mann

Hallo,

wenn es den ein MS-SQL Server ist, so kann der ab 2005 selber synchronisieren.
Steht alles in der 'Online'-Dokumentation, wobei man sich laden kann.
Ansonsten auf gleicher Grundlage, aber ohne MS-SQL, bietet sich Sync-Framework an.
Kann jetzt aber nicht genau sagen ob es im Win7-SDK enthalten ist. Hatte es separat
geladen und installiert.

Viele Grüße

Also wenn ich das umsetzte was ich Momentan im Kopf habe dann wird das eine Mischung sein die als DBMS MySQL haben wird (aufm Server) und auf den Clients dann SQLite (oder was halt grad verfügbar ist).

Zitat:

Zitat von s.h.a.r.k

Ich werfe einfach mal SyncML in den Ring :wink:

Sowas ist natürlich auch nett, muss ich nur mal schaun in wie weit sich das eignet um eigene Daten zu syncen, den irgendwie lese ich da nur was von Adresdaten und so

Zitat:

Zitat von mkinzler

Er möchte keine Lösungen sondern Theorie :zwinker:

Wenn mir jetzt jemand ne fertige Platform übergreifend verfügbare Lösung zeigt dann nehm ich die auch gerne (sie SyncML) wobei die Theorie hinter dem ganzen mich trotzdem interessiert

Zitat:

Zitat von blackfin

Theoretisch könntest du es so machen, dass jeder Datensatz ein "LastUpdateDate" mit sich führt.
Über diesen kannst du dann leicht ermitteln, welche Datensätze geupdated werden müssen.

Soweit bin ich auch schon (eig. noch weiter) denn ganz so trivial ist es dann leider doch nicht

[mkinzler]

Wenn du ein DBMS verwendest, würde ich eine spezielle DBMS bezogene Lösung verwenden.
SyncML ist theoretisch aucxh geeignet du müsstest dich dann aber um die Kapselung deiner daten kümmern

[blackfin]

Zitat:

...denn ganz so trivial ist es dann leider doch nicht

Ok, dann sag uns doch mal bitte, was daran nicht trivial ist bzw. wo das Problem dabei liegt?
Du willst doch Tabellen vom Server mit denen von den Clients syncen, richtig?
Passiert diese Synchronisation der Datensätze nur auf einem Weg (neue Datensätze vom Server => Client) oder auch umgekehrt (neue lokale Datensätze aller Clients => Server).
Dann wird das ganze natürlich komplexer.

[Kalfany]

Zitat:

Zitat von mkinzler

Es kommt dabei auch darauf an, in welche Richtung und wieviele Pools es gibt (werden Änderungen gemacht, welche in die Datenbasis zurückgeschrieben werden müssen)

Zitat:

Zitat von blackfin

Zitat:

...denn ganz so trivial ist es dann leider doch nicht

Ok, dann sag uns doch mal bitte, was daran nicht trivial ist bzw. wo das Problem dabei liegt?
Du willst doch Tabellen vom Server mit denen von den Clients syncen, richtig?
Passiert diese Synchronisation der Datensätze nur auf einem Weg (neue Datensätze vom Server => Client) oder auch umgekehrt (neue lokale Datensätze aller Clients => Server).
Dann wird das ganze natürlich komplexer.

Alle Richtungen :mrgreen:
Jeder Client soll Daten erzeugen können die er dann zum "Server" synct, die sollen dann nat. auch an die anderen Clients verteilt werden ... kann aber auch sein das der "Server" selber Daten erzeugt die dann an alle Clients müssen.

Zitat:

Zitat von mkinzler

Wenn du ein DBMS verwendest, würde ich eine spezielle DBMS bezogene Lösung verwenden.
SyncML ist theoretisch aucxh geeignet du müsstest dich dann aber um die Kapselung deiner daten kümmern

Genau das wird schwer, denn (z.B) MySQL gibts auf mobilen Clients (Handy ...) nicht wirklich. Bzw. glaub ich nicht das es ein DBMS gibt das wirklich Plattform übergreifend verfügbar ist (und auch was taugt)

[mkinzler]

Eine Replikation einer Menge an Pools ist natürlich komplexer. Am Besten arbeitet man hier mit verschiedenene Nummerkreisen ( jeder Pool hat eigenen). In welcher Form werden die Daten lokal gespeichert?

[Kalfany]

Zitat:

Zitat von mkinzler

Eine Replikation einer Menge an Pools ist natürlich komplexer. Am Besten arbeitet man hier mit verschiedenene Nummerkreisen ( jeder Pool hat eigenen). In welcher Form werden die Daten lokal gespeichert?

Meine Idee dazu:
die "Haupt-ID" -> Timestamp+Zufallswert (um sicher zu sein) damit könnte jeder Client (und auch der Server) neue Einträge erzeugen ohne das sich die IDs dann beim Sync überschneiden. (auch lässt sich das ganze dank Timestamp noch sortieren/indizieren) Die Trennung zwischen Server und Client IDs halte ich für weniger Sinnvoll ... dann muss man zum einen die Nummernkreise irgendwo pflegen, und irgendwann kommts dann sicher mal das die Kreise zu klein werden.


Was meinst du mit "Form"? das DBMS oder die Datenstruktur ... wie gesagt DBMS das was für diese Platform gerade verfügbar ist, und zur Struktur ... ka. bisher gibt es noch keine wirklichen Pläne ... daher auch erstmal die Theorie :D

[blackfin]

Möglicher Ansatz:

Der Server hat die Macht über die ID eines Datensatzes.
Wenn der Server neue Datensätze schreibt, vergibt er eh neue ID's.
Erzeugen die Clients offline neue Datensätze, wird diese globale ID erstmal freigelassen.
Erfolgt dann ein Sync von diesem Client, werden die Datensätze vom Server mit einer ID versehen und diese IDs in die Datensätze des lokalen Clients zurückgeschrieben.
Somit erhält jeder Datensatz eine eindeutige ID und kann identifiziert und verteilt werden.
Problematisch wird es dann jedoch, wenn ein Datensatz, der bereits besteht, sowohl vom Server als auch von einem Client modifiziert wird.
Bei einem Sync gäbe es dann eine Kollision. Trifft das bei deinem Problem überhaupt zu oder gibt es generell nur immer neue Datensätze bzw. werden bestehende immer nur von einem (Server?) geändert?

[mkinzler]

Zitat:

Erzeugen die Clients offline neue Datensätze, wird diese globale ID erstmal freigelassen.

Oder man verwendet verschiedene Nummernkreise

[Alter Mann]

Hi,

wenn es nur um dir Theorie geht, dann bitte hier wissend machen.
Es ist eine Möglichkeit und sie funktioniert.

[Kalfany]

Zitat:

Zitat von Alter Mann (Beitrag 1025402)

Hi,

wenn es nur um dir Theorie geht, dann bitte hier wissend machen.
Es ist eine Möglichkeit und sie funktioniert.

So wirklich viel gibt das jetzt nicht her ...