DTU ベースの購入モデルでのサービス レベルService tiers in the DTU-based purchase model

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 without downtime. 単一データベースとエラスティック プールは、サービス レベルとコンピューティング サイズに基づいて時間単位で課金されます。Single databases and elastic pools are billed hourly based on service tier and compute size.

重要

SQL Database Managed Instance は、DTU ベースの購入モデルをサポートしていません。SQL Database managed instance does not support a DTU-based purchasing model. 詳細については、Azure SQL Database Managed Instance に関するページを参照してください。For more information, see Azure SQL Database Managed Instance.

注意

仮想コアベースのサービス レベルの詳細については、仮想コアベースのサービス レベルに関するページを参照してください。For information about vCore-based service tiers, see vCore-based service tiers. DTU ベースのサービス レベルと仮想コアベースのサービス レベルの違いの詳細については、Azure SQL Database の購入モデルに関するページを参照してください。For information about differentiating DTU-based service tiers and vCore-based service tiers, see Azure SQL Database purchasing models.

DTU ベースのサービス レベルを比較するCompare the DTU-based service tiers

サービス レベルの選択は、主に、ビジネス継続性、ストレージ、およびパフォーマンスの要件に依存します。Choosing a service tier depends primarily on business continuity, storage, and performance requirements.

BasicBasic 標準Standard PremiumPremium
対象のワークロードTarget workload 開発、運用Development and production 開発、運用Development and production 開発、運用Development and production
アップタイム SLAUptime SLA 99.99%99.99% 99.99%99.99% 99.99%99.99%
バックアップ保有期間Backup retention 7 日7 days 35 日35 days 35 日35 days
CPUCPU Low 低、中、高Low, Medium, High 中、高Medium, High
IO スループット (概算)IO throughput (approximate) DTU あたり 2.5 IOPS2.5 IOPS per DTU DTU あたり 2.5 IOPS2.5 IOPS per DTU DTU あたり 48 IOPS48 IOPS per DTU
IO 待機時間 (概算)IO latency (approximate) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み)5 ms (read), 10 ms (write) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み)5 ms (read), 10 ms (write) 2 ミリ秒 (読み取り/書き込み)2 ms (read/write)
列ストア インデックス作成Columnstore indexing 該当なしN/A S3 以上S3 and above サポートされていますSupported
インメモリ OLTPIn-memory OLTP 該当なしN/A 該当なしN/A サポートされていますSupported

注意

Azure 無料アカウントと組み合わせて Basic サービス レベルで無料の Azure SQL データベースを取得して、Azure を探索できます。You can get a free 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.

Single Database の 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 標準Standard PremiumPremium
最大ストレージ サイズMaximum storage size 2 GB2 GB 1 TB (テラバイト)1 TB 4 TB4 TB
最大 DTUMaximum DTUs 55 30003000 40004000

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。Under some circumstances, you may need to shrink a database to reclaim unused space. 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。For more information, see Manage file space in Azure SQL Database.

エラスティック プールの eDTU、ストレージ、プールされたデータベースの上限Elastic pool eDTU, storage, and pooled database limits

BasicBasic StandardStandard PremiumPremium
データベースあたりの最大ストレージ サイズMaximum storage size per database 2 GB2 GB 1 TB (テラバイト)1 TB 1 TB (テラバイト)1 TB
プールあたりの最大ストレージ サイズMaximum storage size per pool 156 GB156 GB 4 TB4 TB 4 TB4 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 TB を超える Premium レベルのストレージは、中国東部、中国北部、ドイツ中部、ドイツ北東部、米国中西部、米国 DoD の各リージョンと、米国政府中部を除くすべてのリージョンで利用できます。More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, Germany Northeast, West Central US, US DoD regions, and US Government Central. これらのリージョンでは、Premium レベルのストレージの最大容量は 1 TB です。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. 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。For more information, see manage file space in Azure SQL Database.

DTU ベンチマークDTU Benchmark

DTU の各測定に関連付けられている物理的な特性 (CPU、メモリ、IO) は、実際のデータベース ワークロードをシミュレートするベンチマークを使用して較正されます。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. たとえば、IO の利用が多いアプリケーションでは IO しきい値に達するまでの時間が短くなったり、CPU の使用量が多いアプリケーションでは CPU の上限に達するまでの時間が短くなったりすることがあります。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. ベンチマークは、6 個のテーブルで構成されるデータベースに対して実行されます。The benchmark runs against a database comprised of six tables. テーブルは、固定サイズ、スケーリング、拡大という 3 つのカテゴリに分類されます。The tables fall into three categories: fixed-size, scaling, and growing. 2 個の固定サイズ テーブル、3 個のスケーリング テーブル、1 個の拡大テーブルがあります。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.

トランザクションTransactions

ワークロードは、次の表で示すように、9 種類のトランザクションで構成されます。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、メモリ内、読み取りのみSELECT; in-memory; read-only
読み取り (中負荷)Read Medium SELECT、ほぼメモリ内、読み取りのみSELECT; mostly in-memory; read-only
読み取り (高負荷)Read Heavy SELECT、ほぼメモリ外、読み取りのみSELECT; mostly not in-memory; read-only
更新 (低負荷)Update Lite UPDATE、メモリ内、読み書きUPDATE; in-memory; read-write
更新 (高負荷)Update Heavy UPDATE、ほぼメモリ外、読み書きUPDATE; mostly not in-memory; read-write
挿入 (低負荷)Insert Lite INSERT、メモリ内、読み書きINSERT; in-memory; read-write
挿入 (高負荷)Insert Heavy INSERT、ほぼメモリ外、読み書きINSERT; mostly not in-memory; read-write
削除Delete DELETE、メモリ内とメモリ外の混合、読み書きDELETE; mix of in-memory and not in-memory; read-write
CPU (高負荷)CPU Heavy SELECT、メモリ内、比較的大きい CPU 負荷、読み取りのみ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
削除Delete 22
CPU (高負荷)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.

ペーシング遅延 (手順 2c) はランダムに選択されますが、分布の平均は 1.0 秒になります。The pacing delay (in step 2c) is selected at random, but with a distribution that has an average of 1.0 second. したがって、平均すると、各ユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。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). 5 スケール係数単位ごとに 1 人のユーザーがいます。There is one user for every five scale-factor units. ペーシング遅延のため、平均すると、1 人のユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。Because of the pacing delay, one user can generate at most one transaction per second, on average.

たとえば、スケール係数が 500 (SF=500) のデータベースの場合、ユーザー数は 100 で、最高 100 TPS を実現できます。For example, a scale-factor of 500 (SF=500) database will have 100 users and can achieve a maximum rate of 100 TPS. TPS 率を高くするには、ユーザー数を増やし、データベースを大きくする必要があります。To drive a higher TPS rate requires more users and a larger database.

測定期間Measurement duration

有効なベンチマーク実行のためには、少なくとも 1 時間は安定状態で測定を行う必要があります。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 1 秒あたりのトランザクション数Transactions per second 0.5 秒で第 95 百分位数95th percentile at 0.5 seconds
StandardStandard 1 分あたりのトランザクション数Transactions per minute 1.0 秒で第 90 百分位数90th percentile at 1.0 seconds
基本Basic 1 時間あたりのトランザクション数Transactions per hour 2.0 秒で第 80 百分位数80th percentile at 2.0 seconds

次の手順Next steps