Экспорт (0) Печать
Развернуть все

Руководство по производительности базы данных SQL Azure

Обновлено: Сентябрь 2014 г.

Авторы: Конор Каннингэм (Conor Cunningham), Кун Ченг (Kun Cheng), Ян Энгельсберг (Jan Engelsberg)

Технические редакторы: Морган Ослейк (Morgan Oslake), Джоан Марон (Joanne Marone), Кейт Эльмор (Keith Elmore), Хосе Батиста-Нето (José Batista-Neto), Рохит Найак (Rohit Nayak)

База данных SQL Microsoft Azure имеет три уровня обслуживания — Basic, Standard и Premium. Строго контролируя объем ресурсов База данных SQL Azure и вторичных реплик, уровень обслуживания Premium обеспечивает более предсказуемую производительность облачных приложений. База данных SQL Azure реализует эту концепцию для уровня Standard, чтобы обеспечить прогнозируемую высокую производительность для баз данных с меньшими требованиями к производительности по сравнению с уровнем обслуживания Premium. Уровень обслуживания Basic предназначен для выполнения требований к производительности недорогих баз данных.

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

Общие сведения о базе данных SQL Azure

Что изменилось в уровнях обслуживания?

Причины для использования уровней обслуживания

Основные сведения об использовании ресурсов

Настройки приложения

Заключение

Чтобы разобраться, каким образом уровни обслуживания Basic, Standard и Premium улучшают работу службы База данных SQL Azure, необходимо иметь хорошее общее представление о База данных SQL Azure. Можно выбрать База данных SQL Azure по нескольким причинам. Одна из причин — избежать затяжной процедуры приобретения аппаратного обеспечения и установки оборудования. База данных SQL Azure позволяет создавать и удалять базы данных в обычном режиме, при этом не нужно ждать подтверждения заказа, прибытия оборудования, обновления мощности или установки. Майкрософт самостоятельно решает все эти проблемы и значительно снижает время реализации идей путем заблаговременного провизионирования оборудования в соответствии с общим спросом в каждом из наших центров обработки данных. Это позволяет клиентам экономить недели или даже месяцы по сравнению с самостоятельным приобретением и развертыванием оборудования.

Кроме того, было добавлено несколько автоматических функций управления База данных SQL Azure, например автоматический режим высокой доступности, балансировку нагрузки и встроенное управление.

  • Автоматический режим высокой доступности (HA)

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

  • Балансировка нагрузки

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

  • Встроенное управление

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

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

Корпорация Майкрософт в тесном сотрудничестве с рядом клиентов во время первой адаптации новых сотрудников для работы с База данных SQL Azure разработала специальный подход, позволяющий учитывать особенности разных компаний. Во время этой работы было установлено, что целому ряду клиентов набор новых функций очень понравился. Например, стартапы, разрабатывающие новые облачные службы, часто признавали, что мощность по запросу и меньшие усилия по администрированию упрощали их жизнь и позволяли больше времени уделять более важным задачам бизнеса. Ряд других клиентов испытывали трудности в некоторых сферах, связанных с жесткими требованиями к производительности, так как решения многоуровневых баз данных не подходили для работы с текущей службой База данных SQL Azure. Отзывы показывали, что некоторые клиенты были не против изменяемой производительности, позволяющей снизить издержки, в то время как другие клиенты были более заинтересованы в определенной гарантии производительности, чтобы у них всегда была возможность использовать большую мощность.

Чтобы удовлетворить все потребности клиентов, корпорация Майкрософт представила три уровня обслуживания: Basic, Standard и Premium. У каждого уровня обслуживания есть один или несколько уровней производительности, обеспечивающие предсказуемую работу баз данных. Их мощность описывается в единицах пропускной способности базы данных (DTU). В следующей таблице показаны уровни обслуживания, уровни производительности и DTU.

 

Уровень обслуживания

Уровень производительности

DTU

Базовое

Базовое

5

Standard

S0

10

Standard

S1

20

Standard

S2

50

Расширенный

P1

100

