この投稿は、Windows Azure アドベントカレンダー の 3/12 の投稿です。
先日の投稿で、SQL Database で行/ページ圧縮が利用可能になったようです を書きました。
この圧縮が性能にどのような影響を与えるかを単純な処理を例に見ていきたいと思います。
使用するテーブルは前回のものと同じです。
IF OBJECT_ID('dbo.sample_table', 'U') IS NOT NULL
DROP TABLE dbo.sample_table
GO
CREATE TABLE dbo.sample_table
(
c1 int NOT NULL,
c2 char(10) NULL,
c3 datetime NULL,
CONSTRAINT PK_sample_table PRIMARY KEY (c1)
)
GO
IF OBJECT_ID('dbo.sample_table_page', 'U') IS NOT NULL
DROP TABLE dbo.sample_table_page
GO
CREATE TABLE dbo.sample_table_page
(
c1 int NOT NULL,
c2 char(10) NULL,
c3 datetime NULL,
CONSTRAINT PK_sample_table_page PRIMARY KEY (c1) WITH (DATA_COMPRESSION=PAGE)
)
GO
標準のテーブルとページ圧縮したテーブルを用意しています。
このテーブルに対して以下のようなクエリで 5 万件のデータを挿入してみます。
SET NOCOUNT ON GO DECLARE @i int = 1 WHILE (@i <= 50000) BEGIN INSERT INTO sample_table VALUES(@i, @i, GETDATE()) SET @i += 1 END GO
この時に発生した待ち事象を整理したものが以下の表示なります。
この表は INSERT をした際の待ち事象で代表的なものをピックアップしたものになります。
実行タイミングによって結果にばらつきがないことを確認するために複数回実行してトレンドを取得しています。
発生していた待ち事象としては、
- SE_REPL_COMMIT_ACK : SQL Database の冗長化のための応答待ち
- SOS_SCHEDULER_YIELD : スケジューラーの譲渡待ち
- WRITELOG : ログ書き込み
になりますが、標準テーブルとページ圧縮時のテーブルでは、ほぼ同等の値を示していることが確認できます。
圧縮されたページは CDA (:Compression Data Array) という形式で格納されるのですが、単純な INSERT では処理の傾向は変わらないようでした。
# 固定長データサイズが多いと多少変わってくる可能性がありますが。
このテーブルを以下のクエリで再構築して、検索の性能を見てみたいと思います。
ALTER TABLE sample_table REBUILD ALTER TABLE sample_table_page REBUILD
SQL Database では DBCC によるキャッシュのクリアができないため、今回はキャッシュから読んだ際のページ数の比較となります。
SET NOCOUNT ON SET STATISTICS IO ON GO SELECT COUNT(*) FROM sample_table GO SELECT COUNT(*) FROM sample_table_page GO
この際の読み取りページ数が以下になります。
| Table ‘sample_table’. Scan count 1, logical reads 194, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘sample_table_page’. Scan count 1, logical reads 93, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. |
上が、標準テーブル / 下が、ページ圧縮されたテーブルになりますが、圧縮することでページ数が減りますので、全件検索をした際のページ読み取り数に差が出て、圧縮されたテーブルの方が I/O コストが低くなります。
# 圧縮をすることで、CPU コストは上がりますので、データ件数やキャッシュ状況によってはトータルの処理時間では差がない (逆にオーバーヘッドになる) こともありますが。
更新系に関しても軽くテストはしたところ、処理時間に大きな差はなさそうでした。
ページ圧縮の特徴としては、
- 圧縮によるページサイズの縮小 (DB サイズの縮小とデータベースページキャッシュの縮小)
- 圧縮データ読み込み時の I/O コストの低下
- 圧縮データ読み込み時の CPU コストの増加
というような定番の内容が性能トレンドとしては出てきそうですね。
SQL Database では、現状、データベースの最大サイズが 150GB となっていますので、データ圧縮を使用することで、最大サイズへ達する可能性を緩和させることが可能となりますので、この辺の緩和策としても使用していくと良いかもしれないですね。
# Compression Data Array (CDA) での格納となりますので、サイズを見積もるのは実際には難しいのですが。
