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