Уровни службы в модели приобретения на основе единицы DTUService tiers in the DTU-based purchase model

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных SQL Azure

Уровни службы в модели приобретения на основе единицы DTU отличаются диапазоном объемов вычислительных ресурсов с фиксированным включенным объемом хранилища, фиксированным сроком хранения резервных копий и фиксированной ценой.Service tiers in the DTU-based purchase model are differentiated by a range of compute sizes with a fixed amount of included storage, fixed retention period for backups, and fixed price. Все уровни служб в модели приобретения на основе DTU обеспечивают гибкость изменения размеров вычислений с минимальным временем простоя; Тем не менее в течение короткого промежутка времени, которое можно уменьшить с помощью логики повторных попыток, существует переключение между периодами, в которых подключение к базе данных теряется.All service tiers in the DTU-based purchase model provide flexibility of changing compute sizes with minimal downtime; however, there is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic. Плата за отдельные базы данных и эластичные пулы начисляется за каждый час использования в соответствии с уровнем служб и объемом вычислительных ресурсов.Single databases and elastic pools are billed hourly based on service tier and compute size.

Важно!

Управляемый экземпляр Azure SQL не поддерживает модель приобретения на основе DTU.Azure SQL Managed Instance does not support a DTU-based purchasing model.

Примечание

Дополнительные сведения об уровнях служб на основе виртуальных ядер см. в разделе Уровни служб на основе виртуальных ядер.For information about vCore-based service tiers, see vCore-based service tiers. Сведения о том, как различать уровни служб на основе DTU и уровни служб на основе виртуальное ядро, см. в разделе модели приобретения.For information about differentiating DTU-based service tiers and vCore-based service tiers, see purchasing models.

Сравнение уровней служб на основе числа DTUCompare the DTU-based service tiers

Выбор уровня служб зависит главным образом от требований к непрерывности бизнес-процессов, хранилищу и производительности.Choosing a service tier depends primarily on business continuity, storage, and performance requirements.

BasicBasic StandardStandard PremiumPremium
Целевая рабочая нагрузкаTarget workload Разработка и применение в рабочей среде.Development and production Разработка и применение в рабочей среде.Development and production Разработка и применение в рабочей среде.Development and production
Соглашение об уровне обслуживания с гарантией времени непрерывной работыUptime SLA 99,99 %99.99% 99,99 %99.99% 99,99 %99.99%
Максимальное хранение резервных копийMaximum backup retention 7 дней7 days 35 дней35 days 35 дней35 days
ЦПCPU НизкийLow Низкий, средний, высокийLow, Medium, High Средний, высокийMedium, High
Операций ввода-вывода (приблизительно)*IOPS (approximate)* 1-4 операций ввода-вывода на единицу DTU1-4 IOPS per DTU 1-4 операций ввода-вывода на единицу DTU1-4 IOPS per DTU 25 операций ввода-вывода на единицу DTU25 IOPS per DTU
Задержка ввода-вывода (приблизительно)IO latency (approximate) 5 мс (чтение), 10 мс (запись)5 ms (read), 10 ms (write) 5 мс (чтение), 10 мс (запись)5 ms (read), 10 ms (write) 2 мс (чтение и запись)2 ms (read/write)
Индексирование columnstoreColumnstore indexing НедоступноN/A S3 и вышеS3 and above ПоддерживаетсяSupported
Выполняющаяся в памяти OLTPIn-memory OLTP НедоступноN/A НедоступноN/A ПоддерживаетсяSupported

* Все операции чтения и записи в секунду для файлов данных, включая фоновый ввод-вывод (контрольная точка и отложенный модуль записи)* All read and write IOPS against data files, including background IO (checkpoint and lazy writer)

Важно!

Цели служб Basic, S0, S1 и S2 предоставляют менее одного Виртуальное ядро (ЦП).The Basic, S0, S1 and S2 service objectives provide less than one vCore (CPU). Для рабочих нагрузок с интенсивным использованием ЦП рекомендуется использовать уровень обслуживания S3 или выше.For CPU-intensive workloads, a service objective of S3 or greater is recommended.

