Синхронизация модели частичной базы данных с сервера на клиент

Это скорее концептуальный вопрос, не обязательно связанный с какими-либо конкретными технологиями. Допустим, у вас есть база данных на сервере, некоторые REST/JSON API для доступа к содержимому в этой базе данных, а некоторые мобильные клиенты отображают данные, полученные через API.

Было бы неплохо иметь некоторый механизм кэширования на клиенте, а также иметь возможность автономного доступа к данным, пока клиент только читает (в моем случае это нормально, чтобы запретить доступ на запись к автономным клиентам, чтобы избежать чтобы справиться со всеми этими неприятными конфликтами, которые могут произойти).

Похоже, что хороший способ решить это будет иметь подмножество модели базы данных серверов, присутствующую на клиенте, и синхронизировать данные с сервера на клиент. Доступ к локальной базе данных может сразу же вернуть результаты, а также инициировать запросы на обновление для сервера. В случае, если сервер возвращает измененные данные, модель клиента затем синхронизирует его с локальной базой данных и уведомляет об изменении данных.

Конечная цель, конечно же, состоит в том, что пользователь может просматривать информацию независимо от стабильности своего интернет-соединения и не раздражается диалоговыми окнами подключения или подобными, если он не модифицирует какие-либо данные.

Теперь с точки зрения реализации... с одной стороны, кажется, что плохая идея - соединить базу данных сервера напрямую с клиентской базой данных, поскольку они могут быть от разных поставщиков. По-моему, по крайней мере, должна существовать независимая от поставщика модель выше обеих реализаций баз данных. С другой стороны, преобразование данных из базы данных сервера в какой-то транспортный формат и возврат его в клиентскую базу данных, похоже, связано с большими накладными расходами.

Любые предложения, как решить эту проблему элегантным и удобным способом?

Ответ 1

Я работаю над приложением, которое синхронизирует небольшие части большой базы данных локально на телефоне. Существует начальная предварительная загрузка, которая должна произойти на телефоне, но после этого обновления происходят асинхронно в фоновом режиме.

Прежде всего, рекомендуется развязать сервер и телефон с помощью JSON или XML. Блокировка одной технологии всегда вызывает проблемы, поскольку вы вынуждены использовать одну и ту же технологию независимо от платформы. То есть, если вы планируете распространяться на другие платформы (Web, iOS и т.д.), Вы вынуждены использовать формат, продиктованный сервером. Выбор общего формата сделает это более простым в долгосрочной перспективе. На самом деле, количество публичных библиотек, читающих/записывающих JSON, является тривиальным вопросом.

Мы можем использовать два способа синхронизации данных;

1. AlarmManager

Мы планируем, чтобы AlarmManager запускал услугу для пробуждения по регулярному расписанию (скажем, каждые 6 часов). Пробуждение запускает фоновый сервис, который связывается с сервером, загружает изменения в JSON и обновляет локальную базу данных SQLite. Если соединение отсутствует, обновление будет пропущено и запланировано для следующего пробуждения. Мы добавляем приемник ConnectivityChanged для автоматического перезапуска синхронизации при восстановлении соединения.

2. GCM

Это немного больше работает, но экономит много батарей и использования данных, если вы только обновляете локальную базу данных, когда есть изменения. Google Cloud Messaging может отправить сообщение пробуждения на устройство и сообщить ему, чтобы запустить службу синхронизации. Служба синхронизации работает так же, как и метод AlarmManager выше.

Мы комбинируем оба вышеописанных метода в зависимости от того, насколько "свежими" вам нужны данные и как часто они меняются. Возможно, что-то вроде RSS-канала должно обновляться каждые 30 минут, тогда как погодные данные могут не обновляться более чем каждые 4 часа.

Итак, для запуска синхронизации базы данных мы используем;

Приемники → прослушивание системных событий и запуск службы Сервисы → подключение к серверу, загрузка JSON и обновление поставщиков SQLite Поставщики → вставляют записи в базу данных и изменяют содержимое контента в ContentObservers ContentObservers → когда приложение запущено, ContentObservers обновляют пользовательский интерфейс с новыми данными

В каждом из вышеперечисленных компонентов много технических деталей, но это должно обеспечить вам очень надежную архитектуру для синхронизации данных сервера с локальным db.

Ответ 2

Я работаю над проектом, который имеет схожие требования. Мы хотим иметь большую доступную базу данных на сервере где-то, а затем мобильные устройства, которые получают данные от нее. Если устройства отключены, это нормально, потому что они сохранили свои собственные копии данных локально.

Мы решили использовать BigCouch (fork Apache CouchDb, поддерживающий кластеризацию) в качестве серверной технологии, а затем Couchbase Mobile на мобильных устройствах. (В качестве примечания TouchDB для Android заменит Couchbase Mobile, но он пока не стабилен.)

Причина, по которой мы пошли с технологией Couch *, заключается в том, что у Couch есть хорошая репликация по HTTP. Вы можете программно инициировать событие синхронизации на мобильном устройстве, и оно будет реплицировать все вставки, обновления и удаления для вас. Он хранит информацию о своем встроенном CouchDb на мобильном устройстве, поэтому его можно читать в автономном режиме.

Если вы не хотите спускаться по дороге Couch, вы можете просто использовать что-то вроде SQLlite для хранения результатов ваших вызовов REST/API. Тогда вам придется написать свою собственную логику репликации, когда мобильное устройство переходит в автономный режим, а затем возвращается. Есть творческие способы сделать это, поэтому, возможно, это вариант.