Расширенный

P2

200

Расширенный

P3

800

Уровень обслуживания Basic предназначен для обеспечения стабильной почасовой предсказуемости производительности для каждой базы данных. DTU базы данных Basic предназначен для предоставления достаточных ресурсов небольшим базам данных без множества параллельных запросов.

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

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

Как и уровень Standard, уровень обслуживания Premium позволяет выбирать разные уровни производительности в зависимости от требуемой изоляции клиента.

С помощью настроек производительности уровней Standard и Premium клиенты могут платить только за ту мощность, которая используется, в соответствии с изменением рабочей нагрузки. Например если рабочая нагрузка базы данных повышается в начале учебного года, то можно повысить уровень производительности на этот период, а затем снизить его после снижения пиковой нагрузки. В результате клиенты минимизируют издержки и оптимизируют облачную среду в соответствии с сезонными потребностями бизнеса. Кроме того, такая модель подходит для поддержки жизненного цикла программных продуктов. Команда тестирования может увеличивать мощность на время тестирования и снижать ее после завершения тестирования. В результате этого оплачиваться будет только используемая мощность, а не ресурсы, которые используются редко. Такой порядок работы напоминает традиционную модель выделенного оборудования, к которой привыкли многие клиенты Майкрософт, использующие SQL Server. Теперь более широкий спектр приложений сможет работать с База данных SQL Azure.

Хотя рабочие нагрузки могут отличаться, цель уровней обслуживания — обеспечить высокую предсказуемость производительности на разных уровнях производительности. Они помогают клиентам с масштабными требованиями к ресурсам работать в более изолированной вычислительной среде.

Далее перечислены распространенные сценарии, в которых применяется уровень обслуживания Basic:

  • Начало работы с База данных SQL Azure — приложениям на этапе разработки часто не требуется высокий уровень производительности. Базы данных Basic предоставляют идеальную среду для разработки по низкой цене.

  • База данных с одним пользователем — приложениям, связывающим одного пользователя с базой данных, обычно не применяют строгие требования к параллельности и производительности. Такие приложения являются кандидатами для уровня обслуживания Basic.

Далее перечислены распространенные сценарии, в которых применяется уровень обслуживания Standard:

Базы данных с множеством параллельных запросов — приложения, обслуживающие множество пользователей одновременно, например веб-сайты с умеренным объемом трафика или приложения для различных подразделений, требующие большого объема ресурсов. Такие приложения являются хорошими кандидатами для уровня обслуживания Standard.

Далее перечислены распространенные сценарии, в которых применяется уровень обслуживания Premium:

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

  • Множество параллельных запросов — некоторые приложения обслуживают множество параллельных запросов, например веб-сайты с большим объемом трафика. Уровни обслуживания Basic и Standard накладывают ограничения на число параллельных запросов. Приложения, которым требуется больше подключений, должны зарезервировать соответствующий размер, чтобы справиться с максимальным числом запросов.

  • Небольшая задержка — некоторым приложениям требуется минимальное время отклика базы данных. Если определенная хранимая процедура вызывается как часть более широкого взаимодействия с клиентом, то в 99 % случаев отклик на такой запрос должен выполняться не более чем за 20 миллисекунд. Такое приложение будет хорошо работать с расширенной базой данных, которая обеспечивает необходимые вычислительные мощности.

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

Уровень, который потребуется приложению, зависит от пиковой нагрузки для каждого измерения ресурсов. Некоторые приложения могут использовать незначительные объемы одного ресурса и существенные объемы другого.

Структура уровней обслуживания представлена в следующей таблице.

 

Уровень обслуживания/уровень производительности DTU Максимальный размер базы данных Максимальное число рабочих потоков Максимальное число сеансов Предсказуемость

Базовое

5

2 GB

30

300

Хорошая

Standard/S0

10

250 GB

60

600

Лучше

Standard/S1

20

250 GB

90

900

Лучше

Standard/S2

50

250 GB

120

1,200

Лучше

Premium/P1

100

500 GB

200

2,400

Лучший

