Синхронизировать большие объемы данных между мобильным приложением и веб-сервером

Question

Настройка

У меня есть собственное приложение для iOS и Android, которое синхронизирует данные с моим веб-сервером. Требование приложений заключается в том, что они работают в автономном режиме, поэтому данные хранятся в приложениях в базах данных sqlite.

Приложения связываются с сервером с помощью серии вызовов REST, которые отправляют JSON с сервера для приложений для хранения в своих базах данных.

Моя проблема

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

Конечные точки REST должны ограничивать свои данные и должны вызываться много раз с разными смещениями для достижения всей синхронизации.

Так что я ищу способы повысить эффективность этого процесса.

Моя идея

У меня была идея создать скрипт, который запускался бы на сервере, который создавал бы файл sqlite из базы данных серверов, сжимал его и помещал куда-нибудь для загрузки приложений. Эффективно создавая моментальные снимки серверов текущих данных.

Приложения загружают этот снимок, но все равно должны вызывать свои методы REST в случае, если что-то изменилось с момента создания снимка.

Вопрос

Это добавит еще один уровень сложности моему веб-приложению, и мне интересно, правильный ли это подход. Существуют ли другие методы, которые люди используют при синхронизации больших объемов данных?

Answer 1

100Мб не такой большой. На данный момент мои приложения синхронизируют много ГБ. Если ваши данные могут быть статически сгенерированы и обновлены, то одну вещь, которую вы можете сделать, это записать все на сервер (json, images и т. Д.), А затем синхронизировать все в вашей локальной файловой системе. В моем случае я использую S3. В выбранное время или когда пользователь хочет, они синхронизируются, и это только извлекает / обновляет то, что изменилось. На самом деле в AWS есть вызов API для синхронизации с локальной / удаленной папкой или корзиной. Один звонок. Я делаю свой кастом, но по сути это то же самое, проверяю дату последнего обновления и размер файла локально, и если он отличается, вы добавляете его в очередь загрузки.

Answer 2

Это сложный вопрос, поскольку ответ должен зависеть от ваших ограничений:

1. Как часто будут меняться данные? Если это происходит слишком часто, снимок действительно быстро устареет, поэтому приложения будут эффективно обновлять данные. Кроме того, при большом объеме данных приложение будет тратить процессорное время на синхронизацию (даже если пользователь не использует все эти данные!) Или может быстро не синхронизироваться с сервером - это особенно верно для iOS, где Приложения имеют очень ограниченные фоновые возможности (только небольшое окно, которое регулируется) по сравнению с приложениями для Android.

2. Это БД только для чтения? Вы отправляете обновления на сервер? Если это так, то вам необходимо подготовить методы разрешения конфликтов и охватить случаи, когда данные изменяются, но не сразу публикуются на сервере.

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

Ваша идея хороша в том случае, если не выполняется слишком много обновлений для базы данных, а обычные способы загрузки неэффективны (это то, что вы обычно описывали: отправка миллионов записей с помощью нескольких вызовов REST - довольно трудная задача).

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