Обзор модели приобретения на основе единиц DTU

Применимо к:База данных SQL Azure

В этой статье представлены сведения о модели приобретения на основе единиц DTU для Базы данных SQL Azure.

Дополнительные сведения есть в статьях о модели приобретения на основе виртуальных ядер и о сравнении моделей приобретения.

Единицы транзакций базы данных (DTU)

Единица транзакций базы данных (DTU) предоставляет собой объединенный показатель мощности ЦП, памяти, операций чтения и записи. Уровни службы, использующие модель приобретения на основе единиц DTU, предоставляют несколько объемов вычислительных ресурсов с фиксированным объемом хранилища, фиксированный срок хранения резервных копий и фиксированную цену. Все уровни служб, использующие модель приобретения на основе единиц DTU, позволяют гибко изменять объем вычислительных ресурсов с минимальным временем простоя, но в течение короткого промежутка времени при переключении между уровнями теряется подключение к базе данных. Эту проблему можно обойти, используя логику повторных попыток. Плата за отдельные базы данных и эластичные пулы начисляется за каждый час использования в соответствии с уровнем служб и объемом вычислительных ресурсов.

Для отдельной базы данных с определенным объемом вычислительных ресурсов, предоставляемых в соответствии с уровнем служб, корпорация Майкрософт гарантирует определенный объем ресурсов, который не зависит от других баз данных. Эта позволяет гарантировать предсказуемый уровень производительности. Объем ресурсов рассчитывается как количество единиц передачи данных или DTU и является комплексной оценкой вычислительных ресурсов, ресурсов хранилища и ресурсов ввода-вывода.

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

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

DTU лучше всего позволяют определить относительный объем ресурсов баз данных SQL Azure с разными объемами вычислительных ресурсов и уровнями служб. Например:

• Например, повышение объема вычислительных ресурсов базы данных (через удвоение DTU) означает удвоение объема ресурсов, доступных для этой базы данных.
• База данных уровня служб Premium P11 с 1750 DTU обеспечивает 350 раз больше вычислительной мощности DTU, чем базовая база данных уровня служб с 5 единицами DTU.

Чтобы рассмотреть потребление ресурсов (DTU) в вашей рабочей нагрузке, используйте анализ производительности запросов, который позволит:

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

Единицы транзакций эластичной базы данных (eDTU)

Если для базы данных не всегда требуется наличие выделенного набора ресурсов (фиксированный объем DTU), ее можно поместить в эластичный пул. Для всех баз данных в эластичном пуле используется один экземпляр ярда СУБД и общий набор ресурсов.

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

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

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

Рабочие нагрузки, для которых эффективно используется эластичный пул ресурсов

Пулы хорошо подходят для баз данных с низким средним использованием ресурсов и относительно редких пиков нагрузки. Дополнительные сведения см. разделе Когда следует использовать эластичный пул Базы данных SQL?.

Определение числа единиц DTU, требуемых для рабочей нагрузки

Если вам нужно перенести существующую рабочую нагрузку с локальной виртуальной машины или SQL Server в Базу данных SQL, то вы можете приблизительно оценить требуемое количество DTU, используя наши рекомендации по ценовым категориям. Чтобы разобраться, как потребляются ресурсы (DTU) в существующей рабочей нагрузке Базы данных SQL Azure, и понять, как оптимизировать эту нагрузку, можно воспользоваться анализом производительности запросов. Динамическое административное представление sys.dm_db_resource_stats позволяет просматривать потребление ресурсов за последний час. Представление каталога sys.resource_stats содержит те же сведения, но за последние 14 дней, причем с менее точными средними значениями за пять минут.

Определение загрузки DTU

Чтобы определить средний процент использования DTU/eDTU относительно ограничения DTU/eDTU базы данных или эластичного пула, используйте следующую формулу:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Входные значения для этой формулы можно получить из динамических административных представлений sys.dm_db_resource_stats, sys.resource_statsи sys.elastic_pool_resource_stats. Иными словами, чтобы определить процент использования DTU/eDTU в отношении ограничения DTU/eDTU базы данных или эластичного пула, выберите наибольшее процентное значение из следующих значений: avg_cpu_percent, avg_data_io_percent и avg_log_write_percent на заданный момент времени.

Примечание.

Ограничение DTU базы данных определяется ЦП, операциями чтения, записи и памятью, доступной базе данных. Но поскольку ядро Базы данных SQL обычно использует всю доступную память для кэша данных для повышения производительности, avg_memory_usage_percent значение обычно будет близко к 100 % независимо от текущей загрузки базы данных. Таким образом, несмотря на то, что память косвенно влияет на предел DTU, она не используется в формуле использования DTU.

Настройка оборудования

В модели приобретения на основе DTU клиенты не могут выбрать конфигурацию оборудования, которое используется для баз данных. Несмотря на то, что база данных обычно остается на оборудования определенного типа в течение длительного времени (обычно несколько месяцев), в некоторых случаях база данных может переноситься на другое оборудование.

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

Если база данных перемещается на другое оборудование, то производительность рабочей нагрузки может измениться. Модель DTU гарантирует, что при переносе базы данных на оборудование другого типа пропускная способность и время отклика рабочей нагрузки производительности DTU останутся примерно теми же при условии, что цель обслуживания (количество DTU) остается неизменной.

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

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

