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