Premium/P2

200

500 GB

400

4,800

Лучший

Premium/P3

800

500 GB

1,600

19,200

Лучший

На следующей диаграмме показано почасовое использование ресурсов ЦП для базы данных Premium с уровнем производительности P2 в течение недели. Эта диаграмма начинается в понедельник, охватывает пять рабочих дней и затем выходные, когда нагрузка заметно снижается.

SQL_DB

Судя по этим данным пиковая нагрузка ЦП составляет чуть более 50 % от нагрузки ЦП по сравнению с уровнем производительности P2 (полдень вторника). Если ЦП был главным фактором ресурсного профиля приложения, то клиент может решить, что P2 — правильный уровень производительности, который может гарантировать стабильную работу нагрузок. Если ожидается рост нагрузки с течением времени, то целесообразно немного увеличить буфер ресурсов, чтобы приложение не смогло достигнуть предела производительности. Это позволит избежать заметных ошибок на стороне базы данных в результате нехватки мощности для эффективной обработки запросов, особенно в средах с небольшими задержками (например, для базы данных приложения, создающего веб-страницы на основе запросов к базе данных).

Стоит отметить, что другие приложения могут интерпретировать эту же диаграмму иначе. Например, если приложение попыталось обрабатывать данные каждый день и получало одну диаграмму, то такое пакетное задание будет хорошо работать и на уровне производительности P1. P1 предоставляет 100 DTU по сравнению с 200 DTU уровня P2. Это значит, что P2 обеспечивает производительность в 2 раза меньше, чем P2. Поэтому 50 % нагрузки ЦП на уровне P2 эквивалентно 100 % нагрузки ЦП на уровне P1. Если в работе приложения не возникает пауз, то может не иметь значения, выполняется большое задание 2 или 2,5 часа, а важно только то, чтобы оно закончилось сегодня. Приложение такой категории может вполне использовать уровень Р1. Пользователь может воспользоваться тем, что в определенное время дня использование ресурсов ниже, т. е. его пиковая нагрузка может быть перенесена именно на этот период. Уровень производительности Р1 может отлично подойти для такого приложения (и сэкономить деньги), если задания будут завершаться вовремя в течение одного дня.

База данных SQL Azure предоставляет сведения об использовании ресурсов по каждой активной базе данных в представлении sys.resource_stats для базы данных master на каждом сервере. Данные в таблице агрегируются каждые пять минут. В уровнях обслуживания Basic, Standard и Premium может потребоваться более 5 минут, прежде чем данные появятся в таблице, т. е. эти данные лучше подходят для исторического анализа, а не анализа в режиме реального времени. При запросе представления sys.resource_stats отображается журнал базы данных, позволяющий проверить, обеспечил ли выбранный уровень резервирования требуемую производительность. В следующем примере показано, как выглядят данные в этом представлении.

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB

Примечание. Некоторые столбцы в таблице были усечены. Полное описание выводимых данных см. в разделе sys.resource_stats.

В этом разделе описываются способы наблюдения за использованием ресурсов для База данных SQL Azure с целью сравнения фактически используемых ресурсов с разными уровнями производительности.

  1. Представление каталога sys.resource_stats содержит также исторические сведения использования ресурсов на уровне базы данных. Например, с учетом недельного использования ресурсов для базы данных «userdb1» можно выполнить следующий запрос.

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. Чтобы определить, какой уровень производительности лучше всего подходит для конкретной рабочей нагрузки, нужно детализировать углублением каждый аспект метрики ресурсов: ЦП, операции чтения и записи, число рабочих потоков и число сеансов. Ниже приводится измененный запрос к представлению sys.resource_stats для получения отчета о средних, а также максимальных параметрах использования ресурсов.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. С помощью средних и максимальных значений по каждому ресурсу можно оценить, как выбранный уровень производительности подходит для вашей рабочей нагрузки. В большинстве случаев средние значения из sys.resource_stats предоставляют хорошую основу для определения целевого резервирования. Эти сведения следует использовать в качестве опорного пункта. Например, если вы используете уровень обслуживания Standard с уровнем производительности S2, среднее число операций чтения и записи ЦП меньше 20 %, среднее число рабочих ролей меньше 50, а среднее число сеансов меньше 200, уровень S1 может подходить для этой рабочей нагрузки. Вы легко можете определить, подходят ли ограничения рабочих ролей и сеансов для вашей базы данных. Чтобы узнать, можно ли для базы данных использовать более низкий уровень производительности по отношению к нагрузке ЦП, операциям чтения и записи, разделите число DTU текущего уровня производительности и умножьте результат на 100:

    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20

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

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    В зависимости от целевого уровня обслуживания (SLO) базы данных вы можете определить, подходит ли более низкий уровень производительности для вашей рабочей нагрузки. Если SLO — 99,9% и указанный выше запрос возвращает значение больше 99,9 для всех трех измерений ресурсов, весьма вероятно, что рабочую нагрузку можно выполнять на более низком уровне производительности.

    Если посмотреть на процент, можно также понять, следует ли перейти на следующий уровень производительности для выполнения требований SLO. Например, "userdb1" показывает следующую нагрузку за прошедшую неделю.

     

    Средняя нагрузка ЦП, %

    Максимальная нагрузка ЦП, %

    24.5

    100.00

    Средняя нагрузка ЦП равна приблизительно одной четвертой ограничения уровня производительности, что вполне соответствует уровню производительности баз данных. Однако максимальное значение показывает, что база данных достигает ограничения уровня производительности. Требуется ли перейти на следующий уровень производительности? Опять же, необходимо определить, сколько раз рабочая нагрузка достигает 100 %, и сравнить это значение с SLO рабочей нагрузки базы данных.

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    Если указанный выше запрос возвращает значение меньше 99,9 для любого из трех измерений ресурсов, следует перейти на следующий уровень или использовать методы оптимизации приложения для сокращения нагрузки на База данных SQL Azure.

  4. В таких расчетах также следует учитывать возможное увеличение рабочей нагрузки в будущем.

В традиционной локальной среде SQL Server процесс изначального планирования загрузки часто отделен от процесса запуска приложения в рабочей среде. Другими словами, сначала происходит приобретение оборудования и связанных лицензий для запуска SQL Server и только потом настройка производительности. При использовании База данных SQL Azure обычно рекомендуется (и, поскольку счет выставляется ежемесячно, это также распространенный вариант) объединить процесс настройки и запуска приложения. Оплата только за используемые ресурсы позволяет клиентам настраивать приложение на использование минимальных ресурсов, которые нужны в данный момент, а не выполнять избыточное провизионирование согласно прогнозам будущего роста нагрузки на приложение. Часто такие прогнозы ошибочны, поскольку уходят слишком далеко в будущее. Обратите внимание, что некоторые пользователи предпочитают не настраивать приложение и вместо этого используют избыточное провизионирование ресурсов оборудования. Такой подход может оказаться целесообразным, если клиент не желает изменять ключевое приложение на период высокой нагрузки. Настройка приложения позволяет минимизировать потребление ресурсов и снизить ежемесячные расходы благодаря новым уровням обслуживания в База данных SQL Azure.

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

  • Приложения, которые обладают низкой производительностью в силу «нестабильной» работы

    В эту категорию входят приложения, которые совершают избыточные операции доступа к данным, несмотря на чувствительность к сетевым задержкам. Возможно, в такие приложения лучше внести изменения, сократив число операций доступа к данным в База данных SQL Azure. Например, приложение можно улучшить за счет пакетной обработки неструктурированных запросов или перемещения запросов в хранимые процедуры. Дополнительные сведения см. в разделе «Пакетные запросы» далее.

  • Базы данных с интенсивной рабочей нагрузкой, которые не могут работать на одном сервере

    Базы данных, которым требуется больше ресурсов, чем предоставляет уровень Premium, не являются хорошими кандидатами. Такие базы данных можно улучшить за счет масштабирования рабочей нагрузки. Дополнительные сведения см. в разделах «Сегментирование баз данных» и «Функциональное секционирование».

  • Приложения, содержащие неоптимальные запросы

    Приложения, особенно приложения уровня доступа к данным, которые используют неоптимальные запросы, скорее всего, не смогут воспользоваться преимуществами более высокого уровня производительности. К таким запросам относятся запросы, в которых нет предложения WHERE, отсутствуют индексы или используется устаревшая статистика. Больше пользы таким приложениям принесут стандартные методы оптимизации производительности. Дополнительные сведения см. в разделах «Недостающие индексы» и «Настройка запросов и подсказки» далее.

  • Приложения, которые имеют неоптимальную схему доступа к данным

    Приложения, в которых есть проблемы параллельного доступа к данным, например блокировка при одновременном доступе, не смогут воспользоваться преимуществами более высокого уровня производительности. Разработчики приложений могут попробовать снизить циклические операции к База данных SQL Azure путем кэширования данных на стороне клиента с помощью службы Azure Caching Service или других технологий кэширования. См. раздел «Кэширование на уровне приложения» далее.

