SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

一括インポート時のデータ圧縮の影響

leave a comment

BULK INSERT のような一括インポートをする際のデータ圧縮による処理性能への影響の考え方について少しまとめてみたいと思います。

技術文書としては以下の文書が参考になります。
データ圧縮:キャパシティ プランニングとベスト プラクティス
データ ローディング パフォーマンス ガイド

■一括インポート時のデータ圧縮の影響


トレースフラグ 610 を使わない場合、高速データロードを実行するために、ヒープテーブルに対してデータを挿入することが多いかと思います。

SQL Server のデータ圧縮はインデックスのないヒープ構造でも設定することができます。

ALTER TABLE [dbo].[Compress] REBUILD
WITH
(DATA_COMPRESSION = PAGE)

ヒープを使用していて圧縮を行った場合もサイズを削減する効果が見られます。

image

サイズが減る = データ書き込みが減るということにつながると思いますが、データ圧縮の設定をすることにより、一括インポートの処理時間が伸びることがあります。

SQL Server のデータ圧縮はメモリ上でもデータが圧縮された状態となります。
そのため、メモリにデータを格納している状態でもメモリ上でのデータ操作時には圧縮によるオーバーヘッド (データ格納時の圧縮操作/データ読み込み時の圧縮解除) が発生してきます。

SQL Server のデータ書き込み時はログの先行書き込み + メモリ上のデータ変更が基本となります。
メモリ上のデータに対しても圧縮の処理が行われますので、データ挿入時にはこの圧縮の処理による CPU 負荷が設定しない場合と比較して高くなってきます。

そのため単純なデータ挿入時の処理実行時間だけを考えると
– データ圧縮をしていないヒープ < データ圧縮をしているヒープ
となることがあります。

通常ヒープのまま使用するというのは少ないと思いますので、データ挿入後にクラスター化インデックスを作成するかと思います。
ヒープで圧縮されているテーブルに対して

CREATE CLUSTERED INDEX IX_Compress ON dbo.Compress
    (Col1)

というような形でクラスター化インデックスを付与した場合、クラスター化インデックスは圧縮された状態となっています。

この時、気にしておきたいのが

– データ圧縮をしたヒープテーブルにクラスター化インデックスを設定
– データ圧縮をしていないヒープテーブルにクラスター化インデックスを設定する際に圧縮を指定

のどちらが早いかという点です。

処理の時間としては

– データ圧縮をしたヒープにデータ挿入 + クラスター化インデックスを設定
– データ圧縮をしていないヒープにデータを挿入 + クラスター化インデックス設定時に圧縮を指定

でどちらが効率的かを調べていく必要が出てくると思います。
単純な結果だと後者のほうが処理時間が短い場合が多いかもしれませんね。

一括インポートをする場合、

– 初期のテーブルの状態
– テーブル作成後のインデックス付与

をどのようにすると効率が良いかを試しておくとよさそうですね。
データ圧縮はデータ挿入時の CPU 負荷とデータ読み込み時の CPU 負荷をディスク I/O と比較したトレードオフになってくるかと思いますので。

Written by masayuki.ozawa

10月 14th, 2012 at 11:31 pm

Posted in SQL Server

Tagged with

Leave a Reply

*