Объединение данных с нескольких узлов (сервер)
Во многих компаниях существуют региональные офисы или организации, которые собирают и обрабатывают данные, направляемые затем в центральный офис. Например:
Данные о материальных запасах могут быть «накоплены» или объединены с ряда серверов локальных оптовых баз для передачи на центральный сервер главного управления корпорации.
Данные самостоятельных подразделений предприятия могут быть отправлены на центральный сервер.
Сведения об обработке заказов распределенных отделений могут быть объединены.
В некоторых случаях данные могут быть также отправлены с центрального узла на удаленные узлы. Эти данные обычно предназначены только для чтения на удаленном узле, например это относится к набору таблиц перечня продуктов, который обновляется только на центральном узле.
На следующей схеме показан типичный сценарий, в котором информация накапливается с удаленных узлов. Информация, доступная только для чтения, отправляется на каждый удаленный узел.
.gif "Репликация данных в региональные офисы")
Пример компании Adventure Works Cycles
Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks.
У компании Adventure Works Cycles имеется ряд региональных офисов продаж на территории США. Эти офисы используют репликацию в двух случаях:
Чтобы предоставить информацию об исполнении заказов и для создания отчетности. Данные собираются и обрабатываются в каждой точке продаж и реплицируются в главный офис.
Чтобы предоставить информацию и возможные объемы заказов передвижному персоналу продаж. Данный сценарий описывается в разделе Обмен данными с мобильными пользователями.
Общие рекомендации для этого сценария
Для приложений региональных офисов обычно существуют следующие требования, которые должны быть удовлетворены соответствующим решением для репликации:
Система должна поддерживать согласованность транзакций.
Система должна иметь небольшую задержку: обновления с удаленных узлов должны доставляться на центральный узел быстро.
Система должна иметь высокую пропускную способность: требуется обрабатывать репликации большого числа транзакций.
Обработка репликаций должна требовать минимальных издержек на удаленных узлах.
Изменения данных могут происходить в обоих направлениях: в некоторых случаях данные, доступные только для чтения, отправляются на удаленные узлы в дополнение к данным, собранных с удаленных узлов на главном.
Данные, необходимые центральному узлу, могут быть подмножеством данных, доступных на каждом удаленном узле.
Типы репликации, доступные для использования в этом сценарии
MicrosoftSQL Server использует терминологию издательской отрасли для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки.
На диаграмме, расположенной выше, каждый удаленный узел является издателем. Данные удаленного узла включаются в публикацию со всеми таблицами данных, являющихся статьями (статьями могут быть и объекты другой базы данных, например хранимые процедуры). Центральный узел является подписчиком на эти публикации, получающим по подписке схему и данные.
Центральный узел также служит в роли издателя в отношении данных, отправляемых на удаленные узлы. Каждый удаленный узел является подписчиком в отношении публикаций центрального узла.
Дополнительные сведения о компоненте системы см. в разделе Обзор модели публикации репликации.
SQL Server предлагает разные виды репликации для разных требований приложений: репликация моментальных снимков, репликация транзакций и репликация слиянием. Данный сценарий лучше всего реализуется с помощью репликации транзакций, которая хорошо справляется с требованиями, описанными в предыдущем разделе. Дополнительные сведения о репликации транзакций см. в разделах Обзор репликации транзакций и Как работает репликация транзакций.
По своей конструкции репликации транзакций удовлетворяют главным требованиям этого сценария:
согласованность транзакций;
небольшая задержка;
высокая пропускная способность;
минимальные издержки.
.gif "Примечание") Примечание |
|---|
Подобный сценарий может выполняться для репликации слиянием. Если в приложении требуется разрешение конфликта или фильтры, предоставляющие удаленным узлам уникальные наборы данных, следует использовать репликацию слиянием. Дополнительные сведения см. в разделе Объединение данных с нескольких узлов (клиентов). |
Шаги реализации этого сценария
Чтобы реализовать этот сценарий, прежде всего необходимо создать публикацию и подписки, а затем активизировать каждую из подписок. Чтобы получить дополнительные сведения по каждому шагу, щелкните ссылки, перечисленные ниже:
После того, как подписка активизирована и начался обмен данными между издателем и подписчиками, возможно, потребуется получить дополнительные сведения в следующих подразделах, в которых рассматриваются общие задачи администрирования и контроля: