BLU - IBM

【A-2】
データベース・テクノロジー Part 2
「カラム型」が実現するビッグデータの高速処理
日本アイ・ビー・エム株式会社
ソフトウェア事業インフォメーション･マネジメント事業部
平野真弓
© 2013 IBM Corporation
ご説明内容
• DB2進化の歴史～より速く、止まらないDB
• DB2 10.5登場
• DB2 10.5 BLUアクセラレーション
– BLUアクセラレーションの特徴
– BLUアクセラレーションのキー・テクノロジー
– BLUアクセラレーションの効果
• 検証結果から見るDB2 10.5 BLUアクセラレーションの有用性
• Cognos Business Intelligence(Cognos BI)との連携デモンスト
レーション
• BLUアクセラレーションまとめ
© 2013 IBM Corporation
2
DB2の進化の歴史
～より速く、止まらないDB～
© 2013 IBM Corporation
3
DB2進化の歴史～より速く、止まらないDB
 大規模データの高速処理
 基幹システムを支える連続稼動性
・DBパーティショニング
・HADR
（Database Partitioning
Feature）
(High Availability Disaster
Recovery)
シェアード・ナッシング・
アーキテクチャーによる
大量データの並列処理
ログ・シッピングによる
高可用性と災害対策の
２つのソリューションを
実現
・マテリアライズ照会表
(Materialized Query Table)
時間のかかるクエリーの
結果を保管、実行クエリー
に応じてMQTから結果導出
・DB2 pureScale
・多次元クラスター表/パーティション表
(Multi Dimension Clustering/ Table partitioning)
同じ値を持つ行を同じブロック/
パーティションに保管し、データ・
アクセスを効率化
DB2 for z/OS データ共用の
アーキテクチャーを採用し、極CF
めて高い連続稼動性と拡張
性を実現
RDMA通信
DB2
DB2
DB2
ブロック
履歴表 A
1月
© 2013 IBM Corporation
2月
3月
4月
5月
4
DB2 10.5登場
© 2013 IBM Corporation
5
DB2 10.5登場
BLU アクセラレーション
アナリティクス処理を加速させるRDBの革命
• アナリティクス処理が従来よりも数十倍高速に
• 表にデータを投入するだけですぐに利用可能
• 索引チューニング不要
• 低コストで実装可能なハイブリッド・データベース
© 2013 IBM Corporation
DB2 pureScaleのさらなる進化
基幹業務を支えるため、連続稼動性と
性能をさらに強化
• オンライン・メンテナンス
• 災害対策ソリューション
• オンライン、バッチ双方の性能向上
6
DB2 10.5
BLUアクセラレーション
© 2013 IBM Corporation
7
アナリティクス処理の性能最適化におけるチャレンジ
 非定型分析の性能最適化が難しい
– 利用頻度の高い列に索引をつける、FACT表は日付列を次元にしたMDC表にするといった、
設計上のベストプラクティスはあるが、あらゆる分析軸の可能性に対応することは困難
MDC
DB管理者
チューニングに膨大なコス
トをかけても、非定型のク
エリーへの対応困難
MQT
索引
索引
索引
BIレポートとアナリティクス
応答を待つ?
コーヒーに行く?
投入して帰宅する?
分析担当者
性能にばらつきがあり、
連続的な分析ができない
 ひとつのソリューションは、圧倒的な処理性能を持つDWHアプライアンス
– 大量データのスキャン、ソート、ジョインを伴う分析処理を高速に実行可能
BIレポートとアナリティクス
でも… DWHアプライアンスを導入するほどには、
データ規模が大きくない場合にどうする？
DB2 10.5のBLUアクセラレーションが解決！
© 2013 IBM Corporation
8
DB2 10.5 BLUアクセラレーション登場
BLU アクセラレーション
アナリティクス処理を加速させるRDBの革命
• アナリティクス処理が従来よりも数十倍高速に
• 表にデータを投入するだけですぐに利用可能
• 索引チューニング不要
• 低コストで実装可能なハイブリッド・データベース
© 2013 IBM Corporation
9
ハイブリッド・
データベース
BLUアクセラレーションの特徴
1. カラム・オーガナイズ表
•
•
結果セットを導き出すのに必要な最低限のデータの
みをアクセス
索引の追加等のチューニング不要
BLUアクセラレーションを
実装したデータベース
クエリー実行環境
従来の
実行環境
BLU実行環境
2. ハードウェアの最適な活用
•
SIMDおよびマルチコア・パラレリズムによるCPU能
力のフル活用
•
CPUとキャッシュに最適化された圧縮アルゴリズム
3. ハイブリッド・データベース
•
ハードウェアの
最適な活用
カラム・オーガナイズ表と従来の
形式の表（行オーガナイズ表）が共存可能
•
共通のSQL、ユーティリティー・インタフェース
従来のデータ
管理サービス
従来のDB2バッファー・プール
SIMD機能を備えたCPU
ストレージ
従来の行形式の
テーブル
C1
•
BLU用データ
管理サービス
C2
C3
C4
C5
C6
C7
圧縮とエンコードが
行われた列テーブル
C8
C1 C2 C3 C4 C5 C6 C7 C8
既存のHWインフラ、アプリケーション、運用監視等、
すべてそのまま利用可能
カラム・オーガナイズ表
© 2013 IBM Corporation
10
BLUアクセラレーションのキー・テクノロジー
カラム・
オーガナイズ表
データ・
スキッピング
HWに最適化された
データ圧縮
マルチコア・
パラレリズム
SIMDによる
CPU最適化
© 2013 IBM Corporation
11
BLUテクノロジー(1):カラム・オーガナイズ表
汎用RDBMSにおける行ストア（行オーガナイズ表）
ID
商品名
価格
サイズ
発売日
 １ブロックにすべての列のデータを
