1. ロード処理の性能
様々なソースから提供された大量のデータを、速やかに分析可能な状態するため、データ・アナリティクスの環境では、高速にデータ・ロードを行えることが、とても重要です。
DB2は、データベースの外部にあるデータを表に格納するため、LOADという高速ユーティリティを提供しています。DB2のLOADユーティリティは、入力データを1行ずつ読んでSQL INSERTの実行によってデータを格納するのではなく、表や索引ページの形式にデータをフォーマットして、直接データベースに高速に書き込みます。
カラム・オーガナイズ表に対しても、従来からのLOADユーティリティをそのままの構文で実行することができます。では、カラム・オーガナイズ表へのロード処理と、従来型の行オーガナイズ表へのロード処理の性能を比べてみましょう。
索引不要のカラム・オーガナイズ表はロードも速い
図１は、第２回でもご紹介したStar Schema Benchmark *1で定義されているファクト表 LINEORDER表を、行オーガナイズ表とカラム・オーガナイズ表として同じデータベース環境に定義し、それぞれに6億件のデータをロードしたときの処理時間を示したものです。
グラフでは、行オーガナイズ表とカラム・オーガナイズ表へのロード時間が、行オーガナイズ表のときの処理時間を100とした相対値として示されています。（少ない方が速い）
*1 Star Schema Benchmark： スタースキーマ構造のデータウェアハウスにおける性能評価のために、TPC-Hをベースに作られたベンチマークのひとつ。
http://www.tpc.org/tpctc/tpctc2009/tpctc200917.pdf[http://www.tpc.org/tpctc/tpctc2009/tpctc2009-17.pdf
http://www.cs.umb.edu/~poneil/StarSchemaB.PDF
この例では、カラム・オーガナイズ表へのロード時間は、行オーガナイズ表の70%程度の時間で完了しました。
ここで注目して頂きたいのは、それぞれのロード時間の内訳です。 表オーガナイズ表では、全体の64％の時間をLoadフェーズが占め、残りの36％をBuildフェーズが占めています。
Loadフェーズとは、入力データをデータページの形式にフォーマットして書き込むフェーズです。このフェーズが終わると、Loadユーティリティは、次に索引構築を行います。 これがBuildフェーズです。この例では2つの索引が定義されていました*2。 索引の定義数やそのキー長が大きくなれば、このBuildフェーズはもっと長くなりますから、定義された索引によっては、行オーガナイズ表とカラム・オーガナイズ表のロード時間の差は、さらに拡がります。一方、カラム・オーガナイズ表には、索引が定義されていませんので、Buildフェーズが一瞬で完了しています*3 。このBuildフェーズ時間の差があるため、様々な表で比較してみると、多くのケースで、行オーガナイズ表よりもカラム・オーガナイズ表の方が、より短いロード時間となります。
*2 このときLINEORDER表には、2つの索引が定義されていました。この索引は当シリーズの第2回「BLUアクセラレーションのルーツを探る」で記述したように、Star Schema Benchmarkが定める13個のクエリーを入力に、DB2の索引アドバイザーが推奨したものです。
*3 このケースではカラム・オーガナイズ表には索引はひとつも定義されていませんでしたが、各カラム・オーガナイズ表には、内部のメタデータ管理のための索引がありますので、短時間ですがBUILDフェーズが発生します。
また、カラム・オーガナイズ表へのデータの初期投入の場合、LOADユーティリティは表の統計情報収集を自動的に併せて行いますので、ロード完了後の統計情報収集（RUNSTATSコマンド）が不要です。ですから、表を作ってSQLによる解析の準備が完了するまでの時間、つまりロードだけでなく統計情報収集の時間までを含めて、カラム・オーガナイズ表と行オーガナイズ表を比較すると、一層カラム・オーガナイズ表が有利な結果となります。
カラム・オーガナイズ表へのロード時に発生するAnalyzeフェーズ
図１を見て気づかれたことと思いますが、カラム・オーガナイズ表へのロードには、行オーガナイズ表には無い、Analyzeフェーズがあります。 これは入力ファイルをチェックして列毎に最適な圧縮辞書を構築するフェーズです。データの初期投入の場合には、LOADユーティリティは、Analyzeフェーズによって入力ファイルをチェックして列毎に圧縮辞書をつくり、それからLoadフェーズに移って、入力データの圧縮を実際に行いながらデータ・ロードを実施します。一旦データの入ったカラム・オーガナイズ表への追加ロードの場合には、既にある辞書を使って圧縮しますので、Analyzeフェーズはありません。
カラム・オーガナイズ表の高い圧縮効果
図３を見てください。 行オーガナイズ表とカラム・オーガナイズ表へのデータ・ロードが完了してから、それぞれの表で消費されたディスク領域の大きさを示しています。グラフでは、行オーガナイズ表のデータページと索引ページが消費したトータルのディスク領域を100として、行オーガナイズ表と列オーガナイズ表の相対値を示しています。
この例では、行オーガナイズ表に比べて、14%のストレージ容量で済みました。 このシリーズの第3回「BLUアクセラレーション高速処理のひみつ」でご紹介したように、カラム・オーガナイズ表は、列ごとに持っている圧縮辞書によって効率の良い圧縮を行います。 このことが、この高い圧縮率の理由であることはもちろんですが、索引領域のスペースの差も、ディスク消費量圧縮に貢献しています。
今回のテストで利用した行オーガナイズ表には、２つの索引が定義されていましたが、皆さんが実際に業務システムで利用されている表では、クエリー性能の最適化のために、より多くの索引が定義されているケースも珍しくないと思います。 そのような環境で比較すると、カラム・オーガナイズ表の採用によるストレージ削減の効果は、より一層高くなることでしょう。