В этом разделе описываются некоторые методы, которые можно использовать для настройки База данных SQL Azure с целью повышения производительности приложения и использования наименьшего уровня производительности. Ряд методов схожи с традиционными рекомендациями по настройке SQL Server, однако есть и специфические методы настройки База данных SQL Azure. В некоторых случаях традиционные методы SQL Server можно использовать для работы с База данных SQL Azure путем изучения использования ресурсов.

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

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

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


SQL_DB

База данных SQL Azure содержит функцию, которая указывает администраторам баз данных, как выявить условия, при которых индекс становится необходимым. Динамические административные представления (DMV), встроенные в База данных SQL Azure, учитывают во время компиляции запроса случаи, когда индекс мог бы значительно снизить нагрузку, связанную с выполнением запроса. Во время выполнения запроса представление отслеживает, как часто план запроса выполнялся, а также вычисляет разницу между планом выполнения запроса и возможным планом, если бы использовался индекс. Это позволит администратору баз данных быстро выяснить, какие изменения схемы базы данных могли бы существенно уменьшить рабочую нагрузку для определенной базы данных.

Следующий запрос можно использовать для оценки потенциально отсутствующих индексов.

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

В данном случае предлагается следующий индекс.

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

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

SQL_DB

Важно понимать, что пропускная способность общей среды обычно более ограниченная, чем способность выделенного сервера. По сути, можно минимизировать избыточное число операций ввода-вывода и максимально использовать ресурсы каждого уровня производительности, доступные в рамках уровней обслуживания База данных SQL Azure. Улучшение физической схемы базы данных может значительно повысить отклик определенных запросов, пропускную способность одновременных запросов и минимизировать затраты, необходимые на выполнение одного запроса. Дополнительные сведения о динамических административных представлениях для отсутствующих индексов см. в разделе sys.dm_db_missing_index_details.

Оптимизатор запросов в База данных SQL Azure очень напоминает традиционный оптимизатор запросов SQL Server. Многие рекомендации по настройке запросов и ограничения оптимизатора запросов применимы к База данных SQL Azure. Настройка запросов в База данных SQL Azure позволяет дополнительно снизить требования к ресурсам и фактические затраты, так как в результате можно будет использовать более низкий уровень производительности.

Распространенный пример работы с SQL Server, который также применим к База данных SQL Azure, имеет отношение к параметрам, которые вносятся на лету во время компиляции с целью создания более оптимального плана. Такое внесение параметров на лету означает, что оптимизатор запросов пересчитывает текущее значение параметра во время компиляции запроса с целью создания более оптимального плана запроса. Несмотря на то что такая стратегия может позволить создать план запроса, значительно более быстрый, чем план, созданный без такой оптимизации, текущее поведение SQL Server и База данных SQL Azure несовершенно. Возможны случаи, когда параметры не вносятся либо параметры вносятся, но созданный план не является оптимальным для полного набора параметров в рабочей нагрузке. Майкрософт включает указания запросов (директивы), которые позволяют указать, следует ли изменить поведение по умолчанию. Часто использование указаний позволяет устранить проблемы, когда работа SQL Server и База данных SQL Azure не идеально подходит для конкретной рабочей нагрузки.

