Репликация против Sync Framework против Service Broker - PullRequest
2 голосов
/ 28 января 2010

Я спрашивал о каждой из этих технологий отдельно и действительно не нашел подходящего ответа.

В нашем центральном офисе есть сервер, на котором работает SQL Server 2005 Enterprise, который имеет несколько больших (в том смысле, что DSL является ограничивающим фактором) баз данных, для которых нам необходимы локальные копии в каждом из наших местоположений. В настоящее время у нас есть несколько десятков местоположений, и нам нужно привлечь еще больше онлайн. Общее количество местоположений, с которыми нам нужно будет синхронизировать эти базы данных, будет составлять несколько сотен в следующие 2 года.

Мы пытаемся преодолеть проблемы с WAN-соединением в каждом месте. Это линии DSL, и проводка в местах не всегда самая лучшая. В настоящее время у нас есть проблемы с некоторыми местами, которые отключаются так часто, как каждый час. В то время как мы работаем над решением этих проблем с помощью переподключения и помощи местных телекоммуникационных компаний, в основном это подчеркивает существующую проблему: нам нужна двусторонняя синхронизация, которая может справиться с периодическим подключением.

Мы некоторое время пробовали репликацию транзакций, и хотя она работала некоторое время, это было слишком дорого для нас, и казалось, что она часто выдает случайные ошибки без каких-либо объяснений, что вынуждает нас повторно инициализировать подписки (что может свыше 4 часов, при условии, что местоположение будет оставаться подключенным достаточно долго, чтобы получить весь снимок за один раз). Мы смотрели на разработку собственного решения с нуля, но я не думаю, что это была бы лучшая идея, учитывая масштаб и надежность, в которых мы нуждаемся.

До сих пор мы также рассматривали Sync Framework и, как это было предложено кем-то еще, Service Broker. Sync Framework кажется более подходящим, но мне сказали, что Service Broker масштабируется лучше и надежнее? Я не могу найти никаких эмпирических данных о накладных расходах, связанных с Sync Framework или Service Broker, поэтому невозможно сравнить их в этом отношении.

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

Существует так много возможных решений этой проблемы, все с использованием совершенно разных технологий, поэтому мне нужно взглянуть на это по-новому.

Как вы думаете, что было бы оптимальным решением для нашей ситуации и почему?

РЕДАКТИРОВАТЬ: Очевидно, что обновление до SQL Server 2008 решит эту проблему легко. Тем не менее, мы хотели бы сначала попробовать менее дорогие варианты.

Ответы [ 3 ]

1 голос
/ 23 апреля 2012

Вы можете использовать синхронизацию с SQL Express 2008 R1 / R2 на одном конце и многопользовательским сервером базы данных SQl db на центральном конце. Ниже приведен пример приложения для n-уровневой синхронизации по защищенному каналу WCF. Вы можете написать службу Windows для синхронизации данных из серверной части:

http://www.rajneeshnoonia.com/blog/2012/03/n-tier-sync-framework/

Он может быть достаточно способен обрабатывать большое количество клиентов (тысяч).

1 голос
/ 28 января 2010

У меня нет никаких твердых данных, чтобы предложить это, но мы использовали структуру синхронизации в проекте некоторое время назад. Мой опыт с этим действительно плох. Он медленный (даже при синхронизации сравнительно небольших таблиц в локальной сети), ужасно масштабируется и требует большой работы для ручной обработки условий ошибки (он с удовольствием создаст пакеты большего размера, чем WCF может обработать по умолчанию - и способен только разбивать обновления в пакеты при синхронизации одним способом, а не другим.) И он работает только с несколькими избранными базами данных (насколько я помню, клиент должен использовать MS SQL Compact Edition), если вы не хотите писать свой собственный SyncAdapter.

В целом, много работы, чтобы получить хрупкое и неэффективное решение вашей проблемы. Я бы не рекомендовал это.

0 голосов
/ 28 января 2010

Думаю, мы рассмотрим маршрут обновления SQL Server 2008. Кажется, для этого проще всего использовать встроенную поддержку отслеживания изменений.

...