Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

クエリーだけじゃない!BLUアクセラレーションの恩恵

2013/11/01 00:00

みなさんこんにちは。日本アイ・ビー・エム システムズ・エンジニアリングの白井です。前回の「第3回「BLUアクセラレーション高速処理のひみつ」」に引き続き、BLUアクセラレーションの解説を担当します。よろしくお願い致します。前回は、BLUアクセラレーションの高速処理の秘密について、DB2内部に実装された各テクノロジーの解説をしました。何故BLUアクセラレーションでは、特別なチューニングを施すことなく安定したクエリー性能を確保できるのか、その秘密の一端をご理解頂けたことと思います。さて、BLUアクセラレーションの恩恵を得られるのは、クエリーだけではありません。 第4回目の今回は、ロードや削除など、クエリー以外の処理の特性について解説します。 また、実際にBLUを利用する場合のデータベースの構成手順についてもご紹介します。

1. ロード処理の性能

 様々なソースから提供された大量のデータを、速やかに分析可能な状態するため、データ・アナリティクスの環境では、高速にデータ・ロードを行えることが、とても重要です。

 DB2は、データベースの外部にあるデータを表に格納するため、LOADという高速ユーティリティを提供しています。DB2のLOADユーティリティは、入力データを1行ずつ読んでSQL INSERTの実行によってデータを格納するのではなく、表や索引ページの形式にデータをフォーマットして、直接データベースに高速に書き込みます。

 カラム・オーガナイズ表に対しても、従来からのLOADユーティリティをそのままの構文で実行することができます。では、カラム・オーガナイズ表へのロード処理と、従来型の行オーガナイズ表へのロード処理の性能を比べてみましょう。

索引不要のカラム・オーガナイズ表はロードも速い

 図1は、第2回でもご紹介した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

<<図1: LOADユーティリティの処理性能>>
<<図1: LOADユーティリティの処理性能>>

 この例では、カラム・オーガナイズ表へのロード時間は、行オーガナイズ表の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フェーズ

 図1を見て気づかれたことと思いますが、カラム・オーガナイズ表へのロードには、行オーガナイズ表には無い、Analyzeフェーズがあります。 これは入力ファイルをチェックして列毎に最適な圧縮辞書を構築するフェーズです。データの初期投入の場合には、LOADユーティリティは、Analyzeフェーズによって入力ファイルをチェックして列毎に圧縮辞書をつくり、それからLoadフェーズに移って、入力データの圧縮を実際に行いながらデータ・ロードを実施します。一旦データの入ったカラム・オーガナイズ表への追加ロードの場合には、既にある辞書を使って圧縮しますので、Analyzeフェーズはありません。

<<図2: カラム・オーガナイズ表におけるLOADユーティリティの各フェーズ>>
<<図2: カラム・オーガナイズ表におけるLOADユーティリティの各フェーズ>>

カラム・オーガナイズ表の高い圧縮効果

 図3を見てください。 行オーガナイズ表とカラム・オーガナイズ表へのデータ・ロードが完了してから、それぞれの表で消費されたディスク領域の大きさを示しています。グラフでは、行オーガナイズ表のデータページと索引ページが消費したトータルのディスク領域を100として、行オーガナイズ表と列オーガナイズ表の相対値を示しています。

<<図3: カラム・オーガナイズ表のデータ圧縮効果>>
<<図3: カラム・オーガナイズ表のデータ圧縮効果>>

 この例では、行オーガナイズ表に比べて、14%のストレージ容量で済みました。 このシリーズの第3回「BLUアクセラレーション高速処理のひみつ」でご紹介したように、カラム・オーガナイズ表は、列ごとに持っている圧縮辞書によって効率の良い圧縮を行います。 このことが、この高い圧縮率の理由であることはもちろんですが、索引領域のスペースの差も、ディスク消費量圧縮に貢献しています。

 今回のテストで利用した行オーガナイズ表には、2つの索引が定義されていましたが、皆さんが実際に業務システムで利用されている表では、クエリー性能の最適化のために、より多くの索引が定義されているケースも珍しくないと思います。 そのような環境で比較すると、カラム・オーガナイズ表の採用によるストレージ削減の効果は、より一層高くなることでしょう。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 白井 徹哉(シライ テツヤ)

    日本アイ・ビー・エム システムズ・エンジニアリング株式会社 コンサルティングITスペシャリスト   1992年日本IBM入社。 1995年からDB2の技術サポートを担当し、最新技術の紹介や、それらを活用した先進プロジェクトの支援を社内外で幅広く実施。 昨年の東京マラソン完走以...

バックナンバー

連載:徹底解説!IBM DB2 10.5
All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5