1001
商品A
1000
L
2013-01-20
格納
1002
商品B
2000
XS
2010-07-07
 クエリーの結果導出に不要な列も
1003
商品C
1500
M
2012-10-31
読み込む必要がある。
1004
商品D
3000
S
2013-04-11
BLUアクセラレーション(カラム・オーガナイズ表)
ID
 列データ毎に別ブロックに格納
商品名
価格
1001
 参照処理における不要列データの
サイズ
商品A
発売日
1000
1002
読み込みが無くなり、必要なデータ
L
商品B
2013-01-20
2000
1003
のみ効率良くメモリーへロード
XS
商品C
2010-07-07
1500
1004
 同一列内には特定のデータが繰り
M
商品D
2012-10-31
3000
返し現れることが多く、圧縮効率が
S
2013-04-11
良い
© 2013 IBM Corporation
12
BLUテクノロジー(2):データ・スキッピング
SELECT * FROM T
WHERE
HATSUBAI=‘2013-01-06’
SKIP
 条件に適合しないデータブロックを自動的
にスキップ
- 一定のデータ件数毎に、各列に出現
したデータの最大値と最小値を保持
2013-01-01
2013-01-02
2013-01-03
2013-01-04
 I/O量、メモリー容量、CPU時間を大幅削
減
Min: 2013-01-05
Max:2013-01-08
2013-01-05
2013-01-06
2013-01-07
2013-01-08
SKIP
 データ・スキッピングのための管理情報は
すべて自動メンテナンスされ、利用者によ
る管理は一切不要
Min: 2013-01-01
Max:2013-01-04
発売日
Min: 2013-01-09
Max:2013-01-13
2013-01-09
2013-01-10
2013-01-11
2013-01-12
2013-01-13
条件に合致するデータを含んだ領域のみをスキャン
© 2013 IBM Corporation
13
BLUテクノロジー(3):マルチコア・パラレリズム
 カラム・オーガナイズ表に対するクエリーは、自動的に複数CPU
活用
– スキャン、結合、ソート等の処理を複数スレッドで並列に処理する。
© 2013 IBM Corporation
14
BLUテクノロジー(4):SIMDによるCPU最適化
• SIMD(Single Instruction Multiple Data) を利用し、複数の処理
をまとめて実行
■SIMDを利用した処理
■通常の処理
2012
2011
2010
2001
2003
2002
2009
2005
2001
2009
2008
2004
2012
データ
命令
CPU
2005
Compare
= 2009
結果ストリーム
1つの処理を4回繰り返す
© 2013 IBM Corporation
2007
2003
2011
データ
命令
Compare
= 2009
2006
2002
2010
CPU
2005
結果ストリーム
1回の命令で複数のデータを処理
15
BLUテクノロジー(5):HWに最適化されたデータ圧縮
 ハフマン符号化によるデータの圧縮率最大化
– 値の出現頻度が多いほど、ビット数を小さくする
 複数のデータをグルーピングしてレジスターに格納
– 複数データをレジスター幅にまとめ、単一インストラクションで処理
→ SIMDの活用
 エンコード済みの値は、圧縮したまま処理可能