Сравнить уровни служб

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

	Basic	Standard	Premium
Целевая рабочая нагрузка	Разработка и применение в рабочей среде.	Разработка и применение в рабочей среде.	Разработка и применение в рабочей среде.
Соглашение об уровне обслуживания с гарантией времени непрерывной работы	99,99 %	99,99 %	99,99 %
Azure Backup	Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, 1-7 дней хранения (по умолчанию 7 дней) Долгосрочное хранение доступно до 10 лет	Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, 1–35 дней хранения (по умолчанию 7 дней) Долгосрочное хранение доступно до 10 лет	Выбор локально избыточного хранилища (LRS), избыточного между зонами (ZRS) или геоизбыточного хранилища (GRS) Срок хранения 1–35 дней (по умолчанию — 7 дней) с сроком хранения до 10 лет.
ЦП	Низкая	Низкая, Средняя, Высокая	Среднее, высокое
Операции ввода-вывода в секунду (приблизительно)*	1-4 операций ввода-вывода на DTU	1-4 операций ввода-вывода на DTU	>25 операций ввода-вывода в секунду на DTU
Задержка ввода-вывода (приблизительно)	5 мс (чтение), 10 мс (запись)	5 мс (чтение), 10 мс (запись)	2 мс (чтение и запись)
Индексирование columnstore	Н/П	Стандартный S3 и более поздние версии	Поддерживается
OLTP в памяти	Неприменимо	Неприменимо	Поддерживается

* Все операции чтения и записи операций ввода-вывода в секунду для файлов данных, включая фоновые операции ввода-вывода (проверка point и отложенный модуль записи).

Внимание

Цели служб Basic, S0, S1 и S2 предоставляют менее одного Виртуальное ядро (ЦП). Для рабочих нагрузок с интенсивным использованием ЦП рекомендуется использовать уровень обслуживания S3 или выше.

В целевых показателях служб Basic, S0 и S1 файлы базы данных хранятся в хранилище Azure уровня "Стандартный", использующем носитель для хранения на основе жесткого диска (HDD). Эти цели службы лучше всего подходят для разработки, тестирования и других редко используемых рабочих нагрузок, которые менее чувствительны к изменчивости производительности.

Совет

Чтобы просмотреть фактические ограничения управления ресурсами для базы данных или эластичного пула, запросите представление sys.dm_user_db_resource_governance. Для одной базы данных возвращается одна строка. Для базы данных в эластичном пуле возвращается строка для каждой базы данных в пуле.

Примечание.

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

Ограничения ресурсов

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

Ограничения хранилища для отдельной базы данных

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

	Basic	Standard	Premium
Максимальный размер хранилища	2 ГБ	1 TБ	4 ТБ
Максимальное число DTU	5	3000	4000

Внимание

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

Ограничения для пула эластичных баз данных

Чтобы узнать больше, изучите ограничения по ресурсам для баз данных в пуле.

	Базовая	Стандартные	Премиум
Максимальный размер хранилища для базы данных	2 ГБ	1 TБ	1 TБ
Максимальный размер хранилища для пула	156 ГБ	4 ТБ	4 ТБ
Максимальное число eDTU на базу данных	5	3000	4000
Максимальное число eDTU на пул	1600	3000	4000
Максимальное количество баз данных на пул	500	500	100

Внимание

Хранилище размером более 1 ТБ на уровне "Премиум" в настоящее время доступно во всех регионах, за исключением Восточного и Северного Китая, а также Центральной и Северо-Восточной Германии. В этих регионах максимальный объем хранилища класса Premium ограничен 1 ТБ. Дополнительные сведения см. в разделе о действующих ограничениях для P11-P15.

Внимание

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

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

Физические характеристики (ЦП, память, ввод-вывод), связанные с каждым измерением DTU, калибруются на основе теста производительности, который имитирует рабочую нагрузку реальной базы данных.

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

Сравнение моделей приобретения на основе DTU и виртуальных ядер

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

Модель приобретения на основе виртуальных ядер также позволяет использовать Преимущество гибридного использования Azure для SQL Server для экономии затрат, а также поддерживает бессерверные и гипермасштабированные варианты для Базы данных SQL Azure, которые недоступны в модели приобретения на основе единиц DTU.

Дополнительные сведения см. в разделе Сравнение моделей приобретения на основе виртуальных ядер и на основе единиц DTU для Базы данных SQL Azure.

Следующие шаги

Дополнительные сведения о моделях приобретения и связанных с ними понятиях см. в следующих статьях:

• Дополнительные сведения о конкретных объемах вычислительных ресурсов и доступных размерах хранилища для отдельной базы данных см. в этом разделе.
• Дополнительные сведения о конкретных объемах вычислительных ресурсов и доступных размерах хранилища эластичных пулов см. в разделе Эластичный пул: размеры хранилища и объемы вычислительных ресурсов.
• Сведения о тесте производительности, связанном с моделью приобретения на основе единиц DTU, см. в разделе "Тест производительности DTU".
• Сравнение моделей приобретения на основе виртуальных ядер и на основе единиц DTU для Базы данных SQL Azure.