Поделиться через

Повышение масштабируемости

  • Статья

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

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

Использование репликации для масштабирования считывания данных

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

Пример Adventure Works Cycles

Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Примеры и образцы баз данных.

Adventure Works Cycles недавно обновил веб-узел, чтобы включить следующие новые функции:

  • Заказ продуктов клиентами через Интернет.
  • Проверка состояния заказа через Интернет.
  • Улучшенные возможности поиска документации по продуктам.

Возможность заказа продуктов через веб-узел привела к значительному увеличению количества операций на единственном компьютере компании, выделенном Microsoft SQL Server. Администраторы Adventure Works решили использовать этот компьютер в качестве источника данных для репликации. Все операции считывания были масштабированы на три дополнительных компьютера, использующих SQL Server, для кэширования данных с компьютера-источника. Кэширующие компьютеры обрабатывают все операции чтения, включая просмотр и поиск пользователями в каталогах продуктов и проверку ими состояния заказов. Все операции записи направляются в базу данных-источник.

Общие требования для этого сценария

Приложения, использующие репликацию для обеспечения масштабируемости, обычно предъявляют следующие требования, выполнение которых должно обеспечиваться соответствующим решением для репликации:

  • Система должна поддерживать согласованность транзакций.
  • Система должна иметь небольшую задержку: обновления источника должны быстро попадать в кэш.
  • Система должна иметь высокую пропускную способность: требуется обрабатывать репликации большого числа транзакций.
  • Для обработки репликации должен требоваться минимальный объем служебных операций в источнике.
  • Данные, необходимые в кэше, могут быть подмножеством данных, доступных в источнике.

Типы репликации, доступные для использования в этом сценарии

SQL Server использует модель издательского дела для описания компонентов системы репликации. Компонент включает в себя издатель, подписчики, публикации, статьи и подписки. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.

На вышеприведенной схеме источник является издателем. Некоторые или все данные из источника включаются в публикацию, при этом каждая таблица данных является статьей (статьями также могут быть другие объекты базы данных, например хранимые процедуры). Каждый кэш является подписчиком на публикацию, получающим схему и данные в виде подписки.

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

По своей конструкции репликации транзакций удовлетворяют главным требованиям этого сценария:

  • согласованность транзакций;
  • небольшая задержка;
  • высокая пропускная способность;
  • минимальный объем служебных операций.

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

Шаги по реализации этого сценария

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

После того как подписка инициализирована и начался обмен данными между издателем и подписчиками, возможно, потребуется ознакомиться с дополнительными сведениями в следующих разделах, в которых рассматриваются общие задачи администрирования и контроля:

См. также

Другие ресурсы

Репликация данных в серверной среде

Справка и поддержка

Получение помощи по SQL Server 2005