– 述部（条件評価）と結合は、エンコード済みの値を直接処理
– 結果セットが必要となるまで、データの解凍(マテリアライズ)を行わない
LAST_NAME
Johnson
Smith
Smith
Smith
Smith
Johnson
Smith
Gilligan
Sampson
Smith
© 2013 IBM Corporation
エンコード値
レジスターの長さに揃えて格納
レジスター長
レジスター長
16
BLUアクセラレーションの処理イメージ
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
強化された圧縮技術
によりデータ容量を数
分の一に削減
数TBのデータ
複数CPUコアにて
並列にスキャン
DATA
© 2013 IBM Corporation
DATA
カラム・オーガナイ
ズ表の必要な列に
のみアクセス
データ・スキッピングに
よってアクセス対象
絞り込み
ベクトル処理(SIMD) により
各コア内で複数データを
一度に処理
数秒以内で
処理が完了
DATA
DATA
17
BLUアクセラレーションの効果(1):実装の迅速性
実装の迅速性
DB2 BLU Design and Tuning
• Create Table
• Load data
•インデックス不要
•RUNSTATSが不要（LOAD時
に自動的に実行）
•パフォーマンス向上のための
構成、追加オブジェクト、操作
が不要
これだけ
CREATE TABLE T1 ( C1 int, C2 char(200)) ORGANIZE BY COLUMN
アプライアンスに置き換えるのではなく、汎用RDBMSであるDB2の中で利用できる
特別な設計/チューニングをしなくても安定したハイ・パフォーマンスが得られる
使用のための準備作業を大幅に削減
© 2013 IBM Corporation
18
BLUアクセラレーションの効果(1):実装の迅速性
管理の複雑性を解決
繰り返し
実行する
BLUにより不要に
データベースの設計とチューニング
• パーティショニング戦略を決定する
• 圧縮手法を選択する
• テーブルを作成する
• データをロードする
• パフォーマンスを改善するための構造を作成する
• マテリアライズド・ビュー
• インデックスを作成する
• B+インデックス
• ビットマップ・インデックス
• メモリーをチューニングする
• I/Oをチューニングする
• オプティマイザーのヒントを追加する
• 統計情報を収集する
同じ処理結果を得るために必要なデータベース・オブジェクトの数が少ない
クエリー処理が最適化され、必要となるデータベース・オブジェクトの数が少ないため
継続的な管理業務を削減可能
© 2013 IBM Corporation
19
BLUアクセラレーションの効果(2):データ圧縮効率
• 強化された圧縮技術と、カラム・オーガナイズによる圧縮効率向上
• 処理オブジェクトの数を削減、索引用ストレージが不要
ストレージ・サイズには、
以下が含まれる
・表データ
・索引
・圧縮ディクショナリー
・列ストアのメタデータ
DB2 10.1の圧縮に比べても
高い圧縮効果
投資銀行
© 2013 IBM Corporation
独立系ソフトウェア・ベンダー
DB2 10.1（圧縮前）
DB2 10.1（圧縮後）
DB2（BLUアクセラレーション）
DB2
with BLU Accel.
メーカー
20
BLUアクセラレーションの効果(3):パフォーマンス
DB2 10.1 との比較
A社
B社
C社
D社
E社
46.8x
37.4x
13.0x
6.1x
5.6x
通常
数倍から
数十倍の
パフォーマンスアップ
BNSF
RAILWAY
「当社が使っている行テーブルのパフォーマンスと比較して、クエリーの大幅なスピード
アップが実現することに驚きました。当社が実行するクエリーのうち4件について、パ
フォーマンスが100倍以上改善したのです! パフォーマンスの改善が最も顕著だったの
は、BLUアクセラレーションによってあるクエリーの処理スピードが137倍になったこと
です」
© 2013 IBM Corporation
21
検証結果から見るDB2 10.5 BLU
アクセラレーションの有用性
© 2013 IBM Corporation
22
検証の目的
 DB2の最新リリース10.5が、BLUアクセラレーションと呼ばれる、列指向
のデータ処理エンジンを搭載するようになった。この機能により、従来
からのデータベースの運用や既存のアプリケーションを一切変更する
ことなく、高速なデータ分析が可能になる。
 今回の検証では、この新しい技術と、従来から行指向のテーブルを
使った処理との特性の違いを検証し、当技術を利用する上での指針や
ヒントを得る。
実装の迅速性
圧縮効率
パフォーマンス
 確認ポイント
 確認ポイント
 確認ポイント
 構築/運用の簡易性
 テーブルおよび
関連オブジェクト
のデータ容量
 検索性能が高速である
こと
 テーブル作成後に即
時ロード
 チューニング有無
© 2013 IBM Corporation
 圧縮率
 分析の軸が変更された
