Никто не может поделится ссылками на интернет-источники и бумажные книги по 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

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