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