Synchronizacja modelu częściowej bazy danych z serwera na klienta

Question

Jest to bardziej pytanie koncepcyjne, niekoniecznie związane z konkretnymi technologiami. Powiedzmy, że masz trochę bazy danych na serwerze, niektóre REST/JSON API, aby uzyskać dostęp do zawartości w tej bazie danych i niektórych klientów mobilnych wyświetlających dane pobrane przez API.

Byłoby miło mieć mechanizm buforowania na kliencie, a także mieć możliwość włączania dostępu do danych w trybie offline, o ile tylko klient czyta (w moim przypadku można odmówić prawa zapisu dla klientów offline uniknąć konieczności radzenia sobie z tymi wszystkimi okropnymi konfliktami, które mogą się wydarzyć).

Wydaje się, że dobrym sposobem na rozwiązanie byłoby posiadanie podzbioru modelu bazy danych serwerów na kliencie i synchronizacji danych z serwera do klienta. Dostęp do lokalnej bazy danych może wtedy natychmiastowo zwrócić wyniki, ale także wyzwalać żądania aktualizacji na serwerze. W przypadku gdy serwer zwróci zmodyfikowane dane, model klienta synchronizuje lokalną bazę danych i powiadamia o wyświetleniu zmian danych.

Celem na koniec jest oczywiście to, że użytkownik może przeglądać informacje niezależnie od stabilności swojego połączenia internetowego i nie jest denerwowany przez okna dialogowe połączeń lub podobne, o ile nie zmienia żadnych danych.

Teraz z perspektywy wdrożenia ... z jednej strony wydaje się złym pomysłem powiązanie bazy danych serwera bezpośrednio z bazą danych klienta, ponieważ mogą pochodzić od różnych dostawców. Sądzę, że przynajmniej nad modelem obu baz danych musiałby istnieć model niezależny od dostawcy. Z drugiej strony, przekształcenie danych z bazy danych serwera w pewien format transportu i umieszczenie go z powrotem w bazie danych klienta wydaje się dużo narzutem.

Jakieś sugestie, jak rozwiązać ten problem w elegancki i trwały sposób?

Answer 1

Pracuję nad aplikacją, która synchronizuje małe fragmenty dużej bazy danych lokalnie na słuchawce. Jest początkowe napięcie wstępne, które ma nastąpić w słuchawce, ale po tym aktualizacje zdarzyć asynchronicznie w tle.

Przede wszystkim oddzielenie serwera i słuchawki za pomocą JSON lub XML jest wysoce zalecane. Blokowanie na jednej technologii zawsze powoduje problemy jak jesteś zmuszony do korzystania z tej samej technologii, niezależnie od platformy. Oznacza to, że jeśli planujemy ekspansję na innych platformach (Internet, iOS, etc ..), które są zmuszone do korzystania z formatu dyktowany przez serwer.Wybór ogólnego formatu uprości to na dłuższą metę. W rzeczywistości z ilością odczytów/zapisu bibliotek publicznych JSON jest kwestią banalną.

Są dwa sposoby synchronizacji danych;

1. AlarmManager

My planować AlarmManager do uruchomienia usługi do wzbudzenia w określonych odstępach czasu (powiedzmy co 6 godzin). Budzenie uruchamia usługę w tle, która nawiązuje kontakt z serwerem, pobiera zmiany w JSON i aktualizuje lokalną bazę danych SQLite. Jeśli nie ma połączenia, aktualizacja jest pomijana i planowana na następne przebudzenie. Dodajemy odbiornik ConnectivityChanged, aby automatycznie ponownie uruchomić synchronizację po przywróceniu połączenia.

2. GCM

To trochę więcej pracy, ale oszczędza dużo baterii i wykorzystania danych, jeśli tylko zaktualizować lokalną bazę danych, gdy nastąpią zmiany. Google Cloud Messaging może wysyłać wiadomość o wznowieniu do urządzenia i nakazać uruchomienie usługi synchronizacji. Usługa synchronizacji działa tak samo jak powyższa metoda AlarmManager.

Wykonujemy połączenie obu powyższych metod w zależności od tego, jak "świeże" potrzebne są dane i jak często się zmieniają. Coś jak kanał RSS powinien być aktualizowany co 30 minut, podczas gdy dane pogodowe mogą nie wymagać aktualizacji więcej niż co 4 godziny.

Aby uruchomić synchronizację bazy danych używamy;

Odbiorniki -> nasłuchiwać zdarzeń systemowych i wyzwalają usługi Services -> połączyć się z serwerem, należy pobrać JSON i zaktualizować SQLite dostawcom Providers -> włóż rekordy do bazy danych i nadawanych treści zmian ContentObservers ContentObservers - > Gdy aplikacja jest uruchomiona, ContentObservers aktualizuje interfejs z nowymi danymi w każdym z powyższych komponentów, ale powinien dostarczyć ci bardzo solidną architekturę do synchronizowania danych serwera z lokalnym urządzeniem. db.

Answer 2

Pracuję nad projektem, który ma podobne wymagania. Chcemy mieć dużą, dostępną bazę danych gdzieś na serwerze, a następnie urządzenia mobilne, które pobierają z niej dane. Jeśli urządzenia zostaną przełączone w tryb offline, wszystko jest w porządku, ponieważ lokalne kopie danych zostały zapisane.

Zdecydowaliśmy się użyć BigCouch (fork z Apache CouchDb, który obsługuje klastrowanie) jako technologii serwerowej, a następnie Couchbase Mobile na urządzeniach mobilnych. (Uwaga: TouchDB dla Androida zastąpi Couchbase Mobile, ale nie jest jeszcze stabilny.)

Powodem, dla którego poszliśmy z technologiami Couch * jest to, że kanapa ma dobrą replikację przez HTTP. Możesz programowo zainicjować zdarzenie synchronizacji na urządzeniu mobilnym, a on zreplikuje wszystkie wstawki, aktualizacje i usunięcia. Przechowuje informacje na swoim wbudowanym CouchDb na urządzeniu mobilnym, dzięki czemu można go czytać w trybie offline.

Jeśli nie chcesz, aby zejść z drogi Couch, można po prostu użyć czegoś podobnego SQLlite do przechowywania wyników połączeń REST/API. Wówczas trzeba będzie napisać własną logikę replikacji, gdy urządzenie przenośne przejdzie w tryb offline, a następnie wróci. Są na to twórcze sposoby, więc może to opcja.