Имеется задача буферизации данных, в целом SyncFramework здесь мог б быть полезен. Но как я посмотрел, он уже не поддерживается, и на 4.5 его не переносят. Вместо него предлагают DataSync для Windows Azure, а desktop-версии у него вроде как нет. Вот хочу знать, какие есть альтернативы в настоящее время именно для desktop-сервера на .Net 4.5.
Здравствуйте, Ilya81, Вы писали:
I>Имеется задача буферизации данных, в целом SyncFramework здесь мог б быть полезен. Но как я посмотрел, он уже не поддерживается, и на 4.5 его не переносят. Вместо него предлагают DataSync для Windows Azure, а desktop-версии у него вроде как нет. Вот хочу знать, какие есть альтернативы в настоящее время именно для desktop-сервера на .Net 4.5.
Sync Framework — это набор unmanaged-библиотек и .Net-ных оберток поверх них (самые распоследние собраны под .Net 2.0). Все это хозяйство даже ставится отдельно, путем запуска MSI-ников. Зачем Sync Framework "переносить на 4.5"?
Здравствуйте, scale_tone, Вы писали:
_>Здравствуйте, Ilya81, Вы писали:
I>>Имеется задача буферизации данных, в целом SyncFramework здесь мог б быть полезен. Но как я посмотрел, он уже не поддерживается, и на 4.5 его не переносят. Вместо него предлагают DataSync для Windows Azure, а desktop-версии у него вроде как нет. Вот хочу знать, какие есть альтернативы в настоящее время именно для desktop-сервера на .Net 4.5.
_>Sync Framework — это набор unmanaged-библиотек и .Net-ных оберток поверх них (самые распоследние собраны под .Net 2.0). Все это хозяйство даже ставится отдельно, путем запуска MSI-ников. Зачем Sync Framework "переносить на 4.5"?
Я про другое — может есть какие их аналоги из open source? Проблема ещё в том, что найти даже сложно, всё в результатах поиска какие-то программы сихнронизации данных, а не framework'и/toolkit'ы.
Здравствуйте, Ilya81, Вы писали:
I>Я про другое — может есть какие их аналоги из open source? Проблема ещё в том, что найти даже сложно, всё в результатах поиска какие-то программы сихнронизации данных, а не framework'и/toolkit'ы.
Найти аналог Sync Framework действительно трудно. Так как непонятно, что искать.
Sync Framework — это, по сути, набор примитивов, конструктор такой. Он никакой конкретной задачи сам по себе не решает (после установки дистрибутива ничего ни с чем магическим образом не начнет синхронизироваться).
Он только предоставляет кирпичики для реализации решений синхронизации данных, объединенных двумя общими базовыми идеями:
1) версия сущности может и должна состоять из двух чисел — собственно, версии (счетчика) и идентификатора реплики.
2) версии всех сущностей в реплике можно зазиповать, представить в сильно сжатом виде. Этот вид называется knowledge, и этого сжатого представления версий достаточно для обнаружения изменений и конфликтов между двумя репликами. Т.е. чтобы сравнить две копии БД, достаточно сравнить их knowledge-и.
По сути, основная алгоритмическая ценность всей либы лежит в парочке классов, реализующих математические операции над knowledge-ами (сложить, вычесть etc.). Которые, при желании, можно и самому написать.
У общей схемы синхронизации с knowledge-ами есть важные преимущества:
а) Необязательно иметь мастер-копию данных (некое главное хранилище, через которое все друг с другом синхронизируются).
б) Трафик, потребный для сравнения двух версий БД между собой, очень мал: достаточно передать knowledge.
Само собой, у нее есть и недостатки:
x) Версии сущностей нужно либо хранить и атомарно обновлять вместе с самой сущностью (а это лишнее место на диске, лишнее процессорное время при обновлениях и требование по поддержке транзакций к хранилищу), либо каждый раз вычислять в процессе синхронизации (а это может быть супер-долго).
y) Knowledge тоже нужно либо вычислять каждый раз (что тоже может быть небыстро), либо хранить (и опять же, транзакционно обновлять).
z) и др.
Далее из этих кирпичиков строятся компоненты для синхронизации конкретных видов данных, лежащих в конкретных хранилищах. E.g.
SqlSyncProvider для БД под MS SQL Server или
FileSyncProvider для файлов. При этом с помощью этих компонентов нельзя просто так взять и засинхронизировать, скажем, Oracle с SQL Server-ом (и тем более, SQL Server c папкой на диске) — не заработает.
Я это все к чему: задачу синхронизации данных нельзя рассматривать как абстрактную. И соответственно, не имеет смысла искать в сети некую либу, заменяющую Sync Framework в деле синхронизации всего и вся.
Конкретное решение всегда придется выбирать исходя из множества исходных условий задачи. Вот лишь некоторые из них:
1. Есть ли мастер-копия данных?
2. Каков средний размер сущности (наименьший неделимый кусок синхронизируемых данных)?
3. Как много может быть сущностей?
4. Как часто и на каких репликах меняются данные?
5. Насколько велика вычислительная мощность девайса, где хранится реплика (диапазон от 0 до бесконечности)?
6. Нужна ли атомарная синхронизация (т.е. допускается ли частично успешное применение изменений)?
7. И т.д.
И, соответственно, замену Sync Framework-у нужно искать под конкретную задачу. У Вас она (задача) какая?
Здравствуйте, Ilya81, Вы писали:
I>Пока пробую на WCF .Net TCP, но это не окончательный выбор.
Т.е. между репликами даже есть стабильный коннект? И даже по любому порту?!
Ну-у, в таких-то шоколадных условиях стоит ли заморачиваться с кастомными решениями по синхронизации? Чем не подходит
штатная репликация SQL Server-a, к примеру?
Или вообще заюзать какую-нибудь
документо-ориентированную БД с репликацией из коробки?..
