[Alg] Data syncen: hoe om te gaan met conflicten

[Bozozo]

Ik ben van plan een browserextensie voor Chrome van sync-functionaliteit te voorzien. Specifiek gaat het om een set bookmarks, die ik desgevraagd wil kunnen syncen met de Google account van de gebruiker. Omdat er niet persee voortdurend syncing plaatsvindt (een gebruiker kan offline werken of simpelweg een tijdje niet willen syncen) kunnen er conflicten ontstaan tussen de lokale dataset en de cloud. Een voorbeeld:

Lokale dataset:

• id 1: Foo
• id 2: Bar
• id 3: Tapir

Cloud dataset:

• id 2: Bar
• id 3: Spek
• id 4: Hoi

In de cloud is item 1 verwijderd, de inhoud van item 3 gewijzigd, en item 4 toegevoegd.

Nu is mijn vraag: wat is de meest gebruiksvriendelijke manier om hiermee om te gaan? Ik hou alle opties open: het opslaan van de timestamp per item, een lijst bijhouden van alle wijzigingen, de gebruiker laten kiezen wat te doen bij conflicten, backups maken zodat er een 'roll-back' mogelijk is, etc. Hoe implementeren jullie zoiets?

De reden dat ik deze discussie wil voeren is simpel: ik wil het graag in een keer goed doen. Deze extensie heeft duizenden gebruikers en die worden er niet blij van als ik hun data verknoei

[las3r]

