Jakie jest najbardziej sprytne i łatwe podejście do synchronizacji danych między wieloma podmiotami?

Question

Jakie jest najbardziej sprytne i łatwe podejście do synchronizacji danych między wieloma podmiotami?

W dzisiejszym świecie, gdzie wiele komputerów, urządzeń mobilnych lub usług internetowych udostępnia dane lub działa jak Huby, synchronizacja staje się ważniejsza. Jak wszyscy wiemy rozwiązania, które synchronizują nie są najbardziej komfortowe i najlepiej w ogóle nie synchronizować.

Nadal jestem ciekaw, jak zaimplementowałbyś rozwiązanie synchronizacji do synchronizacji między wieloma podmiotami. Istnieje już wiele różnych podejść, takich jak porównywanie zmienionych pól daty lub hash i korzystanie z najnowszych danych lub pozwalanie użytkownikowi wybrał to, co chce wykorzystać w przypadku konfliktu. Innym podejściem jest próba automatycznego scalania skonfliktowanych danych (co moim zdaniem nie jest tak sprytne, ponieważ maszyna nie może odgadnąć, co użytkownik miał na myśli).

W każdym razie, oto kilka pytań związanych z synchronizacją, na które powinniśmy odpowiedzieć przed rozpoczęciem implementacji synchronizacji:

jakie są najnowsze dane? Jak chcę to reprezentować?
co zrobić, gdy dojdzie do niespójnego stanu (np. rozłączenia z powodu niestabilnego połączenia z siecią komórkową)?
Co muszę zrobić, gdy nie chcę wejść w stan niespójności?
jak wznowić bieżącą synchronizację, która została przerwana?
Jak poradzić sobie z przechowywaniem danych (np. baza danych MySQL w serwisie WWW, podstawowe dane na iPhonie; i jak scalić/zsynchronizować dane bez dużo kleju kodu)?
Jak mam obsługiwać edycje od użytkownika, który dzieje się podczas synchronizacji(która działa w tle, więc interfejs nie jest zablokowany)?
jak i w jakim kierunku propagować zmiany (np. użytkownik tworzy wpis "Foo" na swoim komputerze i nie synchronizuje się; potem jest w ruchu i tworzy kolejny wpis "Foo"; co się dzieje, gdy próbuje zsynchronizować oba urządzenia)? Czy użytkownik będzie miał dwa wpisy " Foo " z różnymi unikalnymi identyfikatorami? Czy użytkownik będzie miał tylko jeden wpis, ale który?
Jak obsługiwać synchronizację, gdy mam dane hierarchiczne? Odgórnie? Oddolnie? Czy traktuję każdy wpis atomicznie, czy tylko patrzę na supernode? Jak duży jest kompromis między upraszczaniem a inwestowaniem zbyt dużo czasu w wdrożenie?
…

Jest wiele innych pytań i mam nadzieję, że będę mogła was wystarczająco zainspirować. Synchronizacja jest dość ogólnym problemem. Po znalezieniu dobrego, wszechstronnego podejścia do synchronizacji powinno być łatwiejsze zastosowanie go do konkretnej aplikacji, zamiast zacząć myśleć od zera. I zdaj sobie sprawę, że istnieje już wiele aplikacji, które próbują rozwiązać (lub z powodzeniem rozwiązać) synchronizację, ale są już dość specyficzne i nie dają wystarczających odpowiedzi na metody synchronizacji w ogóle.

41

database algorithm mobile synchronization

Author: Brian Tompsett - 汤莱恩, 2010-01-19

Source

4 answers

Prawdopodobnie "nie prawdziwe pytanie", tutaj nie ma prawdziwej odpowiedzi:

