目次
DWUをスケールアップしてもDBの真の実力を発揮していない！ リソースクラスも変更する必要がある
Microsoft Azure SQL Data Warehouse(以下、SQL DW)は、SQL Data Warehouseユニット(通称、DWU)をスケールアップすることで手軽に処理性能を上げることができます。(参考：すばやい一時停止とパフォーマンス変更でコストを削減できる) しかし、DWUだけをスケールアップしただけでは、SQL DWの性能を完全に引き出せていない場合があります。今回は、DWUの説明を行ってから「リソースクラス」の変更方法について説明したいと思います。
なお、今回の記事は、「Microsoft｜SQL Data Warehouse での同時実行とワークロード管理」を参考に作成しています。合わせて読んでいただくことで理解が深まると思います。
DWUが上がると同時実行スロット最大数とメモリが増える
SQL DWの最も簡単なパフォーマンスを上げる方法として、DWUをスケールアップする方法があります。前回、行った調査では、100DWUから500DWUにスケールアップを行った結果、4分の1の時間で処理できるようなりました。
しかし、DWUを変えることで、単純な処理性能が変更されるだけではなく、ログインDBユーザーあたりの「同時実行スロット最大数」と「メモリ」も下記の表のように変更されています。これから、表の各要素について解説したいと思います。
同時実行スロット数とは
ご存知の通り、DBの「クエリ」は、SQL文などのDBへの命令の事です。では、「スロット」はSQL DWの何を意味しているのでしょうか？
SQL DWは、1つのクエリをSQL DWで解釈した結果、1つ以上のスロットで並行処理されます。つまり、スロット数が多ければ、並列処理に対応したクエリの処理速度を上げることができます。
スロットを並行処理できるクエリ(SQL命令)は、SELECT文、INSERT-SELECT文、UPDATE文などの使用頻度の多いクエリがあり、クエリ命令の負荷などによって同時実行されるクエリ数が決められます。また、INSERT VALUES文は、スロットを並行処理に対応していないため、大量データの登録は、PolyBaseなどを使う事をお勧めします。（参考：PolyBaseを使ったAzure SQL DWへの高速インポート）
メモリが少ないと大量データの抽出・編集でフリーズする
ユーザーごとのメモリの割り当ては、そのユーザーが使えるデータ編集領域の大きさです。例えば、大量データが登録されているテーブルから情報を取得し、データ項目のデータ型変換や文字列編集を行う場合、そのデータを格納できるメモリが必要になります。(実際にどれだけのメモリが必要になるかは、不明です) もし、メモリが足りない場合は、実行したクエリがフリーズし、処理結果が返ってこなくなります。そのため、大量データを扱う上で、メモリは非常に重要な要素になります。
DBユーザーの標準リソースクラスは「smallrc」になっている
今までの説明で同時実行スロット最大数とメモリが、大量データを扱う上で重要な要素であることが分かって頂けたと思います。しかし、単純にDWUをスケールアップだけでは、この2つの要素を変えることは出来ません。なぜなら、DBユーザーごとに「リソースクラス」という利用権限のようなものがあり、DBユーザーの標準では「smallrc」が割り当てられているためです。そのため、DWUをスケールアップしても、DBユーザーの同時実行スロット最大数は1本、割り当てられるメモリは100MBのままで変わりません。
そのため、DWUをスケールアップするなら、DBユーザーのリソースクラスも変える必要があるのです。
DBユーザーを新規作成してリソースクラスを変える
AzureポータルからSQL DWの作成時、管理用として1つのDBユーザーが作成されます。リソースクラスを変更するためには、この管理用のDBユーザとは別に利用者用のDBユーザーを新規作成して、そのDBユーザーに対してリソースクラスの変更を行う必要があります。
最初に管理者用のDBユーザーを使って、masterデータベースにログインします。masterデータベースとは、AzureポータルからSQL DBを構築した際に、入力したDB名とは別に自動的に作られるDBです。(JDBCでmasterデータベースにログインするためには、通常の接続文字列のdatabaseパラメタを「master」に変更してください)
masterデータベースにログインし、下記のSQL文を実行します。
|
1 2 3 4 5 |
--DBユーザー(db_test)を作成 CREATE LOGIN db_test WITH PASSWORD = 'PassWord1'; --masterデータベースにDBユーザー(db_test)を追加 CREATE USER db_test for LOGIN db_test; |
次に通常のDBにログインし、下記のSQL文を実行します。
|
1 2 3 4 5 6 7 8 |
--通常のDBにDBユーザー(db_test)を追加 CREATE USER db_test for LOGIN db_test; --DBユーザー(db_test)にuser_dbデータベースのCONTROL権限を付与 GRANT CONTROL ON DATABASE::user_db to db_test; --DBユーザー(db_test)にlargercリソースクラスのロールを追加する EXEC sp_addrolemember 'largerc', 'db_test'; |
全てのSQL文を実行すると作成したDBユーザーでDB接続できるようになります。(JDBCで作成したDBユーザーでログインするためには、通常の接続文字列のuserパラメタの@の前を変更してください)
実際に作成したDBユーザーでの動作確認を行うためには、Azureポータルの「クエリの詳細」から行えます。下記の例は、400DWUの動作環境を使用して、db_testユーザー(リソースクラス：largerc)で高負荷のSQL命令を実行した結果です。リソースクラスに「largerc」が表示され、同時実行スロットには400DWUのlargercリソースクラスの最大数の「8」が表示されています。(クエリの詳細の表示方法は、SQL DWのクエリアクティビティのグラフをクリックし、表示されたクエリ一覧からクエリIDをクリックすることで表示されます)
利用者の人数を考えて、最適なリソースクラスを設定する
上記の説明でDWUに合わせてリソースクラスも変更すれば SQL DWの本当の性能を引き出せる事を理解して頂けたと思います。しかし、リソースクラスを上げることは、同時に実行できるクエリ数を減らしている事になります。
同時に実行できるクエリ最大数は、DWUに関係なく32本までです。しかし、実際に実行処理を行っているスロットに空きがなければ、それ以上のクエリは実行待ち状態になります。例えば、400DWUの場合、同時実行スロット最大値は16本です。ここにlargercリソースクラスのDBユーザーが2本の高負荷のクエリを実行した場合、「8本(largercの同時実行スロット最大値) × 2本(クエリ数) ＝ 16本(使用スロット数)」で全てのスロットを占有してしまい、他のクエリを実行することができなくなります。
このように、クエリの処理速度だけではなく、対象のDBの利用者の人数を考慮してリソースクラスを設定する必要があります。また、400DWU以下の場合、xlargercリソースクラスは設定しない事をお勧めします。なぜなら、高負荷のクエリを誤って実行した後に、このクエリ中断命令を実行したい場合、空きのスロットがなくなっているためクエリ中断命令を実行できない事があるためです。