В целевых показателях служб Basic, S0 и S1 файлы базы данных хранятся в хранилище Azure уровня "Стандартный", использующем носитель для хранения на основе жесткого диска (HDD).In the Basic, S0, and S1 service objectives, database files are stored in Azure Standard Storage, which uses hard disk drive (HDD)-based storage media. Эти цели службы лучше всего подходят для разработки, тестирования и других редко используемых рабочих нагрузок, которые менее чувствительны к изменчивости производительности.These service objectives are best suited for development, testing, and other infrequently accessed workloads that are less sensitive to performance variability.

Совет

Чтобы просмотреть фактические ограничения управления ресурсами для базы данных или эластичного пула, запросите представление sys.dm_user_db_resource_governance .To see actual resource governance limits for a database or elastic pool, query the sys.dm_user_db_resource_governance view.

Примечание

Вы можете получить бесплатную базу данных в базе данных SQL Azure на уровне "базовый" службы в сочетании с бесплатной учетной записью Azure для изучения Azure.You can get a free database in Azure SQL Database at the Basic service tier in conjunction with an Azure free account to explore Azure. Сведения см. в разделе Создание управляемой облачной базы данных с помощью бесплатной учетной записи Azure.For information, see Create a managed cloud database with your Azure free account.

DTU отдельной базы данных и ограничения хранилищаSingle database DTU and storage limits

Объем вычислительных ресурсов выражается в единицах транзакций базы данных (DTU) для отдельных баз данных, а для эластичных пулов — в единицах транзакций эластичной базы данных (eDTU).Compute sizes are expressed in terms of Database Transaction Units (DTUs) for single databases and elastic Database Transaction Units (eDTUs) for elastic pools. Дополнительные сведения об DTU и Edtu см. в разделе модель приобретения на основе DTU.For more on DTUs and eDTUs, see DTU-based purchasing model.

BasicBasic StandardStandard PremiumPremium
Максимальный размер хранилищаMaximum storage size 2 ГБ2 GB 1 TБ1 TB 4 TБ4 TB
Максимальное число DTUMaximum DTUs 55 30003000 40004000

Важно!

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство.Under some circumstances, you may need to shrink a database to reclaim unused space. Дополнительные сведения см. в статье Управление дисковым пространством в базе данных SQL Azure.For more information, see Manage file space in Azure SQL Database.

eDTU эластичного пула, хранилище и пределы для базы данных в пулеElastic pool eDTU, storage, and pooled database limits

ОсновнойBasic Standard EditionStandard ПремиальныйPremium
Максимальный размер хранилища на базу данныхMaximum storage size per database 2 ГБ2 GB 1 ТБ1 TB 1 ТБ1 TB
Максимальный размер хранилища на пулMaximum storage size per pool 156 ГБ156 GB 4 TБ4 TB 4 TБ4 TB
Максимальное число eDTU на базу данныхMaximum eDTUs per database 55 30003000 40004000
Максимальное число eDTU на пулMaximum eDTUs per pool 16001600 30003000 40004000
Максимальное количество баз данных на пулMaximum number of databases per pool 500500 500500 100100

Важно!

Более 1 ТБ хранилища на уровне "Премиум" в настоящее время доступны во всех регионах, кроме: Восточный Китай, Северный Китай, Центрально-Центральный регион и Северо-Восточная Германия.More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, and Germany Northeast. В этих регионах максимальный объем хранилища категории "Премиум" ограничен 1 ТБ.In these regions, the storage max in the Premium tier is limited to 1 TB. Дополнительные сведения см. в разделе о действующих ограничениях для P11-P15.For more information, see P11-P15 current limitations.

Важно!

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство.Under some circumstances, you may need to shrink a database to reclaim unused space. Дополнительные сведения см. в статье Управление дисковым пространством в базе данных SQL Azure.For more information, see manage file space in Azure SQL Database.

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

Физические характеристики (ЦП, память, ввод-вывод), связанные с каждым измерением DTU, калибруются с использованием теста производительности, который имитирует рабочую нагрузку реальной базы данных.Physical characteristics (CPU, memory, IO) associated to each DTU measure are calibrated using a benchmark that simulates real-world database workload.

Соотнесение результатов тестирования производительности с реальной производительностью базы данныхCorrelating benchmark results to real world database performance