Myślę, że rozproszone systemy kontroli wersji (takie jak Mercurial czy git) zorientowały się w dużej części tego. Wymagają jednak, aby ludzie zaakceptowali, że może istnieć więcej niż jedna "najnowsza" wersja, a czasami sprzeczne aktualizacje wymagają ręcznego rozwiązania. Ponadto, jeśli nie jesteś zainteresowany utrzymaniem całej historii zmian, istnieje sporo kosztów ogólnych w tych systemach (ale oczywiście najnowsza historia jest konieczna, aby znaleźć wspólnych przodków, aby określić, jak te dwie wersje się odnoszą).

Ale Zgadzam się z Tobą, że w świecie, w którym każdy ma dane rozłożone na wiele urządzeń i usług, potrzeba automatycznego śledzenia i rozpowszechniania aktualizacji stanie się tak pilna, że popularne formaty plików używane przez aplikacje będą zawierały wystarczającą ilość metadanych, aby ułatwić pewnego rodzaju inteligentne łączenie. Ale takie zachowanie prawdopodobnie będzie musiało nastąpić na poziomu aplikacji, ponieważ nie ma ogólnego sposobu rozwiązywania sprzecznych aktualizacji.

W międzyczasie podejście iTunes-iPod jest najłatwiejsze: masz tylko jedną bibliotekę główną i każde urządzenie stamtąd wyciąga. Oczywiście single-master-sync nie jest zbyt satysfakcjonujący we wszystkich scenariuszach (zwłaszcza, gdy zaangażowany jest więcej niż jeden użytkownik), ale mimo to byłbym wdzięczny, gdyby więcej aplikacji oferowało taką opcję (pet peeve: mam trzy Mac-y, z trzema instalacjami iPhoto. Jeśli zsynchronizują się automatycznie z jednego dedykowanego mistrza, podobnie jak zdjęcia synchronizują się z moim iPodem, byłoby to ulepszeniem).

4

Author: Thilo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-19 09:41:57

Dzięki za szczegółową odpowiedź GaZ. Mam kilka dodatkowych pytań:

Jeśli używasz znaczników czasu jak radzisz sobie z niedokładnymi ustawieniami czasu (małe różnice, np. 1-5 sekund)? Jak często w ogóle się pojawiają? Czy wersjonowanie (podobnie jak SVN) nie jest lepsze do obsługi różnych zmian danych?

Rozumiem, że pobierasz dane tylko pomiędzy dwoma znacznikami czasu, last_synchronisation_date (na klienta) i teraz?

Co zrobić, gdy użytkownik nie rozwiązać konflikty? Czy nie synchronizujesz danych oznaczonych flagą isConflict lub dodajesz kolejny konflikt, aby użytkownik mógł wybrać między więcej niż dwiema wersjami encji, gdy zdecyduje się rozwiązać wszystkie konflikty? A może w ogóle nie synchronizujesz, jeśli są jakieś dane oznaczone jako konfliktowe?

0

Author: Rafael Bugajewski,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-20 14:49:09

Chociaż jest to naprawdę przydatne w ekosystemie microsoft, można studiować bloki aplikacji mobilnych .

-1

Author: fravelgue,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-19 19:14:38

score 45 · Accepted Answer

Gdzie pracuję opracowaliśmy wersję "offline" naszej głównej aplikacji (internetowej), aby użytkownicy mogli pracować na swoich laptopach w miejscach, w których nie mają dostępu do Internetu (nie jestem pewien, ile z tych miejsc faktycznie istnieje w dzisiejszych czasach, ale powiedziano mi, że tak;)). Gdy użytkownik wróci na stronę główną, musi zsynchronizować dane wprowadzone offline z naszą główną aplikacją.

Więc, aby odpowiedzieć na twoje pytania:

co jest najbardziej ostatnie dane? Jak chcę to reprezentować?

Mamy kolumnę LAST_UPDATED_DATE na każdej tabeli. Serwer śledzi, kiedy mają miejsce synchronizacje, więc gdy aplikacja offline zażąda synchronizacji, serwer mówi "Hej, daj mi tylko dane zmienione od tej daty".

Co mam zrobić w przypadku konfliktu? Połączyć? Czy podpowiadam i pytam użytkownik co robić?

