Рекомендации по алгоритму синхронизации базы данных

Я работаю над приложением, для которого требуется алгоритм синхронизации данных.

У нас будет основной сервер и несколько подчиненных устройств, которые необходимо синхронизировать вместе.

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

1. Описание алгоритма можно найти здесь. Это научно-исследовательская работа Сан-Вук Кима Отдел информации и коммуникаций Университет Ханьянг, Корея

http://goo.gl/yFCHG

2 Этот алгоритм включает в себя сохранение записей временных меток и номеров версий баз данных

Если, например, версия v10, на одном мобильном устройстве и сервере, имеет v12, мобильный, предполагая, что текущая временная метка на мобильном устройстве менее известна по сравнению с меткой времени на сервере,

Если обозначить делецию через -, то вставка a + и изменение на ~

И следующие журналы изменений связаны с несколькими версиями:

v11: + r (44), ~ r (45), -r (46) v12: -r (44), ~ r (45), + r (47)

Тогда общее изменение в базе данных: ~ r (45) (из v12), + r (47), -r (46)

Отсюда видно, что запись r (44) не нужна, даже если она была добавлена, а затем удалена. Следовательно, никакие избыточные данные не должны передаваться.

Весь алгоритм можно найти здесь (я поставил его в pdf) http://goo.gl/yPC7A

3 Этот алгоритм действует - хранит таблицу, которая записывает последнюю временную метку изменения для каждой записи. И сохраняет строки, отсортированные в соответствии с timestamp.It синхронизирует только те строки, которые были изменены, я вижу, что сортировка таблицы выполняется каждый раз в соответствии с отметками времени.

Здесь ссылка http://goo.gl/8enHO

Спасибо за ваше мнение!: D

Ответ 1

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

Все конструкции здесь сохраняют пропускную способность, распространяя изменения. Если что-то заставляет одну сторону перестать быть точной копией другой, эта несогласованность может сохраняться бесконечно. Вы могли бы хотя бы обнаружить такую ​​проблему, обменяв контрольные суммы (SHA-2 или SHA-3, если вы достаточно обеспокоены). Одна из идей - попросить систему получателей для контрольной суммы, а затем выбрать пакет обновлений на основе этой контрольной суммы.