Обзор модели закупок на базе DTU

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

В этой статье представлен обзор модели приобретения для Azure SQL Database на основе DTU. Модель приобретения на основе DTU — это простая, комплексная мера вычислительных ресурсов, хранилища и ввода-вывода. Лучше всего подходит для большинства клиентов с типичными рабочими нагрузками. Модель приобретения на основе DTU доступна на уровнях служб "Базовый", "Стандартный" и "Премиум". Модель приобретения на основе DTU также доступна для эластичных пулов.

Модель приобретения, основанная на DTU, отличается от модели приобретения, основанной на vCore, поэтому можно сравнить модели приобретения.

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

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

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

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

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

DTU наиболее полезны для понимания относительных ресурсов, выделяемых для баз данных при различных размерах вычислительных мощностей и уровнях обслуживания. Например:

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

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

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

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

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

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

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

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

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

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

Определение числа единиц 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)

Входные значения для этой формулы можно получить из динамических административных представлений (DMV) 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 benchmark останутся примерно теми же, при условии, что целевое назначение услуги (количество DTU) остается неизменным.

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

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

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

Примечание.

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

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

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

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

² Для получения дополнительных сведений см. Изменение уровней обслуживания баз данных, содержащих индексы columnstore.

Внимание

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

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

Совет

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

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

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

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

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

	Базовый	Стандарт	Премиум
Максимальный размер хранилища	2 ГБ	1 TБ	4 ТБ
Максимальное число DTU	5	3000	4000

Внимание

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

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

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

	Базовая	Стандартные	Премиум
Максимальный размер хранилища для базы данных	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 и vCore

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

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

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

Связанный контент

• Ограничения ресурсов на основе DTU для отдельных баз данных
• Ограничения ресурсов на основе DTU
• Тест производительности DTU
• Сравнение моделей приобретения Azure SQL Database на основе vCore и DTU