Обзор модели приобретения на основе единиц DTU
Область применения:
База данных SQL Azure
В этой статье представлены сведения о модели приобретения на основе единиц DTU для Базы данных SQL Azure.
Дополнительные сведения есть в статьях о модели приобретения на основе виртуальных ядер и о сравнении моделей приобретения.
Единицы транзакций базы данных (DTU)
Единица транзакций базы данных (DTU) предоставляет собой объединенный показатель мощности ЦП, памяти, операций чтения и записи. Уровни службы, использующие модель приобретения на основе единиц DTU, предоставляют несколько объемов вычислительных ресурсов с фиксированным объемом хранилища, фиксированный срок хранения резервных копий и фиксированную цену. Все уровни служб, использующие модель приобретения на основе единиц DTU, позволяют гибко изменять объем вычислительных ресурсов с минимальным временем простоя, но в течение короткого промежутка времени при переключении между уровнями теряется подключение к базе данных. Эту проблему можно обойти, используя логику повторных попыток. Плата за отдельные базы данных и эластичные пулы начисляется за каждый час использования в соответствии с уровнем служб и объемом вычислительных ресурсов.
Для отдельной базы данных с определенным объемом вычислительных ресурсов, предоставляемых в соответствии с уровнем служб, корпорация Майкрософт гарантирует определенный объем ресурсов, который не зависит от других баз данных. Эта позволяет гарантировать предсказуемый уровень производительности. Объем ресурсов рассчитывается как количество единиц передачи данных или DTU и является комплексной оценкой вычислительных ресурсов, ресурсов хранилища и ресурсов ввода-вывода.
Коэффициент этих ресурсов первоначально определялся по тестовой рабочей нагрузке OLTP, отражающей фактические рабочие нагрузки OLTP. Если рабочая нагрузка превышает объем любого из этих ресурсов, то пропускная способность регулируется, что приводит к снижению производительности и простоям.
Ресурсы, используемые вашей рабочей нагрузкой в отдельной базе данных, не влияют на ресурсы других баз данных в облаке Azure. Точно таким же образом, ресурсы, используемые другими рабочими нагрузками, не влияют на ресурсы, доступные для вашей базы данных.
DTU лучше всего позволяют определить относительный объем ресурсов баз данных SQL Azure с разными объемами вычислительных ресурсов и уровнями служб. Пример:
- Например, повышение объема вычислительных ресурсов базы данных (через удвоение DTU) означает удвоение объема ресурсов, доступных для этой базы данных.
- База данных 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 % |
| Максимальное хранение резервных копий | 7 дней | 35 дней | 35 дней |
| ЦП | Низкий | Низкий, средний, высокий | Средний, высокий |
| Операции ввода-вывода в секунду (приблизительно)* | 1-4 операций ввода-вывода на DTU | 1-4 операций ввода-вывода на DTU | >25 операций ввода-вывода на DTU |
| Задержка ввода-вывода (приблизительно) | 5 мс (чтение), 10 мс (запись) | 5 мс (чтение), 10 мс (запись) | 2 мс (чтение и запись) |
| Индексирование columnstore | Н/Д | S3 и выше | Поддерживается |
| OLTP в памяти | Н/Д | Н/Д | Поддерживается |
* Все операции чтения и записи в секунду для файлов данных, включая фоновый ввод-вывод (контрольная точка и отложенный модуль записи)
Важно!
Цели служб Basic, S0, S1 и S2 предоставляют менее одного Виртуальное ядро (ЦП). Для рабочих нагрузок с интенсивным использованием ЦП рекомендуется использовать уровень обслуживания S3 или выше.
В целевых показателях служб Basic, S0 и S1 файлы базы данных хранятся в хранилище Azure уровня "Стандартный", использующем носитель для хранения на основе жесткого диска (HDD). Эти цели службы лучше всего подходят для разработки, тестирования и других редко используемых рабочих нагрузок, которые менее чувствительны к изменчивости производительности.
Совет
Чтобы просмотреть фактические ограничения управления ресурсами для базы данных или эластичного пула, запросите представление sys.dm_user_db_resource_governance.
Примечание
Вы можете получить бесплатную базу данных в базе данных SQL Azure на уровне "базовый" службы в сочетании с бесплатной учетной записью Azure для изучения Azure. Сведения см. в разделе Создание управляемой облачной базы данных с помощью бесплатной учетной записи Azure.
Ограничения ресурсов
Ограничения ресурсов отдельных баз данных и баз данных в пуле
Ограничения хранилища для отдельной базы данных
Объем вычислительных ресурсов выражается в единицах транзакций базы данных (DTU) для отдельных баз данных, а для эластичных пулов — в единицах транзакций эластичной базы данных (eDTU). Чтобы узнать больше, изучите ограничения по ресурсам для отдельной базы данных.
| Basic | Standard | Premium | |
|---|---|---|---|
| Максимальный размер хранилища | 2 ГБ | 1 TБ | 4 TБ |
| Максимальное число DTU | 5 | 3000 | 4000 |
Важно!
Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье об управлении файловым пространством в Базе данных SQL Azure.
Ограничения для пула эластичных баз данных
Чтобы узнать больше, изучите ограничения по ресурсам для баз данных в пуле.
| Основной | Standard Edition | Премиальный | |
|---|---|---|---|
| Максимальный размер хранилища для базы данных | 2 ГБ | 1 ТБ | 1 ТБ |
| Максимальный размер хранилища для пула | 156 ГБ | 4 TБ | 4 TБ |
| Максимальное число eDTU на базу данных | 5 | 3000 | 4000 |
| Максимальное число eDTU на пул | 1600 | 3000 | 4000 |
| Максимальное количество баз данных на пул | 500 | 500 | 100 |
Важно!
Хранилище размером более 1 ТБ на уровне "Премиум" в настоящее время доступно во всех регионах, за исключением Восточного и Северного Китая, а также Центральной и Северо-Восточной Германии. В этих регионах максимальный объем хранилища категории "Премиум" ограничен 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.