Рекомендуемая структура для агрегации данных

У нас есть приложение, которое будет собирать данные и хранить их на локальных компьютерах с WinXP, используя Microsoft SQL Server Compact. Мы хотим объединить эти данные в единый полноценный SQL Server для создания отчетов и архивирования. Передача данных должна быть достаточно непрерывной (т. е. не пакетной), хотя допустима некоторая задержка (минута или две максимум).

Данные — это односторонняя передача от коллекторов к серверу. Сборщикам никогда не нужно знать, что делают другие сборщики, и первичный сервер никогда не будет обновлять данные обратно на сборщике. Текущие планы рассчитаны на 5 сборщиков, но масштабируемость практически не ограничена.

Мы должны предположить, что мы будем «в основном подключены», но мы не можем гарантировать подключение коллекторов к серверу. Если сервер или сеть выйдет из строя, мы по-прежнему будем собирать данные, и данные будут возвращены, когда сервер снова станет доступным.

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

Прямо сейчас у нас есть две технологии-кандидата на это:

  1. SQL-репликация
  2. Службы синхронизации Майкрософт

У нас мало опыта работы с первым, но мы знаем, что настройка подписок и т. д. в SQL Server болезненна, а их отладка не доставляет удовольствия, поэтому мы пытаемся найти альтернативу.

Мы почти ничего не знаем о № 2, только то, что он был предложен в качестве альтернативы для передачи данных устройства на сервер.

Есть ли у кого-нибудь опыт работы с таким сценарием или с одной из этих технологий или с чем-то, о чем мы не думали, чем они могут поделиться? SQL Compact на сборщиках является фиксированным требованием. SQL Server на сервере не требуется, но желателен, поскольку он уже есть у заказчика.


person ctacke    schedule 19.11.2008    source источник


Ответы (4)


Я использовал Microsoft Sync Services до того, как они были полностью выпущены. Мне понравилось, и кажется, что это идеально подходит для вашего приложения.

Я рекомендую, если вы хотите облегчить себе жизнь, использовать GUID (уникальный идентификатор SQL Server) в качестве первичных ключей для всех таблиц, которые вы хотите синхронизировать с основным сервером. Это предотвратит коллизии и много дополнительного кода.

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

person Scott Whitlock    schedule 29.11.2008

Попробуйте синхронизацию и расскажите нам, как она идет :) Я видел событие MSFT, и эти ребята говорят: «Я добавил эти 3 строки кода, и все просто синхронизируется... уууууу».

Звучит как путь ко мне.

person Sam    schedule 19.11.2008

Проблема с репликацией заключается в том, что при изменении схемы вам придется выполнять ручную работу на каждом клиенте, чтобы снова запустить репликацию. У меня нет опыта работы со службами синхронизации, но я бы задал тот же вопрос: что происходит при изменении схемы? Если вам нужно прикасаться к каждому клиенту, это может быть проблемой.

person Brent Ozar    schedule 29.11.2008

В итоге я выбрал вариант 3: ни то, ни другое. Вместо этого мы просто периодически (настраивается пользователем, но по умолчанию 5 секунд) используем класс SqlBulkCopy для копирования записей. Это хорошо работает, потому что позволяет нам передать IDataReader, поэтому мы локально открываем таблицу с помощью TableDirect, ищем самый высокий RowID из удаленной таблицы, а затем передаем читатель классу WriteToServer.

person ctacke    schedule 31.12.2008