W naszym przypadku aplikacja offline jest w stanie zaktualizuj stosunkowo mały podzbiór wszystkich danych. Ponieważ każdy rekord jest zsynchronizowany, sprawdzamy, czy jest to jeden z tych przypadków, a jeśli tak, to porównujemy last_updated_date dla rekordu zarówno online, jak i offline. Jeśli daty są różne, sprawdzamy również wartości (ponieważ nie jest to konflikt, jeśli obie są zaktualizowane do tej samej wartości). Jeśli jest konflikt, rejestrujemy różnicę, ustawiamy flagę, aby powiedzieć, że jest co najmniej jeden konflikt i sprawdzamy resztę szczegółów. Once the proces zostanie zakończony wtedy, gdy ustawiona zostanie flaga "isConflict", użytkownik będzie mógł przejść do specjalnej strony, która wyświetla różnice i zdecydować, które dane są "poprawną" wersją. Ta wersja jest następnie zapisywana na serwerze, a flaga "isConflict" jest resetowana.

co mam zrobić, gdy nie chcę wchodzić w niekonsekwentne stan?

jak wznowić bieżącą synchronizację, która została przerwana?

Cóż, staramy się unikać wchodzenia w niespójne stan na pierwszym miejscu. Jeśli synchronizacja zostanie przerwana z jakiegokolwiek powodu, to last_synchronisation_date nie zostanie zaktualizowana, a więc przy następnym uruchomieniu synchronizacji rozpocznie się od tej samej daty, Co Data rozpoczęcia poprzedniej (połączonej) synchronizacji.

Jak poradzić sobie z przechowywaniem danych (np. baza danych MySQL w serwisie WWW, Core Dane na iPhonie; i jak to zrobić scalanie/synchronizacja danych bez dużej ilości kod kleju)?

Używamy standardowe bazy danych obu aplikacji oraz obiekty Java pomiędzy nimi. Obiekty są serializowane do XML (i gziped, aby przyspieszyć transfer) dla rzeczywistego procesu synchronizacji, a następnie dekompresowane/deserializowane na każdym końcu.

Jak powinienem obsługiwać edycje użytkownika, które mają miejsce podczas synchronizacji (który działa w tle, więc Interfejs użytkownika nie jest zablokowany)?

Te edycje nastąpiłyby po dacie rozpoczęcia synchronizacji, a więc nie byłoby / align = "left" /

jak i w jakim kierunku propagować zmiany (np. użytkownik tworzy wpis " Foo " na komputerze i nie synchronizuje się; potem jest w ruchu i tworzy kolejny wpis "Foo"; co dzieje się, gdy próbuje zsynchronizować oba urządzenia)? Czy użytkownik będzie miał dwa " Foo" wpisy z różnymi unikalnymi identyfikatorami? Czy użytkownik ma tylko jeden wpis, ale który?

To od Ciebie zależy jak chcę się tym zająć... tzn. w zależności od tego, jaki jest klucz podstawowy Foo i jak można określić, czy jeden Foo jest taki sam jak drugi.

Jak obsługiwać synchronizację, gdy mam dane hierarchiczne? Odgórnie? Oddolnie? Czy traktuję każdy wpis atomicznie czy tylko patrzę na supernode?

Synchronizacja jest atomowa, więc jeśli jeden rekord zawiedzie, cały proces zostanie oznaczony jako niekompletny, podobnie jak commit subversion transakcja.

Jak duży jest kompromis między upraszczaniem a inwestowaniem za dużo czasu na wdrożenie?

Nie jestem pewien, co dokładnie masz na myśli, ale powiedziałbym, że wszystko zależy od twojej sytuacji i rodzaju / ilości danych, które chcesz zsynchronizować. Zaprojektowanie i wdrożenie procesu może zająć dużo czasu, ale jest to możliwe.

Mam nadzieję, że to ci pomoże lub przynajmniej da kilka pomysłów! :)