Важно понимать, что все тесты производительности являются лишь показательными и ориентировочными.It is important to understand that all benchmarks are representative and indicative only. Показатели скорости транзакций, достигнутые приложением тестирования производительности, будут отличаться от таких показателей других приложений.The transaction rates achieved with the benchmark application will not be the same as those that might be achieved with other applications. Тест производительности состоит из набора транзакций разных типов, выполняемых в схеме, которая содержит целый ряд таблиц и типов данных.The benchmark comprises a collection of different transaction types run against a schema containing a range of tables and data types. Хотя тест производительности выполняет основные операции, свойственные для всех рабочих нагрузок OLTP, он не представляет какой-либо определенный класс базы данных или приложения.While the benchmark exercises the same basic operations that are common to all OLTP workloads, it does not represent any specific class of database or application. Цель тестирования производительности заключается в предоставлении приемлемых рекомендаций для относительной производительности базы данных, которую можно ожидать при переходе на более высокий или более низкий объем вычислительных ресурсов.The goal of the benchmark is to provide a reasonable guide to the relative performance of a database that might be expected when scaling up or down between compute sizes. На самом деле базы данных имеют разные размеры и сложность, обрабатывают разные сочетания рабочих нагрузок и реагируют разными способами.In reality, databases are of different sizes and complexity, encounter different mixes of workloads, and will respond in different ways. Например, приложение с большим объемом операций ввода-вывода может быстрее достигнуть порогового значения таких операций или приложение с интенсивной нагрузкой ЦП может быстрее достигнуть порогового значения такой нагрузки.For example, an IO-intensive application may hit IO thresholds sooner, or a CPU-intensive application may hit CPU limits sooner. Нет никакой гарантии, что конкретная база данных будет увеличиваться так же, как это показывает тест производительности при увеличении нагрузки.There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.

Тест производительности и его методология подробно описаны ниже.The benchmark and its methodology are described in more detail below.

Сводка о тесте производительностиBenchmark summary

Тест производительности измеряет производительность набора основных операций базы данных, выполняемых чаще всего при рабочих нагрузках оперативной обработки транзакций (OLTP).The benchmark measures the performance of a mix of basic database operations that occur most frequently in online transaction processing (OLTP) workloads. Хотя тест производительности разрабатывался для облачных вычислений, схемы базы данных, заполнение данными и транзакции рассчитаны на максимально широкий уровень репрезентативности основных элементов, которые чаще всего используются в рабочих нагрузках OLTP.Although the benchmark is designed with cloud computing in mind, the database schema, data population, and transactions have been designed to be broadly representative of the basic elements most commonly used in OLTP workloads.

схемаSchema

Схема разработана таким образом, чтобы предоставить достаточную степень разнообразия и сложности для поддержки широкого диапазона операций.The schema is designed to have enough variety and complexity to support a broad range of operations. Тест производительности выполняется в базе данных, состоящей из шести таблиц.The benchmark runs against a database comprised of six tables. Эти таблицы делятся на три категории: фиксированного размера, масштабируемые и расширяемые.The tables fall into three categories: fixed-size, scaling, and growing. Есть две таблицы фиксированного размера, три масштабируемые таблицы и одна расширяемая таблица.There are two fixed-size tables; three scaling tables; and one growing table. Таблицы фиксированного размера имеют неизменное количество строк.Fixed-size tables have a constant number of rows. Масштабируемые таблицы имеют кратность, пропорциональную производительности базы данных, но не изменяемую во время тестирования производительности.Scaling tables have a cardinality that is proportional to database performance, but doesn’t change during the benchmark. Расширяемая таблица имеет такой же размер, что и масштабируемая таблица при начальной нагрузке, но затем в процессе тестирования производительности кратность изменяется по мере добавления и удаления строк.The growing table is sized like a scaling table on initial load, but then the cardinality changes in the course of running the benchmark as rows are inserted and deleted.

Схема включает сочетание типов данных, в том числе целое число, цифру, символ, а также дату и время.The schema includes a mix of data types, including integer, numeric, character, and date/time. Схема включает первичные и вторичные ключи, но не имеет внешних ключей, т. е. между таблицами нет ограничений ссылочной целостности.The schema includes primary and secondary keys, but not any foreign keys - that is, there are no referential integrity constraints between tables.

Программа формирования данных создает данные для исходной базы данных.A data generation program generates the data for the initial database. Целочисленные и числовые данные создаются с помощью разных стратегий.Integer and numeric data is generated with various strategies. В некоторых случаях значения случайным образом распределяются в диапазоне.In some cases, values are distributed randomly over a range. Чтобы гарантировать соблюдение конкретного распределения в других случаях, набор значений переставляется случайным образом.In other cases, a set of values is randomly permuted to ensure that a specific distribution is maintained. Текстовые поля создаются из взвешенного списка слов для формирования реалистичных данных.Text fields are generated from a weighted list of words to produce realistic looking data.

Размер базы данных устанавливается в соответствии с «коэффициентом масштабирования».The database is sized based on a “scale factor.” Коэффициент масштабирования (сокращенно SF) определяет кратность элементов в масштабируемых и растущих таблицах.The scale factor (abbreviated as SF) determines the cardinality of the scaling and growing tables. Как описано ниже, в разделе «Пользователи и пошаговое продвижение», размер базы данных, количество пользователей и максимальная производительность масштабируются пропорционально друг к другу.As described below in the section Users and Pacing, the database size, number of users, and maximum performance all scale in proportion to each other.

TransactionsTransactions

Рабочая нагрузка состоит из девяти типов транзакций, как показано в следующей таблице.The workload consists of nine transaction types, as shown in the table below. Каждая транзакция должна подчеркивать определенный набор системных характеристик в ядре СУБД и системном оборудовании. При этом она должна явно отличаться от других транзакций.Each transaction is designed to highlight a particular set of system characteristics in the database engine and system hardware, with high contrast from the other transactions. Такой подход упрощает оценку влияния различных компонентов на общую производительность.This approach makes it easier to assess the impact of different components to overall performance. Например, транзакция «Чтение, высокая интенсивность» создает значительное число операций чтения с диска.For example, the transaction “Read Heavy” produces a significant number of read operations from disk.

Тип транзакцииTransaction Type ОписаниеDescription
Чтение, низкая интенсивностьRead Lite ВЫБОР; в памяти; только для чтенияSELECT; in-memory; read-only
Носитель для чтенияRead Medium ВЫБОР; в основном в памяти; только для чтенияSELECT; mostly in-memory; read-only
Чтение, высокая интенсивностьRead Heavy ВЫБОР; в основном не в памяти; только для чтенияSELECT; mostly not in-memory; read-only
Обновление, низкая интенсивностьUpdate Lite ОБНОВЛЕНИЕ; в памяти; чтение и записьUPDATE; in-memory; read-write
Обновление, высокая интенсивностьUpdate Heavy ОБНОВЛЕНИЕ; в основном не в памяти; чтение и записьUPDATE; mostly not in-memory; read-write
Вставка, низкая интенсивностьInsert Lite ВСТАВКА; в памяти; чтение и записьINSERT; in-memory; read-write
Вставка, высокая интенсивностьInsert Heavy ВСТАВКА; в основном не в памяти; чтение и записьINSERT; mostly not in-memory; read-write
DELETEDelete УДАЛЕНИЕ; сочетание в памяти и не в памяти; чтение и записьDELETE; mix of in-memory and not in-memory; read-write
ЦП, высокая интенсивностьCPU Heavy ВЫБОР; в памяти; относительно высокая загрузка ЦП; только для чтенияSELECT; in-memory; relatively heavy CPU load; read-only

Сочетание рабочих нагрузокWorkload mix

Транзакции выбираются случайным образом из взвешенного распределения следующего общего сочетания.Transactions are selected at random from a weighted distribution with the following overall mix. Обще сочетание имеет соотношение чтения и записи 2:1.The overall mix has a read/write ratio of approximately 2:1.

Тип транзакцииTransaction Type Процент от сочетания% of Mix
Чтение, низкая интенсивностьRead Lite 3535
Носитель для чтенияRead Medium 2020
Чтение, высокая интенсивностьRead Heavy 55
Обновление, низкая интенсивностьUpdate Lite 2020
Обновление, высокая интенсивностьUpdate Heavy 33
Вставка, низкая интенсивностьInsert Lite 33
Вставка, высокая интенсивностьInsert Heavy 22
DELETEDelete 22
ЦП, высокая интенсивностьCPU Heavy 1010

