SQL Server 2014 自習書シリーズ （HTML 版）
「No.5 Microsoft Azure SQL Database 入門」

2.17　データ圧縮を利用する

Azure SQL Database は、SQL Server でお馴染みの「データ圧縮」機能も利用することができます。データ圧縮は、テーブル内のデータそのものを圧縮できる機能で、データを圧縮することによって、ディスクへの書き込み／読み取り量（I/O 数）を減らすことができるので、性能向上を実現できる機能です。ただし、圧縮を行う分、CPU パワーを余分に消費することになるので、それとのトレードオフになります。

データ圧縮は、SQL Server と同様、次のように設定することができます。

ALTER INDEX ステートメントでインデックスを再構築（REBUILD）するときに、WITH 句で DATA_COMPRESSION を指定することで、データ圧縮を行うことができます。データ圧縮には、「行圧縮」（Row Compression）と「ページ圧縮」（Page Compression）の２種類があり、DATA_COMPRESSION で ROW を指定した場合が行圧縮、PAGE を指定した場合がページ圧縮、NONE を指定した場合が非圧縮（圧縮なし）になります。

◆ 行圧縮の内部動作

行圧縮では、次のように、固定長データ型の利用していない領域を削る（可変長データ型のように扱う）ことで、データを圧縮しています。

int データ型は、4バイトの固定長データ型ですが、「99」のように 0～255の間の整数を格納する場合には、1バイトの使用領域で済むので、残りの 3バイトを圧縮することができます。また、「8888」のように -32,768～32,767 の間の整数である場合は、2バイトの使用領域で済むので、残りの 2バイトを圧縮することができます。

char／nchar などの固定長文字列のデータ型の場合は、末尾に余分な空白がある場合に、そこを圧縮することができます。

◆ ページ圧縮の内部動作

ページ圧縮は、行圧縮よりもさらに圧縮ができる（サイズを小さくすることができる）機能です。ページ圧縮では、行圧縮を行った後に、さらにページ単位での圧縮を行うことで、サイズを小さくすることができます。具体的には、次のようにページ内での重複部分を圧縮（プレフィックスを圧縮）しています。

ただし、ページ圧縮では、より高度な圧縮をかけるので、CPU のオーバーヘッドが行圧縮よりも上がってしまうというデメリットがあります。

◆ データ圧縮の試し方

データ圧縮は、次のように試すことができます。

このように、ALTER INDEX ステートメントを利用して、インデックスを再構築（REBUILD）するときに、DATA_COMPRESSION を指定することで、データ圧縮を行うことができま（ROW を指定すれば行圧縮になります）。

圧縮したものを、元に戻したい場合は、次のように NONE を指定するようにします。

◆ 弊社事例 ～4億件のデータ～

次のグラフは、筆者のお客様のデータベース（4億件のデータ）を、Azure SQL Database 上に配置して、データ圧縮（行圧縮、ページ圧縮）を行った場合の結果です。

通常テーブル（圧縮なし）が 8.2GBであるところを、行圧縮では 6.5GB（約20.1％）、ページ圧縮では 4.46GB（約45.4％、半分近いサイズ）に圧縮することができています。このお客様のデータは、普段から tinyint や snallint などの小さいデータ型を活用されているので、行圧縮ではあまり圧縮ができていませんが、int や bigint などの大きいデータ型を利用している環境であれば、行圧縮でも30％ぐらいの圧縮をすることができます。

また、このときのクエリの実行時間は、次のようになりました（S3 プレビュー版で計測）。

クエリ１ では、行圧縮で 2.4倍の性能向上、ページ圧縮では 1.9倍の性能向上を実現することができたものの、クエリ２ では、行圧縮で 28％の性能ダウン、ページ圧縮では 54.2％の性能ダウンとなりました。データ圧縮では、速くなるクエリがある反面、CPU 利用のオーバーヘッドによって、遅くなるクエリも出てくるので、実際のクエリで検証を行うことが非常に重要になります。また、より利用頻度の高いクエリ（重要なクエリ）のスピードに注目するようにして、データ圧縮を利用すべきかどうかを検討してみてください（使いどころをうまく選択すれば、データ圧縮は非常に大きな効果を得ることができるので、ぜひ活用してみてください）。

なお、データ圧縮については、SQL Server 2014 の自習書シリーズの「SQL Server 2005 ユーザーのための SQL Server 2014」編でも詳しく説明しているので、こちらもぜひご覧いただければと思います。

◆ Premium エディションへの変更や、列ストア インデックスを利用した場合

クエリの性能を向上させたい場合には、上位のエディションを利用するという方法もあります。前述の事例グラフは、Standard エディションの S3（プレビュー版）で、データ圧縮を利用して性能を向上させる例でしたが、これを Premium エディションに変更したり、Premium エディションでサポートされる「インメモリの列ストア インデックス」を利用したりすることで、次のように性能を向上させることができます。

Premium エディションの P1 に変更することで 2.9倍、P2 で 5.7倍、P3 なら 23.5倍もの性能向上を実現することができます。Premium エディションでは、高速ストレージの利用や、並列クエリがサポートされていることによって、Standard エディションよりも良い性能でクエリを実行することができます。また、列ストア インデックスに関しては、この後詳しく説明しますが、これを利用すると、集計関連のクエリで驚異的な性能向上を実現することができます（グラフのようにクエリ１ では 184.5倍もの性能向上）。

データ圧縮では性能が向上しなかった、前述の「クエリ２」でも、Premium エディションや列ストア インデックスを利用すれば、次のように性能向上を実現することができます。

Premium エディションの P1 への変更では、性能向上はありませんでしたが、P2 に変更することで 1.8倍、P3 なら 6.7倍もの性能向上を確認することができました。また、インメモリの列ストア インデックスを利用すれば、172.6倍もの性能向上を実現できることも確認できました。

◆ インメモリの列ストア インデックスによる性能効果

列ストア インデックスは、Premium エディションでのみ利用できる機能なので、P3 だけでなく、P1 や P2 でも利用することができます。P1 や P2 で利用したときの結果は、次のとおりです（クエリ１ とクエリ２ は、前述のクエリと同じものです）。

このように、列ストア インデックスを利用すれば、20倍以上の性能向上を簡単に実現することができます。列ストア インデックスの作成方法や、どういった場面で利用するのかについては、次の項で説明します。