先日、SQL Database の新しいエディションの特性を調べてみる (2014/7 版) という投稿をしました。
結果のサマリーとしては以下のようになっています。
■INSERT
| 処理時間 | 前回 | 今回 |
| Business | 1:53 | 2:03 |
| Basic | 9:19 | 2:08 |
| Standard/S1 | 4:35 | 1:56 |
| Standard/S2 | 3:03 | 1:58 |
■SELECT
| 前回 | 今回 | |||
| 処理時間 | エラー数 | 処理時間 | エラー数 | |
| Business | 00:07.3908 | 0 | 00:06.8152 | 0 |
| Basic | 01:57.4251 | 883 | 02:16.9123 | 0 |
| S1 | 02:28.5198 | 0 | 00:46.5336 | 0 |
| S2 | 00:27.2976 | 0 | 00:13.8427 | 0 |
| P1 | 00:08.8606 | 0 | ||
| P2 | 00:07.2884 | 0 | ||
INSERT については差がなく、SELECT については S2 を使用することで、現状の Business に近い処理時間にすることはできました。
以下は SQL Database の料金になります。
現状の SQL Database は DTU が設定されていないため、性能については一定の性能が保障されるわけではなくデータベースの使用量に応じて課金がされます。
新しいパフォーマンスレベルについては、現状はプレビュー料金のため 50% のプレビュー割引きとなっていますが、データベースのコストを抑えるためには S1 の利用が基本になってくるかなと思います。
S1 のスループットを現状のエディションに近づけるためにはどうすればよいかをメモとして。
INSERT の処理時間は同じだったため、本投稿では SELECT をターゲットとして検証しています。
INSERT も複数スレッドで実行した場合はトレンドが変わってくるはずなので、厳密には検証する必要があります。
データベースのアクセスを効率よく実行するためには、SQL Database のページ圧縮の機能を使用するのが現実的なのかなと思いました。
# Azure SQL DB to support page and row compression capabilities
今回は以下のようなテーブルのスキーマを使用しています。
CREATE TABLE Table_1
(
c1 uniqueidentifier,
c2 char(1000),
CONSTRAINT PK_Table_1 PRIMARY KEY (c1)
)
GO
これを以下のように WITH (DATACOMPRESSION=PAGE) を使用してページ圧縮をすることでchar 型の列の圧縮とページの圧縮が行われます。
CREATE TABLE Table_1
(
c1 uniqueidentifier,
c2 char(1000),
CONSTRAINT PK_Table_1 PRIMARY KEY (c1) WITH (DATA_COMPRESSION=PAGE)
)
GO
以下がページ圧縮をしなかった場合の処理時間になります。
ページ圧縮をした場合は以下になります。
ページ圧縮をすることで、データの格納効率が向上し、論理 (または物理) 読み取り数が減るため、処理時間が短くなっています。
S2 の場合は以下のようになります。
# 左 : 未圧縮 / 右 : ページ圧縮
圧縮をすることで、現状の Business 相当になっていますね。
ちなみに Business で圧縮した結果が以下になります。
# 左 : 未圧縮 / 右 : ページ圧縮
Basic の場合は以下になります。
# 左 : 未圧縮 / 右 : ページ圧縮
現状のエディションはパフォーマンスが保障されているわけではないので、性能にばらつきがあるかとは思いますが、新しいパフォーマンスレベルで低価格で現状のエディションに近づけるためには、データ圧縮により、I/O の効率化をすることで性能を向上させるのは効果がありそうですので、データ圧縮は検討材料の一つとなるのかと。