場合でも、チューニング
なしで高速検索が可能
23
実施テスト：Star Schema Benchmark
SUPPLIER（20万件）
CUSTOMER (300万件)
C_CUSTKEY
C_NAME
C_ADDRESS
C_CITY
C_NATION
C_REGION
C_PHONE
C_MKTSEGMENT
PART (140万件）
P_PARTKEY
P_NAME
P_MFGR
P_CATEGORY
P_BRAND
P_COLOR
P_TYPE
P_SIZE
P_CONTAINER
LINEORDER（6億件)
LINEORDER
LO_ORDERKEY
LO_LINENUMBER
LO_CUSTKEY
LO_PARTKEY
LO_SUPPKEY
LO_ORDERDATE
LO_ORDERPRIOTITY
LO_SHIPPRIOTITY
LO_QUANTITY
LO_EXTENDEDPRICE
LO_ORDTOTALPRICE
LO_DISCOUNT
LO_REVENUE
LO_SUPPLYCOST
LO_TAX
LO_COMMITDATE
LO_SHIPMODE
Star Schema Benchmark のモデルを利用 (www.cs.umb.edu/~poneil/StarSchemaB.pdf )
Scale Factor = 100にてデータ生成
© 2013 IBM Corporation
S_SUPPKEY
S_NAME
S_ADDRESS
S_CITY
S_NATION
S_REGION
S_PHONE
DATES (2556件）
D_DATEKEY
D_DATE
D_DAYOFWEEK
D_MONTH
D_YEAR
D_YEARMONTHNUM
D_YEARMONTH
D_DAYNUMINWEEK
D_DAYNUMINMONTH
D_DAYNUMINYEAR
D_MONTHNUMINYEAR
D_WEEKNUMINYEAR
D_SELLINGSEASON
D_LASTDAYINWEEKFL
D_LASTDAYINMONTHFL
D_HOLIDAYFL
D_WEEKDAYFL
24
Star Schema Benchmarkクエリー
• Star Schema Benchmarkが定める13のクエリー性能を測定
– パターン1： 2つの表の結合と集計を、選択行のレンジを変動させながら
実行
– パターン2： 4つの表を結合し、2つの分析軸で集計
– パターン3： 4つの表を結合し、3つの分析軸で集計
– パターン4： 5つの表を結合し、3つの分析軸で集計
© 2013 IBM Corporation
25
検証クエリー・パターン1 (Q1.1～Q1.3）
• ２つの表の結合と集計を、選択行のレンジを変動させながら３種類実行
-- Query Q1.1
SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS REVENUE
FROM LINEORDER, DATES
WHERE LO_ORDERDATE = D_DATEKEY
AND D_YEAR = 1993
AND LO_DISCOUNT BETWEEN 1 AND 3
AND LO_QUANTITY < 25;
-- Query Q1.2
SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS REVENUE
FROM LINEORDER, DATES
WHERE LO_ORDERDATE = D_DATEKEY
AND D_YEARMONTH = 'Jan1994'
AND LO_DISCOUNT BETWEEN 4 AND 6
AND LO_QUANTITY BETWEEN 26 AND 35;
-- Query Q1.3
SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS REVENUE
FROM LINEORDER, DATES
WHERE LO_ORDERDATE = D_DATEKEY
AND D_WEEKNUMINYEAR = 6
AND D_YEAR = 1994
AND LO_DISCOUNT BETWEEN 5 AND 7
AND LO_QUANTITY BETWEEN 26 AND 35;
© 2013 IBM Corporation
26
検証クエリー・パターン2 (Q2.1～Q2.3）
• ４つの表を結合し、2つの分析軸で集計
– 選択行のレンジを変動させながら３種類のクエリーを実行
-- Query Q2.1
SELECT SUM(LO_REVENUE), D_YEAR, P_BRAND
FROM LINEORDER, DATES, PART, SUPPLIER
WHERE LO_ORDERDATE = D_DATEKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND P_CATEGORY = 'MFGR#12'
AND S_REGION = 'AMERICA'
GROUP BY D_YEAR, P_BRAND
ORDER BY D_YEAR, P_BRAND;
-- Query Q2.3
SELECT SUM(LO_REVENUE), D_YEAR, P_BRAND
FROM LINEORDER, DATES, PART, SUPPLIER
WHERE LO_ORDERDATE = D_DATEKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND P_BRAND= 'MFGR#2239'
AND S_REGION = 'EUROPE'
GROUP BY D_YEAR, P_BRAND
ORDER BY D_YEAR, P_BRAND;
-- Query Q2.2
SELECT SUM(LO_REVENUE), D_YEAR, P_BRAND
FROM LINEORDER, DATES, PART, SUPPLIER
WHERE LO_ORDERDATE = D_DATEKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND P_BRAND BETWEEN 'MFGR#2221'
AND 'MFGR#2228'
AND S_REGION = 'ASIA'
GROUP BY D_YEAR, P_BRAND
ORDER BY D_YEAR, P_BRAND;
© 2013 IBM Corporation
27
検証クエリー・パターン3 (Q3.1～Q3.4）
 ４つの表を結合し、３つの分析軸で集計
– 選択行のレンジや分析軸の異なる４種類のクエリーを実行
-- Query Q3.1
SELECT C_NATION, S_NATION, D_YEAR,
SUM(LO_REVENUE) AS REVENUE
FROM CUSTOMER, LINEORDER, SUPPLIER, DATES
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_ORDERDATE = D_DATEKEY
AND C_REGION = 'ASIA'
AND S_REGION = 'ASIA'
AND D_YEAR >= 1992 AND D_YEAR <= 1997
GROUP BY C_NATION, S_NATION, D_YEAR
ORDER BY D_YEAR ASC, REVENUE DESC;
-- Query Q3.2
SELECT C_CITY, S_CITY, D_YEAR, SUM(LO_REVENUE)
AS REVENUE
FROM CUSTOMER, LINEORDER, SUPPLIER, DATES
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_ORDERDATE = D_DATEKEY
AND C_NATION = 'UNITED STATES'
AND S_NATION = 'UNITED STATES'
AND D_YEAR >= 1992 AND D_YEAR <= 1997
GROUP BY C_CITY, S_CITY, D_YEAR
ORDER BY D_YEAR ASC, REVENUE DESC;
© 2013 IBM Corporation
-- Query Q3.3
SELECT C_CITY, S_CITY, D_YEAR, SUM(LO_REVENUE)
AS REVENUE
FROM CUSTOMER, LINEORDER, SUPPLIER, DATES
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_ORDERDATE = D_DATEKEY
AND (C_CITY='UNITED KI1'
OR C_CITY='UNITED KI5')
AND (S_CITY='UNITED KI1'
OR S_CITY='UNITED KI5')
AND D_YEAR >= 1992 AND D_YEAR <= 1997
GROUP BY C_CITY, S_CITY, D_YEAR
ORDER BY D_YEAR ASC, REVENUE DESC;
-- Query Q3.4
SELECT C_CITY, S_CITY, D_YEAR, SUM(LO_REVENUE)
AS REVENUE
FROM CUSTOMER, LINEORDER, SUPPLIER, DATES
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_ORDERDATE = D_DATEKEY
AND (C_CITY='UNITED KI1'
OR C_CITY='UNITED KI5')
AND (S_CITY='UNITED KI1'
OR S_CITY='UNITED KI5')
AND D_YEARMONTH = 'Dec1997'
GROUP BY C_CITY, S_CITY, D_YEAR
ORDER BY D_YEAR ASC, REVENUE DESC;
28
検証クエリー・パターン4 (Q4.1～Q4.3）
 ５つの表を結合して集計
– 選択行のレンジや分析軸の異なる３種類を実行
-- Query Q4.1
SELECT D_YEAR, C_NATION,
SUM(LO_REVENUE - LO_SUPPLYCOST) AS PROFIT
FROM DATES, CUSTOMER, SUPPLIER, PART, LINEORDER
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_ORDERDATE = D_DATEKEY
AND C_REGION = 'AMERICA'
AND S_REGION = 'AMERICA'
AND (P_MFGR = 'MFGR#1'
OR P_MFGR = 'MFGR#2')
GROUP BY D_YEAR, C_NATION
ORDER BY D_YEAR, C_NATION;
-- Query Q4.3
SELECT D_YEAR, S_CITY, P_BRAND,
SUM(LO_REVENUE - LO_SUPPLYCOST) AS PROFIT
FROM DATES, CUSTOMER, SUPPLIER, PART, LINEORDER
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_ORDERDATE = D_DATEKEY
AND S_NATION = 'UNITED STATES'
AND (D_YEAR = 1997 OR D_YEAR = 1998)
AND P_CATEGORY = 'MFGR#14'
GROUP BY D_YEAR, S_CITY, P_BRAND
ORDER BY D_YEAR, S_CITY, P_BRAND;
-- Query Q4.2
SELECT D_YEAR, S_NATION, P_CATEGORY,
SUM(LO_REVENUE - LO_SUPPLYCOST) AS PROFIT
FROM DATES, CUSTOMER, SUPPLIER, PART, LINEORDER
WHERE LO_CUSTKEY = C_CUSTKEY
AND LO_SUPPKEY = S_SUPPKEY
AND LO_PARTKEY = P_PARTKEY
AND LO_ORDERDATE = D_DATEKEY
AND C_REGION = 'AMERICA'
AND S_REGION = 'AMERICA'
AND (D_YEAR = 1997 OR D_YEAR = 1998)
AND (P_MFGR = 'MFGR#1'
OR P_MFGR = 'MFGR#2')
GROUP BY D_YEAR, S_NATION, P_CATEGORY
ORDER BY D_YEAR, S_NATION, P_CATEGORY;
© 2013 IBM Corporation
29
検証環境
IBM Power 740
(Power7 3.7GHz x 8 core, 64GB memory)
AIX 7.1 TL2 SP2
DB2 10.5 Beta
同一DB内に、BLUアクセラレーション機能
利用のためのカラム・オーガナイズ表と、
従来と同じ行オーガナイズ表(2パターン)
を作成し、比較
DS4800 (RAID5)
従来型表
従来型表
C1 C2 C3 C4 C5 C6 C7 C8
C1 C2 C3 C4 C5 C6 C7 C8
MDC
BLUアクセラレーション表
索引
索引
行オーガナイズ表
• 圧縮なし
• 索引なし
© 2013 IBM Corporation
C1 C2 C3 C4 C5 C6 C7 C8
…
行オーガナイズ表
※チューニング有り
• 圧縮あり
• 20索引追加
• MDC次元列追加
カラム・オーガナイズ表
• デフォルトでBLU圧縮
• 索引なし
30
DB2 BLU アクセラレーションの使用開始までの流れ
①通常のDB2導入と同じ手順で、DB2 10.5
の導入とインスタンス作成
-
db2setup等にて導入
実装の迅速性
◎構築/運用の簡易性
◎テーブル作成後に
即時ロード
◎チューニング不要
②レジストリー変数 DB2_WORKLOAD=ANALYTICS を設定
③データベースの作成 CREATE DATABASE db名
 BLUに適したDBパラメータが設定され、表のデフォルトがカラム・
オーガナイズ表となる(自動設定）
C1 C2 C3 C4 C5 C6 C7 C8
④テーブルの作成 CREATE TABLE table名 …
 データ圧縮は常にオン
 索引は必要としない
圧縮後
データ
⑤データロード
分析対象データ
カラム・オーガナイズ表の場合は、ロード時に以下の処理も
含まれる
⑥分析用SQL実行
•
圧縮辞書の作成と圧縮処理
SQLの述部の評価
JOINのキーマッチングは
圧縮データのまま実行
•
自動で統計情報が更新される
© 2013 IBM Corporation
31
カラム・オーガナイズ表（BLU）と行オーガナイズ表の共存

DB構成パラメーター DFT_TABLE_ORGにて、デフォルトの表タイプを指定
– COLUMN：カラム・オーガナイズ表（BLU）
– ROW：
行オーガナイズ表

１つのデータベース内で２つのタイプの表が共存可能
– ORGANIZE BY COLUMN / ORGANIZE BY ROW によって明示指定可能
CREATE TABLE BLU01 (C1 INT, C2 CHAR(100)) ORGANIZE BY COLUMN
CREATE TABLE ROW01 (C1 INT, C2 CHAR(100)) ORGANIZE BY ROW
© 2013 IBM Corporation
32
(補足)行オーガナイズ表へのチューニング：アドバイザー
BLUでは不要
による推奨索引追加
• Q1.1～Q4.3までの13個のクエリーをもとに推奨された索引をすべて定義
■ CUSTOMER表
■ SUPPLIER表
索引１：
C_REGION + C_NATION + C_CUSTKEY
索引１：
S_REGION S_NATION S_SUPPKEY
索引２：
C_REGION + C_CUSTKEY
索引２：
S_NATION S_CITY S_SUPPKEY
索引３：
C_NATION + C_CITY C_CUSTKEY
索引３：
S_CITY S_SUPPKEY
索引４：
C_CITY C_CUSTKEY
索引４：
S_REGION S_SUPPKEY
索引５：
C_CUSTKEY
■ DATES表：
■ PART表
索引１：
D_YEAR ＋ D_DATEKEY
索引１：
P_MFGR P_CATEGORY P_PARTKEY
索引２：
D_YEARMONTH ＋ D_YEAR ＋ D_DATEKEY
索引２：
P_CATEGORY P_BRAND P_PARTKEY
索引３：
D_WEEKNUMINYEAR ＋ D_YEAR ＋ D_DATEKEY
索引３：
P_BRAND P_PARTKEY
索引４：
D_YEARMONTH ＋ D_DATEKEY
索引４：
P_BRAND P_PARTKEY
索引５：
D_DATEKEY ＋ D_YEAR
■ LINEORER表：
索引１：
LO_PARTKEY ＋ LO_REVENUE
＋ LO_ORDERDATE + LO_SUPPKEY
索引２：
LO_ORDERDATE ＋ LO_DISCOUNT
＋ LO_QUANTITY ＋ LO_EXTENDEDPRICE
© 2013 IBM Corporation
33
(補足)行オーガナイズ表へのチューニング：
LINEORDER表のMDC化、圧縮指定
BLUでは不要
• LINEORDER表をMDC化し、スキャン行数を限定
– 13個のクエリーは日付範囲を指定したクエリーが多いため、日付にて
クラスタリング
• LO_ORDERDATEの年月部分だけを取り出した生成列
（LO_ORDERMONTH）をつくり、MDC表の次元列とした
CREATE TABLE LINEORDER
( LO_ORDERKEY
BIGINT,
LO_LINENUMBER
BIGINT,
LO_CUSTKEY
INTEGER NOT NULL,
LO_PARTKEY
INTEGER NOT NULL,
LO_SUPPKEY
INTEGER NOT NULL,
LO_ORDERDATE
INTEGER NOT NULL,
LO_ORDERPRIOTITY VARCHAR(15) NOT NULL,
LO_SHIPPRIOTITY
INTEGER,
LO_QUANTITY
BIGINT,
LO_EXTENDEDPRICE BIGINT,
LO_ORDTOTALPRICE BIGINT,
LO_DISCOUNT
BIGINT,
LO_REVENUE
BIGINT,
LO_SUPPLYCOST
BIGINT,
LO_TAX
BIGINT,
LO_COMMITDATE
INTEGER NOT NULL,
LO_SHIPMODE
VARCHAR(10) NOT NULL,
LO_ORDERMONTH
INTEGER NOT NULL GENERATED ALWAYS AS (LO_ORDERDATE/100) )
ORGANIZE BY DIMENSIONS ( LO_ORDERMONTH )
COMPRESS YES ADAPTIVE;
圧縮も指定
© 2013 IBM Corporation
34
圧縮効率の検証
• LINEORDER表(6億件)のデータロード後サイズを３種類の表で
比較
– 行オーガナイズ表（圧縮なし、索引なし）
– 行オーガナイズ表 ※チューニング有り (圧縮あり、索引あり、MDC次元
列あり）
– カラム・オーガナイズ表（デフォルトでBLU圧縮、索引なし）
• 圧縮率の確認
– ロード後、管理ビューにて消費ストレージサイズを確認
SELECT
VARCHAR(TABNAME,20) AS TABNAME,
DATA_OBJECT_P_SIZE,
INDEX_OBJECT_P_SIZE,
COL_OBJECT_P_SIZE
FROM SYSIBMADM.ADMINTABINFO WHERE TABNAME=‘LINEORDER’；
© 2013 IBM Corporation
35
圧縮効率の検証
圧縮効率
◎索引用ストレージが不要
◎強化された圧縮技術により圧縮効率向上
100%
87%
ストレージ消費（MB ）
表
タイプ
22%
行
MDC
BLU
Data
Obj
Index
Obj
Coｌ Obj
Total
圧縮
率
行
78,089
－
－
78,089
100%
MDC
37,226
30,458
－
67,684
87%
BLU
2
13
17,270
17,285
22%
行：行オーガナイズ表 (圧縮なし、索引なし)
MDC ：チューニングした行オーガナイズ表(圧縮あり、索引あり、
MDC次元列あり)
BLU ：カラム・オーガナイズ表(デフォルトでBLU圧縮、索引なし)
BLU(カラム・オーガナイズ表）ではデフォルトで大きな圧縮効果
[補足]SYSIBMADM.ADMINTABINFO管理ビューには、カラム・オーガナイズ表の物理データを保管する領域サイズを確認する
COL_OBJECT_P_SIZE列が追加されている。
内部のメタデータを管理するため、カラム・オーガナイズ表も、わずかにデータ・ページ、索引ページの消費がある。
© 2013 IBM Corporation
36
パフォーマンス検証：
Star Schema Benchmarkクエリー結果
•
13個のクエリーの応答性能を3種類の表で比較
– 行：行オーガナイズ表 (圧縮なし、索引なし)
– MDC ：チューニングした行オーガナイズ表 (圧縮あり、索引あり、MDC次元列あり)
– BLU：カラム・オーガナイズ表(デフォルトでBLU圧縮、索引なし)
表のタ
イプ
各クエリーの応答時間（秒）
Q1.1
Q1.2
Q1.3
Q2.1
Q2.2
Q2.3
Q3.1
Q3.2
Q3.3
Q3.4
Q4.1
Q4.2
Q4.3
行
342.7
341.1
340.9
304.3
319.5
334.1
260.7
325.6
336.3
336.7
253.1
261.9
296.4
MDC
6.5
0.2
0.1
25.8
4.1
0.5
105.4
103.2
103.0
17.5
104.5
103.8
103.3
BLU
2.6
2.2
1.9
6.1
5.3
5.2
9.1
5.8
4.6
1.8
9.9
6.6
4.8
行オーガナイズ表をカラム・オーガナイズ表に変更することで、各4分～6分要していたク
エリーが、数秒で完了するようになった。
索引の追加やMDC表への変更で、行オーガナイズ表でも高速化できるクエリーはある
が、効果が十分に発揮されないクエリーもある。
© 2013 IBM Corporation
37
パフォーマンス検証：MDCとBLU表の比較のポイント
 BLUではクエリー形式の違いにかかわらず、一貫して高速なレスポンスを維持
パフォーマンス
MDC化や索引追加
などで最適化した表
を用意しても、すべて
のクエリーの高速化
は難しい
◎検索性能が高速である
こと
◎分析の軸が変更された
場合でも、チューニングな
しで高速検索が可能
クエリーの形式や集計
列の違いに関わらず、
カラム・オーガナイズ
表（BLU）は数秒の応
答時間を維持
カラム・オーガナイズ表を使えば、照会の軸、
範囲が急遽変更になってもチューニングなしで対応可能
© 2013 IBM Corporation
38
[ご参考]DB2 10.5 BLUアクセラレーション機能対応！
Optim Query Workload TunerによるBLU表への変更
アドバイス例
変更後のパフォーマンス改善
率も推定してくれる
対象表
一覧
© 2013 IBM Corporation
カラム・オーガナイ
ズ表への移行推奨
移行用のスクリプトも
表毎に出力してくれる
39
BLUアクセラレーション検証結果サマリー
実装の迅速性
圧縮効率
パフォーマンス
 確認ポイント
 確認ポイント
 確認ポイント
◎ 構築/運用の簡易性
◎ 索引用ストレージが不
要
◎ 検索性能が高速である
こと
◎ 強化された圧縮技術
により圧縮効率向上
◎ 分析の軸が変更された
場合でも、チューニング
なしで高速検索が可能
◎ テーブル作成後に即
時ロード
◎ チューニング不要
 Star Schema Benchmark結果サマリー
–
–
–
–
スタースキーマの分析処理に対して、BLUは安定的に性能向上が見られた。
BLUは、従来表に比べ、25倍～187倍の性能向上
BLUは、すべてのケースにおいて数秒で応答
データ・アナリティクスのように、検索条件や分析の軸が随時変わるようなワーク
ロードに対しては、カラム・オーガナイズ表の利用が適していると言える。
– 索引、MDC等の事前設計の困難な非定型検索にBLUが適している
© 2013 IBM Corporation
40
DB2 BLUアクセラレーションの活用シナリオ例
EDWアプリケーション
OLAPアプリケーション
Cognos BI
BLUアクセラレーションを実現
Cognos BI
他社のパフォーマンスの
落ちたデータウェアハウス
BLUアクセラレーションを実現
BLUアクセラレーションで構築
された高速なデータ・マートを簡
単に作成・ロードする
アナリティクスの
データ・マート
（BLUテーブル）
マルチプラットフォーム・
ソフトウェア
© 2013 IBM Corporation
41
BLUアクセラレーションまとめ
• DB2 10.5のひとつの機能として利用可能な
分析処理を加速するソフトウェア
分析処理が速い！
BLUアクセラレーションを
実装したDB2 10.5
クエリー実行環境
従来の
実行環境
BLU実行環境
使い方が簡単！
従来のデータ
管理サービス
行と列のハイブリッド！
BLU用データ
管理サービス
従来のDB2バッファープール
SIMD機能を備えたCPU
ビッグデータの分析のスタートに最適
DB2
ストレージ
従来の行形式の
テーブル
C1
C2
C3
C4
C5
C6
C7
圧縮とエンコードが
行われた列テーブル
C8
C1 C2 C3 C4 C5 C6 C7 C8
WITH BLU
ACCELERATION
© 2013 IBM Corporation
42
ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目
的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありませ
ん。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかな
る保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責
任を負わないものとします。本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすこ
とを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むもので
もありません。
本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示するも
のではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつで
も変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含ま
れている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したもので
も、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいて
います。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレー
ジ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと
同様の結果を得られると確約するものではありません。
記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたもの
です。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。
IBM、IBM ロゴ、ibm.com、AIX、Cognos、DB2、Optim、Power、PureData、pureScale、およびz/OSは、世界の多くの国で登録されたInternational Business
Machines Corporationの商標です。
他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。
現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。
© 2013 IBM Corporation
43

Download Report