Синхронизация баз данных? Ваши мысли?

Всем, доброго вечера. В общем была поставлена задача реализовать синхронизацию 2-ух баз данных SQL. Причем первая бд наша, а вторая сторонняя, и ее курят другие разработчики. У них есть шина обмена данными. Сказали нам, что будем работать через нее. Ну, окей, работаем. Написали мы WCF сервис, выложили, они вроде как там что-то у себя подкрутят и будут нам данные идти по ней, хорошо.

Но мы со своей стороны в их шину, должны запихивать, теперь уже наши данные. Столкнулись мы с этим в первый раз, по-этому и появились вопросы на сколько это все правильно у нас? Вопросы:

1) Решено было на нужные нам данные в таблицах повесить триггеры, которые после DML(I,U,D) операций, делают вставку в таблицу для Import'a, откуда соответственно, в дальнейшем мы будем узнавать, что и где обновилось. Насколько хорош этот способ? Другого варианта у нас нету.

2) С данными вроде бы разобрались и теперь получить их можем, дальше надо осуществить их отправку в шину. Решено было сделать службу windows, которая с определенным интервалом опрашивает таблицу Import'a, ну и проверяет если там данные или нет. Исходя из этого уже производим отправку. НО нам этот вариант не нравится, то есть он рабочий, но что-то не впечатляет. Стали разбираться, а можно ли сделать, так чтобы БД сама уведомила нас о том, что в таблицу Import'a была добавлена запись, тогда бы мы сразу осуществили передачу данных, снизилась бы нагрузка, не каких этих таймеров и т. д. Нашли мы такую штуку SqlDependency, уж больно она стала нам люба. Если у кого-то опыт работы с этой штукой? К каким последствиям ее использование может привести производительность, безопасность? Она использует какой-то там SQL Server Service Broker, он может как то навредить? Если какие-то другие механизмы уведомления приложения базой данных?

3) Хотелось бы так же услышать, ваши комментарии по поводу, того как бы вы подошли к решению данной задачи, с такими же условиями?
  • Вопрос задан
  • 332 просмотра
Пригласить эксперта
Ответы на вопрос 3
@d-stream
Готовые решения - не подаю, но...
В принципе вариант с "очередями" достаточно удобен:
в исходящую очередь выкладываются изменения по триггерам, потом, позже из этой очереди записи выгребаются неким обработчиком, возможно с "украшательством" в виде добавления в выгрузку референсных данных и т.п.
Там же можно хранить число попыток отправки и lasterror
Из плюсов - в грязную очередь могут влететь несколько записей на выгрузку одной и той же сущности (к примеру манагер вбил комментарий к клиенту, сохранил, подумал, поправил коммент и снова сохранил = 2 записи), а к отправке уже можно группировать по id сущностей (если конечно по логике не требуется историчность).

Входящая очередь - тут собственно получить-сложить-обработать (принять), где тоже во-первых может быть ошибка. Ну и как вариант - некий doorbell с "той стороны" по появлению данных - т.е. можно не по таймерам проверять наличие, а отрабатывать по сигналу.
Ответ написан
Задача обалдеть не простая.
Вставляют две записи одновременно в БД_1 и БД_2, id у них точно разные :)
Синхронизировались, потом одну и туже запись начинают менять в БД_1 и БД_2 одновременно, кто победит на при следующей синхронизации?
С учетом задержек передачи данных между БД по сети + надежность этого канала, время непрерывной работы не 100%.
Ответ написан
AndyKorg
@AndyKorg
Кнопконажиматель и припоерасплавлятель
Структура БД одинаковая? Тогда штатный механизм репликации спасет отца русской демократии. Если нет то свой механизм нужно писать, а тут уже сложнее.
Своей механизм синхронизации должен решать две задачи -
первая: синхронизация master-таблицы в отношении master-detail и разрешение конфликтов;
вторая: то же самое для detail таблиц.
Если "уровней" детализации больше, то и уровней больше.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы