DTU ベンチマーク

適用対象:Azure SQL データベース

データベース トランザクション ユニット (DTU) は、CPU、メモリ、読み取り、書き込みを組み合わせた測定値を表す測定単位です。 DTU の各測定に関連付けられている物理的な特性 (CPU、メモリ、IO) は、実際のデータベース ワークロードをシミュレートするベンチマークを使用して較正されます。 この記事では、DTU ベンチマークの概要を示し、スキーマ、使用されるトランザクションの種類、ワークロード ミックス、ユーザーとペーシング、スケーリング ルール、およびベンチマークに関連付けられているメトリックに関する情報を共有します。

DTU ベースの購入モデルの一般情報については、「DTU ベースの購入モデルの概要」を参照してください。

ベンチマークの概要

この DTU ベンチマークでは、オンライン トランザクション処理 (OLTP) ワークロードで最も頻繁に発生する、混在した基本的なデータベース操作のパフォーマンスを測定します。 ベンチマークはクラウド コンピューティングを考慮して設計されていますが、データベース スキーマ、データの設定、およびトランザクションは、OLTP ワークロードでよく使用される基本的な要素を広く表すように設計されています。

実際のデータベース パフォーマンスへのベンチマーク結果の関連付け

すべてのベンチマークは単なる典型値であり、指標である点を理解しておくことが重要です。 ベンチマーク アプリケーションで達成されるトランザクション率は、他のアプリケーションで達成されるトランザクション率と同じにはなりません。 ベンチマークは、さまざまなテーブルやデータの種類を含むスキーマに対して実行されるさまざまなトランザクションの種類のコレクションで構成されます。 ベンチマークではすべての OLTP ワークロードに共通する同じ基本操作を実行しますが、特定のクラスのデータベースまたはアプリケーションを表すものではありません。 このベンチマークの目的は、コンピューティング サイズをスケール アップまたはスケール ダウンしたときに予想されるデータベースの相対的なパフォーマンスの適切なガイドを提供することです。

実際には、データベースのサイズと複雑さはさまざまであり、さまざまなワークロードが発生するため、対応方法も変わります。 たとえば、IO の利用が多いアプリケーションでは IO しきい値に達するまでの時間が短くなったり、CPU の使用量が多いアプリケーションでは CPU の上限に達するまでの時間が短くなったりすることがあります。 負荷が増えている状況で、特定のデータベースがベンチマークと同様に拡張する保証はありません。

この記事では、ベンチマークとその手法についてさらに詳しく説明します。

スキーマ

スキーマは、広範な操作をサポートするのに十分な多様さと複雑さを備えるように設計されています。 ベンチマークは、6 個のテーブルで構成されるデータベースに対して実行されます。 テーブルは、固定サイズ、スケーリング、拡大という 3 つのカテゴリに分類されます。 2 個の固定サイズ テーブル、3 個のスケーリング テーブル、1 個の拡大テーブルがあります。 固定サイズ テーブルには一定の数の行が含まれます。 スケーリング テーブルにはデータベースのパフォーマンスに比例するカーディナリティがありますが、ベンチマークの途中で変化することはありません。 拡大テーブルのサイズは初期状態の負荷ではスケーリング テーブルと同じように設定されますが、ベンチマークの実行中に行が挿入および削除されることによってカーディナリティが変化します。

スキーマには、整数、数値、文字、日時など、さまざまなデータ型が含まれています。 スキーマにはプライマリ キーとセカンダリ キーが含まれますが、外部キーは含まれません。つまり、テーブルの間に参照整合性制約はありません。

データ生成プログラムによって、初期データベースのデータが生成されます。 さまざまな方法で整数データと数値データが生成されます。 場合によっては、値はある範囲にランダムに分散されます。 それ以外の場合は、値のセットの順序がランダムに変更されて、一定の分散が維持されます。 テキスト フィールドは単語の重み付けされたリストから生成され、現実に近いデータが作成されます。

データベースのサイズは "倍率" に基づいて設定されます。 スケール係数 (SF と略記) により、スケーリング テーブルと拡大テーブルのカーディナリティが決まります。 「ユーザーとペーシング」で後述するように、データベース サイズ、ユーザー数、最大パフォーマンスはすべて、相互に比例して拡大します。

トランザクション

ワークロードは、次の表で示すように、9 種類のトランザクションで構成されます。 各トランザクションは、データベース エンジンおよびシステム ハードウェアの特定のシステム特性セットが強調され、他のトランザクションとの違いがはっきりわかるように設計されています。 この方法では、異なるコンポーネントのパフォーマンス全体に対する影響を簡単に評価できます。 たとえば、トランザクション "読み取り (高負荷)" では、ディスクからの読み取り操作が大量に生成されます。

トランザクションの種類 説明
読み取り (低負荷) SELECT、メモリ内、読み取りのみ
読み取り (中負荷) SELECT、ほぼメモリ内、読み取りのみ
読み取り (高負荷) SELECT、ほぼメモリ外、読み取りのみ
更新 (低負荷) UPDATE、メモリ内、読み書き
更新 (高負荷) UPDATE、ほぼメモリ外、読み書き
挿入 (低負荷) INSERT、メモリ内、読み書き
挿入 (高負荷) INSERT、ほぼメモリ外、読み書き
削除 DELETE、メモリ内とメモリ外の混合、読み書き
CPU (高負荷) SELECT、メモリ内、比較的大きい CPU 負荷、読み取りのみ

ワークロード ミックス

トランザクションは、次の表のような全体的混合比率で重み付けされた分布からランダムに選択されます。 全体として読み取り/書き込みの比率は約 2:1 になります。

トランザクションの種類 混合の割合
読み取り (低負荷) 35
読み取り (中負荷) 20
読み取り (高負荷) 5
更新 (低負荷) 20
更新 (高負荷) 3
挿入 (低負荷) 3
挿入 (高負荷) 2
削除 2
CPU (高負荷) 10

ユーザーとペーシング

ベンチマークのワークロードは、一連の接続に対してトランザクションを発行して一定数の同時ユーザーの動作をシミュレートするツールによってもたらされます。 すべての接続とトランザクションはコンピューターによって生成されますが、わかりやすくするため、ここではこれらの接続のことを "ユーザー" と呼びます。 各ユーザーは他のすべてのユーザーとは独立して動作しますが、すべてのユーザーは以下に示すような同じ手順のサイクルを実行します。

  1. データベース接続を確立します。
  2. 終了を通知されるまで繰り返します:
    • ランダムにトランザクションを選択します (重み付けされた分布から)。
    • 選択されたトランザクションを実行して応答時間を測定します。
    • ペーシング遅延だけ待機します。
  3. データベース接続を閉じます。
  4. 終了します。

ペーシング遅延 (手順 2c) はランダムに選択されますが、分布の平均は 1.0 秒になります。 したがって、平均すると、各ユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。

スケーリング ルール

ユーザーの数は、データベースのサイズ (スケール係数単位での) によって決まります。 5 スケール係数単位ごとに 1 人のユーザーがいます。 ペーシング遅延のため、平均すると、1 人のユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。

たとえば、スケール係数が 500 (SF=500) のデータベースの場合、ユーザー数は 100 で、最高 100 TPS を実現できます。 TPS 率を高くするには、ユーザー数を増やし、データベースを大きくする必要があります。

測定期間

有効なベンチマーク実行のためには、少なくとも 1 時間は安定状態で測定を行う必要があります。

メトリック

ベンチマークでの重要なメトリックは、スループットと応答時間です。

  • スループットはベンチマークにおける基本的なパフォーマンス尺度です。 スループットは、単位時間あたりのすべてのトランザクション タイプのトランザクション数で表されます。
  • 応答時間は、パフォーマンスの予測可能性の尺度です。 応答時間の制約はサービスのクラスによって異なり、次に示すように、サービス クラスが高いほど応答時間の要件は厳しくなります。
サービスのクラス スループットの測定 応答時間の要件
Premium 1 秒あたりのトランザクション数 0.5 秒で第 95 百分位数
Standard 1 分あたりのトランザクション数 1.0 秒で第 90 百分位数
Basic 1 時間あたりのトランザクション数 2.0 秒で第 80 百分位数

注意

応答時間のメトリックは、DTU ベンチマークに固有のものです。 その他のワークロードの応答時間は、ワークロードによって異なります。

次のステップ

購入モデルと、関連する概念の詳細については、次の記事を参照してください。