Никто не может поделится ссылками на интернет-источники и бумажные книги по offline-синхронизации информационных сущностей.

Есть определенная распределенная БД, нужно разработать простой механизм кастомизации для "умной" синхронизации данных в общем случае. Что именно читать?

Результаты уже есть, но хотелось бы посмотреть на другие решения, если они открыты.

Mr MarmeladШаманские практики,

не совсем понятно Коллега - Что будем синхронизировать - Данные в Базах или Сущности в Моделях?

Экземпляры сущностей, которые размазаны по таблицам в базе. Протокол клиентско-серверного обмена уже есть (пакеты данных нечто типа иерархической БД типа xml). Нужна литература на стратегии "умной" репликации.

С Уникальностью проблем нет, так как заранее озаботился чтобы все ID были типа GUID.

Mr MarmeladШаманские практикиНужна литература на стратегии "умной" репликации. С Уникальностью проблем нет, так как заранее озаботился чтобы все ID были типа GUID.

Поставлю вопрос ещё по другому: Ваша задача

:
а) Архитектурная (есть несколько баз различных вендоров данные не критичны)
б) Аналитическая (есть модели и их надо привести к знаменателю - данные вторичны)
в) Административная (есть базы данных от вендоров с данными в продакшн - надо синхронизировать всё)


В Зависимости от этой буквы А и будет конкретное решение, Коллега. две другие буквы DB нам известны.

Кстати и откуда генерироваться будет Ваш GUID?

Клиент и сервер - приложения.

Клиент в котором лежит дерево определённый данных неограниченной вложенности (реально вложенность не более 30), нечто вроде внутренней файловой системы. Клиент меняет эти "файлы" по желанию как хочет(создаёт, изменяет, удаляет(удаление логическое - отметка об удалении)). http://www.tidyfavorites.com/

Есть аккаунт на сервере, на котором клиент может синхронизировать своё текущее состояние (бекап или синхронизация нескольких копий клиентов). На каждый клиент на сервере свою база.

Все данные создаются на клиенте - сервер занимается только их сохранением и умной синхронизацией между несколькими клиентами. Там же (на клиенте) каждой записи в базе в качестве идентификатора и присваивается GUID(чтобы не думать об реализации уникальности).

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

Необходимо, если возможно, дать ссылки на литературу по организации сценариев синхронизации данных из базы, если структура таблиц может различаться между разными базами. Синхронизация файлов подойдёт.

Клиент-сервер написаны на Delphi, база и там и там Firebird, но на сервере может быть база другого вендора.

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

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

Mr MarmeladШаманские практики На каждый клиент на сервере свою база.

Моя переводческая система кажется никогда это не переведёт. Пжст поясните


Аккаунтом много, их данные никак не пересекаются, поэтому был выбран вариант, что на каждого из аккаунтов создаётся свою отдельная БД, это позволит создать распределённую систему, где можно задействовать несколько серверов, каждый их которых будет обслуживать, скажем только 10000 определённых аккаунтов в сутки. Это позволит на базе обычного движка FB обрабатывать до нескольких миллионов подключений, так как они будут разнесены в системе (при создании нового аккаунта будет автоматически выбираться менее нагруженный рабочий сервер, на котором и создаваться база).

В общем архитектура здесь такова:

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

Рабочие сервера , каждый из которых обслуживает свои аккаунты.

На каждом из рабочих серверов лежат базы конкретных аккаунтов, которых он обслуживает.

Один аккаунт может работать на нескольких компьютерах одновременно, используя свою локальную базу данных FB (сервер только для синхронизации данных между ними).

Mr Marmelad
: У меня уже есть работающий прототип, но хотелось бы посмотреть другие пути решения и подкорректировать.

А Ваш прототип можно попробовать? Для более полного понимания...

Пока нет, он работает только в лабораторных условиях на нужных данных.

Mr MarmeladШаманские практики,

Ещё такой вопрос Коллега. А какой вендор выбран для поддержки такой архитектуры (платформа?)

ПО написано на Delphi, командой в которой я работаю. FB - вендор понятен. Серверная платформа Windows Server 2000+, для клиентов Win2000, XP и выше.

Для сервера понятно, что лучше было бы ваять на чём-то реально серверном, но серверный код на Delphi написан так, чтобы его без бубнов можно было перевести на FreePascal64bit(это если Delphi 2010 не допилят с его 64-битностью). Так что здесь нет никаких ограничений.

Для общения клиента и сервера создан RMP(remote message processing) протокол, несколько похожий на технологию COM, но более отказоустойчивый и рассчитанный для Internet (сбор и прибивание подвисших серверных объектов). Лисапед, но который полностью подходит под данный тип задач.

Если я правильно понял ваш вопрос, то ответ дан?

SeVa Это тоже стоит посмотреть
Salesforce это уже десять лет назад реализовала.Пробовал промониторить цены,после десятка, сбился со счета
ЗЫ Синхронизация в MS Live Mash будет на базе Sync Framework

Спасибо. У не не нужен технологический монстр. Пнял что нужно доработать в моём липапеде чтобы оно всегда корректно работало с моей задачей.

BelyiscrafmBelyА как решаются конфликты репликации, когда один объект менялся с двух сторон?
Или схема работы пользователей построена так, что их не может быть?
почему же, конечно может такое быть. Такие ситуации разруливаются точно также, как и в локальной сети. Ну при Offline-синхронизации - шансы нарваться на конфликт гораздо больше.
Если при работе в локальной сети для предотвращения одновременного доступа используют блокировки (серверные или самопальные), то при Offline синхронизации, скажем, 1 раз в день - шансы нарваться на одновременное редактирование одной записи двумя пользователями - существенно возрастают.


Здесь всё у меня намного проще. Кто последний тот и прав, тоесть в запись идёт только последняя по серверному времени запись, на остальные клиенты она реплицируется перетирая эти же записи, но более старые.

У меня проще, так как пользователь один, просто у него компьютеров много.