Ik zou sowieso een oplopende nummering aanhouden (zoals MySQL dat bijvoorbeeld doet met z'n auto-increment). Op die manier hoef je je uberhaupt niet druk te maken om de overlappende nummers. maw: Id's zelf toekennen als id = max(id)+1

[Bozozo]

Helaas kun je er niet van uit gaan dat max(id)+1 uniek is als er op meerdere machines tegelijk gewerkt wordt zonder sync

[begintmeta]

Je kan uids gebruiken en dan met timestamps kijken wat de actueelste status is van het item. Imho kan je de gebruiker dan ook nog laten kiezen of laten opgeven dat een partij altijd wint. Bij out of sync modificaties kan het ingewikkeld worden. Je zou locking kunnen overwegen.

Misschien kan je bij de diverse open source rcs en cvs inspiratie opdoen.

[ Voor 31% gewijzigd door begintmeta op 30-08-2013 20:39 ]

[eerdepeer]

Ik heb hier geen kaas van gegeten, maar heb er wel een gedachte over. De sync lijkt me prioriteit te moeten geven aan de laatste bewerking. Om daarbij alleen af te gaan op de tijdsinstelling van de server of device is natuurlijk lastig en niet altijd even betrouwbaar. (Gemakkelijkmte wijzigen). Dus misschien moet je iets maken waarbij je synct op tijd en tevens een berekening uitvoert op het verschil van de tijd van je device tot de server. Geen idee of dit praktisch haalbaar is. Just my 2 cents.

[Gomez12]

Wat ik zou doen is het simpelweg anders behandelen (geen deletes toestaan bijv, bookmarks kunnen alleen hidden gemaakt worden zodat je kan synchen wat er verwijdert is (bij deletes kan dit niet))

Daarnaast zou ik gewoon je objecten bij aanmaak een uid geven zodat ze overal uniek zijn. En je wijzigingen binnen een uid kan bijhouden.

Daarnaast voor je sync-probleem zou ik 2 timestamps (last sync time en update time) bijhouden op de client en 1 timestamp op de server (update time). Alhoewel ik dan wel uitga van een server en niet van een cloud bij een cloud zou ik over een last-sync time bijhouden (inclusief client/servernaam)

Hiermee kan je bijv zeggen dat als iemand iets lokaal gewijzigd heeft na de last-sync time en op de server is de last-updated time lager dan de last-sync time dan kan je de wijziging doorvoeren (het is alleen client-side gewijzigd)
Is de last-updated time op de server en de client hoger dan de sync time dan kan je een popup aan de gebruiker tonen om conflict resolution te doen (nadat je eerst gekeken hebt of het record niet simpelweg gelijk is, voor het zelfde geld is er op 2 computers dezelfde actie gedaan dan is het een beetje stom om een conflict resolution popup te tonen)
Is de last-updated time op de server hoger, maar op de client lager dan de sync time dan kan je de client overschrijven.

En bij een echte cloud-vorm (dus meerdere servers) zou ik gewoon een tabelletje bijhouden met last-synced met wie en bij elke client sync een cloud sync doen zodat je binnen de cloud bijna geen conflict resolution hebt.
En ik zou binnen de cloud je conflict resolution zo instellen dat die gewoon 2 duplicaten genereert met bijv de datum van conflict erbij.
Plus dat ik zelf nog wat instellingen zou hebben in de vorm van : max automatic sync time (zodat je als je een computer na een half jaar offline gebruik opeens weer gaat syncen je niet van alles weggooit).

Wil je toch entry's verwijderen na verloop van tijd dan heb je weer het uitgebreide sync-tabelletje op de server nodig zodat je echt weet dat een entry overal gesynced is zodat je het ook echt weg kan halen)

[Nactive]

Wat je van systeem kan toepassen is een optimistic locking systeem.
Op je server voorzie je al je entrys met een last changed timestamp.
Bij het ophalen van de boodmarks pak je ook die last changed timestamp mee. Indien je een update doet op de server moet de last changed timestamp altijd gelijk zijn aan de opgehaalde waarde, anders wordt de wijziging niet doorgevoerd. Je kan de gebruiker dan de boodschap geven in de vorm van 'Antoher proces already changed the item'.

Conflict resolution zou ik er niet insteken omdat ten eerste dit niet zoveel zal voorkomen en ten tweede dit het veel ingewikkelder maakt. Ook vereist conflict resolution al meer kunsten van de gebruiker (ik denk niet dat mij moeder zou begrijpen wat het probleem is).
Je kan altijd de dropbox techniek toepassen, dit is een copy van het conflicted item bewaren. Dus plotseling heb je twee items. Ik zou in ieder geval niet aanraden om er een heel resolution systeem in te steken want als gebruiker willen we tegenwoordig dat de applicatie alles voor ons doet. Als de applicatie tegen ons komt klagen over conflicten is de doorsnee gebruiker alleen maar geïrriteerd.

Wij gebruiken bij ons op het werk in ieder geval zo een last timestamp techniek om in een multie user omgeving te zorgen dat als twee mensen hetzelfde item aanpassen er geen problemen ontstaan.

[ Voor 26% gewijzigd door Nactive op 31-08-2013 15:52 ]

[Bozozo]

Bedankt voor de reacties! Het onzichtbaar maken van items ipv echt verwijderen lijkt me een goed idee, al zal er wel enige purging nodig zijn. Een systeem met GUIDs oid lijkt me ook noodzakelijk, plus timestamps op alle wijzigingen op zowel elke client als in de cloud. Al met al genoeg werk voor een regenachtige zondagmiddag... ik hou jullie op de hoogte

[Gomez12]

Nactive schreef op zaterdag 31 augustus 2013 @ 15:42:
Wat je van systeem kan toepassen is een optimistic locking systeem.
Op je server voorzie je al je entrys met een last changed timestamp.
Bij het ophalen van de boodmarks pak je ook die last changed timestamp mee. Indien je een update doet op de server moet de last changed timestamp altijd gelijk zijn aan de opgehaalde waarde, anders wordt de wijziging niet doorgevoerd.

Ik zal het wel niet exact snappen hoor, maar als ik dus op pc 1 gister heb gesynched dan is de last changed timestamp op de server dus op gister gezet, zet ik nu vandaag pc 2 aan met wat wijzigingen en ga ik die synchen dan komen de last changed timestamps niet overeen en dus wordt er niets gesynched?

Ik vermoed dat jouw systeem alleen werkt met een 100% online oplossing, want ik zie even niet hoe 1 timestamp leading kan zijn als ik op 3 devices offlline veranderingen heb doorgevoerd.

Nactive schreef op zaterdag 31 augustus 2013 @ 15:42:
Je kan altijd de dropbox techniek toepassen, dit is een copy van het conflicted item bewaren. Dus plotseling heb je twee items.

Dat vind ik zo'n ruk systeem (alhoewel ik dropbox schitterend vind), ik heb momenteel gewoon 1x per dag cronjob lopen die zoekt naar conflicted copy's en die mij meld zodat ik zelf er actie op kan ondernemen.
Ik heb verschillende processen in mijn dropbox draaien en dan gebeurde het vaak genoeg dat ik ergens 5 directories diep allemaal conflicted copy's heb staan zonder dat ik ergens vanaf weet.

Ik zou in ieder geval niet aanraden om er een heel resolution systeem in te steken want als gebruiker willen we tegenwoordig dat de applicatie alles voor ons doet. Als de applicatie tegen ons komt klagen over conflicten is de doorsnee gebruiker alleen maar geïrriteerd.

Je kan je conflict resolution zoveel mogelijk automatiseren, maar sommige dingen kan je gewoon niet oplossen zonder gebruikers invloed, dan kan je blind copieeen gaan maken maar dan alsnog moet iemand handmatig conflict resolution gaan toepassen om van de copieeen af te komen. Dan liever in your face dan dat ik het ergens 5 nivo's diep moet gaan opzoeken.

[Nactive]

Ik zal het wel niet exact snappen hoor, maar als ik dus op pc 1 gister heb gesynched dan is de last changed timestamp op de server dus op gister gezet, zet ik nu vandaag pc 2 aan met wat wijzigingen en ga ik die synchen dan komen de last changed timestamps niet overeen en dus wordt er niets gesynched?

Het systeem is redelijk eenvoudig.
Je geeft elk item dat je wilt syncen (voor dropbox zou dit elk bestand zijn) een dirty flag en de datum dat de laatste wijziging ervan op de server is gebeurd.
Als je gaat syncen kijk je voor al uw items waarvan dirty flag op true staat:

• Is last changed van dit item op server nog gelijk aan wat ik heb (je kan zonder problemen syncen)
• Is last changed verschillend, kan je zien of je automatische het conflict kan oplossen (misschien hebben ze dezelfde wijziging gedaan) en anders zit je met de vraag hoe je het aan de gebruiker zal tonen .

Wat je dan tenslotte van resolutie systeem gebruikt (Dropbox techniek van copytje, een resolution popup, ...) hangt meer van je persoonlijke voorkeur af denk ik. Gomez12 denk hier al anders over als mij .