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

Первое, что вам нужно решить, - это общая политика относительно того, какая сторона считается «авторитетной» в случае противоречивых изменений.

То есть: предположим, что запись № 125 была изменена на сервере 5 января в 22:00, а такая же запись была изменена на одном из телефонов (назовем ее клиентом A) 5 января в 23:00. Последняя синхронизация была 3 января. Затем пользователь снова подключается, скажем, 8 января.

Определить, что нужно изменить, «легко» в том смысле, что и клиент, и сервер знают дату последней синхронизации, поэтому все создано или обновлено (подробнее об этом см. Ниже) поскольку необходимо согласовать последнюю синхронизацию.

Итак, предположим, что единственная измененная запись - № 125. Вы либо решаете, что одна из двух автоматически «выигрывает» и перезаписывает другую, либо вам необходимо поддерживать фазу согласования, когда пользователь может решить, какая версия (серверная или клиентская) является правильной, перезаписывая другую.

Это решение чрезвычайно важно, и вы должны взвесить «роль» клиентов. Особенно, если существует потенциальный конфликт не только между клиентом и сервером, но и в случае, если разные клиенты могут изменять одну и ту же запись (записи).

[Предполагая, что № 125 может быть изменен вторым клиентом (клиентом B), есть вероятность, что клиент B, который еще не синхронизировался, предоставит еще одну версию той же записи, что делает предыдущее разрешение конфликта спорным ]

Относительно пункта « создано или обновлено » выше ...как вы можете правильно идентифицировать запись, если она была создана на одном из клиентов (при условии, что это имеет смысл в вашей проблемной области)? Предположим, ваше приложение управляет списком деловых контактов. Если клиент A говорит, что вам нужно добавить недавно созданного Джона Смита, а на сервере есть Джон Смит, созданный вчера клиентом D ... вы создаете две записи, потому что не можете быть уверены, что они не разные люди? Вы попросите пользователя уладить и этот конфликт?

Есть ли у клиентов «владение» подмножеством данных? Т.е. если Клиент B настроен как «авторитет» для данных для Области №5, может ли Клиент A изменять / создавать записи для Области №5 или нет? (Это упростит разрешение некоторых конфликтов, но может оказаться невозможным в вашей ситуации).

Подводя итог, можно выделить следующие основные проблемы:

• Как определить «идентичность», учитывая, что отключенные клиенты могли не получить доступ к серверу до создания новой записи.
• Предыдущая ситуация, независимо от того, насколько сложным является решение, может привести к дублированию данных, поэтому вы должны предвидеть, как периодически решать эти проблемы и как информировать клиентов о том, что то, что они считали «записью № 675», действительно было объединено с / заменено записью № 543
• Решите, будут ли разрешены конфликты с помощью fiat (например, «Версия сервера всегда превосходит версию клиента, если первая была обновлена ​​с момента последней синхронизации») или ручным вмешательством
• В случае fiat , особенно если вы решите, что клиент имеет приоритет, вы также должны позаботиться о том, как поступать с другими, еще не синхронизированными клиентами, которые могут иметь еще некоторые изменения.
• В предыдущих пунктах не учитывалась детализация ваших данных (чтобы упростить описание). Достаточно сказать, что вместо рассуждений на уровне «записи», как в моем примере, вы можете найти более подходящим записывать изменения на уровне поля. Или работать с набором записей (например, запись человека + запись адреса + запись контактов), одновременно рассматривая их совокупность как своего рода «мета-запись».

Библиография:

• Подробнее об этом, конечно же, в Википедии .

• Простой алгоритм синхронизации автора статьи Vdirsyncer

• OBJC о синхронизации данных

• SyncML®: синхронизация и управление мобильными данными (Книга по O'Reilly Safari)

• Бесконфликтные типы реплицируемых данных

• Оптимистическая репликация ЯСУШИ САЙТО (HP Laboratories) и МАРК ШАПИРО (Microsoft Research Ltd.) - ACM Computing Surveys, Vol. V, No. N, 3 2005.

• Александр Трауд, Юрген Наглер-Ихляйн, Франк Каргл и Майкл Вебер. 2008. Циклическая синхронизация данных посредством повторного использования SyncML. В материалах Девятой Международной конференции по управлению мобильными данными (MDM '08). IEEE Computer Society, Вашингтон, округ Колумбия, США, 165–172. DOI = 10.1109 / MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10

• Лам Ф., Лам Н. и Вонг Р. 2002. Эффективная синхронизация для мобильного XML данные. В материалах одиннадцатой международной конференции по управлению информацией и знаниями (Маклин, Вирджиния, США, 4–9 ноября 2002 г.). ЦИКМ '02. ACM, Нью-Йорк, Нью-Йорк, 153–160. DOI = http://doi.acm.org/10.1145/584792.584820

• Cunha, P. R. и Maibaum, T. S. 1981. Resource & equil; абстрактный тип данных + синхронизация - Методология программирования, ориентированного на сообщения -. В материалах 5-й международной конференции по разработке программного обеспечения (Сан-Диего, Калифорния, США, 9–12 марта 1981 г.).Международная конференция по программной инженерии. IEEE Press, Пискатауэй, Нью-Джерси, 263-272.

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

С сайта Доктор Доббс :

• Создание приложений с SQL Server CE и SQL RDA, Билл Вагнер, 19 мая 2004 г. (Лучшие практики разработки приложений для настольных и мобильных ПК - Windows / .NET)

Источник: arxiv.org:

• Неконфликтный реплицированный тип данных JSON - в документе описывается реализация JSON CRDT (бесконфликтные реплицированные типы данных - CRDT - это семейство структур данных, которые поддерживают одновременную модификацию и гарантируют сходимость таких одновременных обновлений).