Пользователи и пошаговое продвижениеUsers and pacing

Рабочая нагрузка теста производительности определяется с помощью средства, которое передает транзакции через ряд подключений для имитации работы определенного количества одновременных пользователей.The benchmark workload is driven from a tool that submits transactions across a set of connections to simulate the behavior of a number of concurrent users. Хотя все подключения и транзакции создаются компьютером, для простоты мы называем эти подключения «пользователи».Although all of the connections and transactions are machine generated, for simplicity we refer to these connections as “users.” Несмотря на то, что каждый пользователь работает независимо от других пользователей, все они выполняют одинаковый цикл, показанный ниже:Although each user operates independently of all other users, all users perform the same cycle of steps shown below:

  1. Установление подключения к базе данных.Establish a database connection.
  2. Повторение до получения сигнала выхода:Repeat until signaled to exit:
    • случайный выбор транзакций (из взвешенного распределения);Select a transaction at random (from a weighted distribution).
    • выполнение выбранной транзакции и измерение времени ответа;Perform the selected transaction and measure the response time.
    • ожидание задержки шага.Wait for a pacing delay.
  3. Завершение подключения к базе данных.Close the database connection.
  4. Выйти.Exit.

Задержка шага (в действии 2в) выбирается случайным образом, однако с распределением со средним значением в 1,0 секунду.The pacing delay (in step 2c) is selected at random, but with a distribution that has an average of 1.0 second. Таким образом, в среднем каждый пользователь может создавать максимум одну транзакцию в секунду.Thus each user can, on average, generate at most one transaction per second.

Правила масштабированияScaling rules

Количество пользователей определяется размером базы данных (в единицах коэффициента масштабирования).The number of users is determined by the database size (in scale-factor units). Существует один пользователь на каждые пять единиц коэффициента масштабирования.There is one user for every five scale-factor units. Из-за задержки шага один пользователь может в среднем создавать не более одной транзакции в секунду.Because of the pacing delay, one user can generate at most one transaction per second, on average.

Например, база данных с коэффициентом масштабирования 500 (SF=500) будет иметь 100 пользователей и может достичь максимальной скорости в 100 транзакций в секунду.For example, a scale-factor of 500 (SF=500) database will have 100 users and can achieve a maximum rate of 100 TPS. Для более высокой скорости требуется больше пользователей и большие размеры базы данных.To drive a higher TPS rate requires more users and a larger database.

Продолжительность измеренияMeasurement duration

Для правильного выполнения теста производительности требуется измерять устойчивое состояние по крайней мере один час.A valid benchmark run requires a steady-state measurement duration of at least one hour.

МетрикиMetrics

Ключевыми показателями теста производительности являются пропускная способность и время ответа.The key metrics in the benchmark are throughput and response time.

  • Пропускная способность — это важный показатель производительности в тесте производительности.Throughput is the essential performance measure in the benchmark. Пропускная способность измеряется в транзакциях в единицу времени, учитывая все типы транзакций.Throughput is reported in transactions per unit-of-time, counting all transaction types.
  • Время отклика — это показатель прогнозируемости производительности.Response time is a measure of performance predictability. Ограничение времени ответа зависит от класса службы. Более высокие классы службы имеют более строгие требования ко времени ответа, как показано ниже.The response time constraint varies with class of service, with higher classes of service having a more stringent response time requirement, as shown below.
Класс службыClass of Service Единица пропускной способностиThroughput Measure Требование ко времени ответаResponse Time Requirement
PremiumPremium Транзакций в секундуTransactions per second 95-й процентиль при 0,5 секунды95th percentile at 0.5 seconds
StandardStandard Транзакций в минутуTransactions per minute 90-й процентиль при 1,0 секунде90th percentile at 1.0 seconds
BasicBasic Транзакций в часTransactions per hour 80-й процентиль при 2,0 секундах80th percentile at 2.0 seconds

Дальнейшие действияNext steps