Синхронизация частичной модели базы данных от сервера к клиенту
Это скорее концептуальный вопрос, не обязательно связанный с какими-либо конкретными технологиями. Допустим, у вас есть какая-то база данных на сервере, немного API REST/JSON для доступа к содержимому в этой базе данных, а также мобильный клиент, отображающий данные, полученные через API.
Было бы неплохо иметь некоторый механизм кэширования на клиенте, а также иметь возможность включать автономный доступ к данным, пока клиент только читает (в моем случае было бы нормально запретить доступ на запись к автономным клиентам, чтобы избежать необходимости управлять все эти неприятные конфликты, которые могут случиться).
Похоже, что хорошим способом решения этой проблемы было бы наличие подмножества модели базы данных серверов на клиенте и синхронизация данных с сервера на клиент. Доступ к локальной базе данных может затем немедленно вернуть результаты, но также может инициировать запросы на обновление к серверу. В случае, если сервер возвращает измененные данные, клиентская модель затем синхронизирует свою локальную базу данных и уведомляет об отображении изменений данных.
Цель в конце, конечно, состоит в том, что пользователь может просматривать информацию независимо от стабильности своего интернет-соединения, и его не раздражают диалоговые окна и т.п., если он не изменяет какие-либо данные.
Теперь с точки зрения реализации... с одной стороны, кажется плохой идеей связать базу данных сервера напрямую с базой данных клиента, поскольку они могут быть от разных поставщиков. Я думаю, что, по крайней мере, должна существовать независимая от поставщика модель выше обеих реализаций базы данных. С другой стороны, преобразование данных из базы данных сервера в некоторый транспортный формат и их последующее возвращение в базу данных клиента кажется чрезмерной нагрузкой.
Любые предложения, как решить это элегантно и ремонтопригодно?
2 ответа
Я работаю над приложением, которое локально синхронизирует небольшие части большой базы данных с телефоном. Начальная предварительная загрузка должна произойти на телефоне, но после этого обновления происходят в фоновом режиме асинхронно.
Прежде всего, настоятельно рекомендуется разделение сервера и телефона с помощью JSON или XML. Блокировка одной технологии всегда вызывает проблемы, поскольку вы вынуждены использовать одну и ту же технологию независимо от платформы. То есть, если вы планируете экспансию на другие платформы (Web,iOS и т. Д.), Вы вынуждены использовать формат, определяемый сервером. Выбор общего формата сделает это проще в долгосрочной перспективе. В действительности с количеством публичных библиотек чтение / запись JSON - тривиальный вопрос.
Есть два способа синхронизации данных;
1. AlarmManager
Мы планируем AlarmManager для запуска службы по регулярному расписанию (скажем, каждые 6 часов). Пробуждение запускает фоновую службу, которая связывается с сервером, загружает изменения в JSON и обновляет локальную базу данных SQLite. Если соединения нет, обновление будет пропущено и запланировано на следующее пробуждение. Мы добавляем приемник ConnectivityChanged для автоматического перезапуска синхронизации при восстановлении соединения.
2. GCM
Это немного больше работы, но экономит заряд батареи и данных, если вы обновляете локальную базу данных только при наличии изменений. Google Cloud Messaging может отправить на устройство сообщение о пробуждении и попросить его запустить службу синхронизации. Служба синхронизации работает так же, как и метод AlarmManager, описанный выше.
Мы используем комбинацию обоих методов, описанных выше, в зависимости от того, насколько "свежи" вам нужны данные и как часто они меняются. Что-то вроде RSS-канала, вероятно, должно обновляться каждые 30 минут, в то время как данные о погоде могут обновляться не чаще, чем каждые 4 часа.
Поэтому для запуска синхронизации базы данных мы используем;
Получатели -> прослушивают системные события и запускают службы Service Services -> подключаются к серверу, загружают JSON и обновляют провайдеров SQLite. Провайдеры -> вставляют записи в базу данных и транслируют изменения содержимого в ContentObservers ContentObservers -> при запуске приложения, ContentObservers обновляет пользовательский интерфейс новыми данными
В каждом из вышеперечисленных компонентов есть много технических деталей, но это должно предоставить вам очень надежную архитектуру для синхронизации данных сервера с локальной базой данных.
Я работаю над проектом, который имеет аналогичные требования. Мы хотим иметь большую доступную базу данных на сервере, а затем мобильные устройства, которые получают данные от него. Если устройства выходят в автономный режим, это нормально, потому что они сохранили свои собственные копии данных локально.
Мы решили использовать BigCouch (форк Apache CouchDb, поддерживающий кластеризацию) в качестве серверной технологии, а затем Couchbase Mobile на мобильных устройствах. (Как примечание, TouchDB для Android заменит Couchbase Mobile, но он еще не стабилен.)
Причина, по которой мы пошли с технологиями Couch*, заключается в том, что у Couch хорошая репликация по HTTP. Вы можете программно инициировать событие синхронизации на мобильном устройстве, и оно будет реплицировать все вставки, обновления и удаления для вас. Он хранит информацию на собственном встроенном CouchDb на мобильном устройстве, поэтому его можно читать в автономном режиме.
Если вы не хотите идти по пути Couch, вы можете просто использовать что-то вроде SQLlite для хранения результатов ваших вызовов REST/API. Тогда вам придется написать собственную логику репликации, когда мобильное устройство отключается, а затем возвращается. Есть творческие способы сделать это, так что, возможно, это вариант.