В следующем примере показано, как обработчик запросов может создать план, который не является оптимальным в плане производительности и требований к ресурсам, и как использование указаний запросов может снизить время выполнения запроса и используемые ресурсы для База данных SQL Azure.

Ниже представлен пример установки.

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

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

Пример (часть 1).

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

Пример (часть 2 — подождите 10 минут, прежде чем проверять эту часть, чтобы получить очевидную разницу в итоговых данных телеметрии).

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


Каждая часть примера пытается выполнить параметризованную вставку 1000 раз (это необходимо для создания достаточной нагрузки). При выполнении хранимых процедур обработчик запросов учитывает значение параметра, переданное в процедуру во время первой компиляции (то, что называется вставкой на лету). Результирующий план кэшируется и используется в дальнейшем, даже если значение параметра будет другим. То есть оптимальный план может не подойти для всех случаев. Иногда нужно указывать оптимизатору, какой план выбрать, чтобы этот план был средним, а не просто подходящим для определенного случая. В этом примере изначальный план создает сканирование, при котором считываются все строки, и находится значение, которое отвечает параметру:

SQL_DB

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

Выполнение теста с параметром SET STATISTICS IO ON показывает работу логического сканирования. Видно, что план выполнил 1148 операций чтения, т. е. его эффективность очень низка, особенно если нужно вернуть только одну строку.

SQL_DB

Во второй части примера используется указание запроса, которое позволяет указать оптимизатору использовать конкретное значение во время компиляции. В данном случае обработчик запросов должен пропустить переданное значение и вместо этого предположить значение UNKNOWN, т. е. значение, которое будет иметь среднюю частоту в таблице (независимо от искажения распределения). Итоговый план — это план на основе поиска, который работает быстрее и использует меньше ресурсов, чем план из части 1.

SQL_DB

Эффект можно посмотреть в таблице sys.resource_stats (примечание: между временем выполнения теста и появлением данных в таблице будет задержка). В этом примере часть 1 выполнялась в рамках временного окна 22:25:00, а часть 2 — в 22:35:00. Обратите внимание, что часть 1 использовала больше ресурсов, чем часть 2 (в силу повышения эффективности).

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB

ImportantВажно!
Использованный пример достаточно примитивен, однако последствия неоптимальных параметров могут быть существенными, особенно для больших баз данных. Разница для быстрых и медленных запросов в некоторых случаях может достигать от нескольких секунд до нескольких часов.

Рекомендуется просмотреть sys.resource_stats, чтобы определить, использует ли один тест больше ресурсов, чем другой. При сравнении данных нужно закладывать между тестами достаточное время, чтобы они не группировались вместе в одном 5-минутном окне в представлении sys.resource_stats. Кроме того, обратите внимание, что цель расчетов — минимизировать общее использование ресурсов, а не пиковую нагрузку. Обычно оптимизация части кода с целью более быстрого исполнения также приводит к сокращению использования ресурсов. Убедитесь, что вносимые изменения действительно нужны и не сказываются на работе приложения отрицательным образом при использовании указаний запроса.

Если рабочая нагрузка содержит ряд повторяющихся запросов, то часто бывает целесообразно отследить и проверить оптимальность планов, так как это, скорее всего, позволит уменьшить минимальный размер ресурсов, необходимых базе данных. После проверки выборочный пересмотр планов позволит убедиться, что их производительность со временем не ухудшилась. Дополнительные сведения об указаниях запросов см. в разделе Указания запросов (Transact-SQL).

Поскольку База данных SQL Azure работает на неспециализированном оборудовании, ограничения для одной базы данных будут ниже, чем в традиционной локальной среде SQL Server. В силу этого ряд пользователей использует сегментирование баз данных, если размеры одной базы данных в База данных SQL Azure недостаточные. Многие пользователи, реализующие сегментирование База данных SQL Azure на сегодняшний день, разбивают данные одного измерения на несколько баз данных. Этот подход предполагает, что часто приложения OLTP выполняют транзакции, которые применимы к одной строке или небольшой группе строк внутри одной схемы. Например, если база данных содержит сведения о заказчике, заказе и цене (как можно видеть в стандартном примере базы данных Northwind, который используется для SQL Server), эти данные можно разбить на несколько баз, группируя все сведения и обеспечивая целостность данных. Приложение должно разбивать заказчиков по разным базам данных и эффективно распределять нагрузку. В результате можно не только не превышать существующее ограничение максимального размера базы данных, но и обрабатывать в База данных SQL Azure рабочие нагрузки, которые существенно превышают ограничения различных уровней производительности, если каждая отдельная база данных будет работать в соответствии с ограничениями DTU.

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

Пользователи SQL Server часто объединяют несколько функций в одной базе данных. Например, если приложение содержит логику управления запасами склада, то база данных может содержать логику, связанную с запасами, отслеживанием заказов на покупку, хранимыми процедурами и индексированными представлениями ежемесячных отчетов и т. д. Такой подход позволяет легко администрировать базы данных и выполнять такие операции как резервное копирование. Однако в этом случае нужно также умело распределять пиковую нагрузку функций одного приложения.

В рамках масштабируемой архитектуры внутри База данных SQL Azure часто лучше разнести функции приложения по разным базам данных. Это позволит каждой базе данных масштабироваться независимо. По мере повышения нагрузки на приложение (и, как следствие, нагрузки на базу данных) администратор сможет определить уровни производительности независимо для каждой функции одного приложения. Такая архитектура позволит приложению расширяться за пределы одного сервера за счет распределения нагрузки по разным серверам.

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

Некоторые приложения требуют большого количества операций записи. Иногда можно уменьшить общую нагрузку операций ввод-вывода для базы данных путем правильного пакетирования операций записи. Часто достаточно просто использовать явные транзакции вместо автоматической фиксации внутри хранимой процедуры. Оценка различных подходов рассматривается в разделе Методы пакетирования для приложений баз данных SQL в среде Azure. Рекомендуется экспериментировать с рабочей нагрузкой для нахождения оптимальной модели пакетной обработки с учетом того, что не все модели обеспечивают транзакционную целостность. Выявление наиболее оптимальной рабочей нагрузки минимизирует использование ресурсов.

Некоторые приложения базы данных содержат рабочие нагрузки, выполняющие много операций чтения. Можно использовать уровни кэширования с целью снижения нагрузки на базу данных, а также возможного понижения уровня производительности, необходимого для поддержки базы данных с помощью База данных SQL Azure. Azure Caching (кэширование) позволяет рабочей нагрузке с большим числом операций чтения считывать данные один раз (или, возможно, один раз в рамках одного сервера в зависимости от конфигурации) и сохранять данные вне База данных SQL Azure. В результате снижается нагрузка на базу данных (ЦП и число операций ввода-вывода), однако теряется транзакционная целостность, так как данные в кэше могут быть устаревшими по сравнению с данными в базе данных. Для многих приложений определенный уровень целостности приемлем, однако это верно не для всех рабочих нагрузок. Рекомендуется как следует изучить требования приложения, прежде чем использовать стратегию кэширования на уровне приложения.

Уровни обслуживания База данных SQL Azure расширяют возможности приложений, которые могут быть построены в облачной среде. В сочетании с надлежащей настройкой приложения эти возможности обеспечивают мощную и прогнозируемую производительность всего приложения. В настоящем документе описаны рекомендуемые способы оптимизации использования ресурсов базы данных для применения одного из новых уровней обслуживания. Тонкая настройка — это рутинная операция в облачной модели. Уровни обслуживания и их уровни производительности позволяют администраторам добиться максимальной производительности и минимизировать затраты на платформе Microsoft Azure.

См. также

Показ:
© 2014 Microsoft