DB2 BLUアクセラレーションを中心にDB2の機能を解説

1. © 2013 IBM Corporation
データベース・テクノロジー Part 2
「カラム型」が実現するビッグデータの高速処理
日本アイ・ビー・エム株式会社
ソフトウェア事業 インフォメーション･マネジメント事業部
平野 真弓
【A-2】

2. © 2013 IBM Corporation 2
ご説明内容
• DB2進化の歴史 ～ より速く、止まらないDB
• DB2 10.5登場
• DB2 10.5 BLUアクセラレーション
– BLUアクセラレーションの特徴
– BLUアクセラレーションのキー・テクノロジー
– BLUアクセラレーションの効果
• 検証結果から見るDB2 10.5 BLUアクセラレーションの有用性
• Cognos Business Intelligence(Cognos BI)との連携デモンスト
レーション
• BLUアクセラレーションまとめ

3. © 2013 IBM Corporation
DB2の進化の歴史
～ より速く、止まらないDB～
3

4. © 2013 IBM Corporation 4
DB2進化の歴史 ～ より速く、止まらないDB
 大規模データの高速処理  基幹システムを支える連続稼動性
（Database Partitioning
Feature）
・多次元クラスター表/パーティション表
シェアード・ナッシング・
アーキテクチャーによる
大量データの並列処理
同じ値を持つ行を同じブロック/
パーティションに保管し、データ・
アクセスを効率化
・マテリアライズ照会表
(Materialized Query Table)
時間のかかるクエリーの
結果を保管、実行クエリー
に応じてMQTから結果導出
・HADR
(High Availability Disaster
Recovery)
・DB2 pureScale
ログ・シッピングによる
高可用性と災害対策の
２つのソリューションを
実現
DB2 for z/OS データ共用の
アーキテクチャーを採用し、極
めて高い連続稼動性と拡張
性を実現
RDMA通信
DB2 DB2DB2CF
・DBパーティショニング
ブロック
履歴表A
5月1月 2月 3月 4月
(Multi Dimension Clustering/ Table partitioning)

5. © 2013 IBM Corporation
DB2 10.5登場
5

6. © 2013 IBM Corporation
DB2 10.5登場
BLU アクセラレーション
アナリティクス処理を加速させるRDBの革命
• アナリティクス処理が従来よりも数十倍高速に
• 表にデータを投入するだけですぐに利用可能
• 索引チューニング不要
• 低コストで実装可能なハイブリッド・データベース
DB2 pureScaleのさらなる進化
基幹業務を支えるため、連続稼動性と
性能をさらに強化
• オンライン・メンテナンス
• 災害対策ソリューション
• オンライン、バッチ双方の性能向上
6

7. © 2013 IBM Corporation
DB2 10.5
BLUアクセラレーション
7

8. © 2013 IBM Corporation 8
アナリティクス処理の性能最適化におけるチャレンジ
BIレポートとアナリティクス
 非定型分析の性能最適化が難しい
– 利用頻度の高い列に索引をつける、FACT表は日付列を次元にしたMDC表にするといった、
設計上のベストプラクティスはあるが、あらゆる分析軸の可能性に対応することは困難
でも… DWHアプライアンスを導入するほどには、
データ規模が大きくない場合にどうする？
索引
索引
索引
MDC
 ひとつのソリューションは、圧倒的な処理性能を持つDWHアプライアンス
– 大量データのスキャン、ソート、ジョインを伴う分析処理を高速に実行可能
MQTDB管理者
チューニングに膨大なコス
トをかけても、非定型のク
エリーへの対応困難
分析担当者
性能にばらつきがあり、
連続的な分析ができない
BIレポートとアナリティクス
応答を待つ?
コーヒーに行く?
投入して帰宅する?
DB2 10.5のBLUアクセラレーションが解決！

9. © 2013 IBM Corporation 9
DB2 10.5 BLUアクセラレーション登場
BLU アクセラレーション
アナリティクス処理を加速させるRDBの革命
• アナリティクス処理が従来よりも数十倍高速に
• 表にデータを投入するだけですぐに利用可能
• 索引チューニング不要
• 低コストで実装可能なハイブリッド・データベース

10. © 2013 IBM Corporation 10
ストレージ
圧縮とエンコードが
行われた列テーブル
従来の行形式の
テーブル
SIMD機能を備えたCPU
BLUアクセラレーションを
実装したデータベース
BLU用データ
管理サービス
クエリー実行環境
従来の
実行環境 BLU実行環境
従来のDB2バッファー・プール
従来のデータ
管理サービス
1. カラム・オーガナイズ表
• 結果セットを導き出すのに必要な最低限のデータの
みをアクセス
• 索引の追加等のチューニング不要
2. ハードウェアの最適な活用
• SIMDおよびマルチコア・パラレリズムによるCPU能
力のフル活用
• CPUとキャッシュに最適化された圧縮アルゴリズム
3. ハイブリッド・データベース
• カラム・オーガナイズ表と従来の
形式の表（行オーガナイズ表）が共存可能
• 共通のSQL、ユーティリティー・インタフェース
• 既存のHWインフラ、アプリケーション、運用監視等、
すべてそのまま利用可能
ハイブリッド・
データベース
カラム・オーガナイズ表
ハードウェアの
最適な活用
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8 C1C2C3 C4C5 C6C7C8C1C2C3 C4C5 C6C7C8
BLUアクセラレーションの特徴

11. © 2013 IBM Corporation 11
BLUアクセラレーションのキー・テクノロジー
カラム・
オーガナイズ表
データ・
スキッピング
マルチコア・
パラレリズム
SIMDによる
CPU最適化
HWに最適化された
データ圧縮

12. © 2013 IBM Corporation 12
BLUテクノロジー(1):カラム・オーガナイズ表
汎用RDBMSにおける行ストア（行オーガナイズ表）
BLUアクセラレーション(カラム・オーガナイズ表)
 列データ毎に別ブロックに格納
 参照処理における不要列データの
読み込みが無くなり、必要なデータ
のみ効率良くメモリーへロード
 同一列内には特定のデータが繰り
返し現れることが多く、圧縮効率が
良い
ID 商品名 価格 サイズ 発売日
1001 商品A 1000 L 2013-01-20
ID
1001
1002
1003
1004
商品名
商品A
商品B
商品C
商品D
価格
1000
2000
1500
3000
サイズ
L
XS
M
S
発売日
2013-01-20
2010-07-07
2012-10-31
2013-04-11
 １ブロックにすべての列のデータを
格納
 クエリーの結果導出に不要な列も
読み込む必要がある。
1002 商品B 2000 XS 2010-07-07
1003 商品C 1500 M 2012-10-31
1004 商品D 3000 S 2013-04-11

13. © 2013 IBM Corporation
BLUテクノロジー(2):データ・スキッピング
発売日
2013-01-01
2013-01-02
2013-01-03
2013-01-04
2013-01-05
2013-01-06
2013-01-07
2013-01-08
2013-01-09
2013-01-10
2013-01-11
2013-01-12
2013-01-13
Min: 2013-01-09
Max:2013-01-13
SELECT * FROM T
WHERE
HATSUBAI=‘2013-01-06’
Min: 2013-01-01
Max:2013-01-04
SKIP
条件に合致するデータを含んだ領域のみをスキャン
Min: 2013-01-05
Max:2013-01-08
SKIP
13
条件に適合しないデータブロックを自動的
にスキップ
- 一定のデータ件数毎に、各列に出現
したデータの最大値と最小値を保持
I/O量、メモリー容量、CPU時間を大幅削
減
データ・スキッピングのための管理情報は
すべて自動メンテナンスされ、利用者によ
る管理は一切不要

14. © 2013 IBM Corporation
BLUテクノロジー(3):マルチコア・パラレリズム
 カラム・オーガナイズ表に対するクエリーは、自動的に複数CPU
活用
– スキャン、結合、ソート等の処理を複数スレッドで並列に処理する。
14

15. © 2013 IBM Corporation 15
• SIMD(Single Instruction Multiple Data) を利用し、複数の処理
をまとめて実行
Compare
= 2009
2001
命令
結果ストリーム
データ
2002 2003 2004
2005
2005 2006 2007 20082009 2010 2011 2012
CPU
2001
命令
結果ストリーム
データ
200220032009
2010
2011
2012
Compare
= 2009 2005
CPU
BLUテクノロジー(4):SIMDによるCPU最適化
1つの処理を4回繰り返す 1回の命令で複数のデータを処理
■通常の処理 ■SIMDを利用した処理

16. © 2013 IBM Corporation
BLUテクノロジー(5):HWに最適化されたデータ圧縮
 ハフマン符号化によるデータの圧縮率最大化
– 値の出現頻度が多いほど、ビット数を小さくする
 複数のデータをグルーピングしてレジスターに格納
– 複数データをレジスター幅にまとめ、単一インストラクションで処理
→ SIMDの活用
 エンコード済みの値は、圧縮したまま処理可能
– 述部（条件評価）と結合は、エンコード済みの値を直接処理
– 結果セットが必要となるまで、データの解凍(マテリアライズ)を行わない
Smith
Smith
Smith
Smith
Smith
Smith
Johnson
Johnson
Gilligan
Sampson
LAST_NAME エンコード値
レジスターの長さに揃えて格納
レジスター長
レジスター長
16

17. © 2013 IBM Corporation
数TBのデータ
強化された圧縮技術
によりデータ容量を数
分の一に削減
複数CPUコアにて
並列にスキャン
ベクトル処理(SIMD) により
各コア内で複数データを
一度に処理
数秒以内で
処理が完了
カラム・オーガナイ
ズ表の必要な列に
のみアクセス
データ・スキッピングに
よってアクセス対象
絞り込み
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA DATA DATA
DATA
DATA DATA
17
BLUアクセラレーションの処理イメージ

18. © 2013 IBM Corporation
BLUアクセラレーションの効果(1):実装の迅速性
18
DB2 BLU Design and Tuning
• Create Table
• Load data
CREATE TABLE T1 ( C1 int, C2 char(200)) ORGANIZE BY COLUMN
これだけ
アプライアンスに置き換えるのではなく、汎用RDBMSであるDB2の中で利用できる
特別な設計/チューニングをしなくても安定したハイ・パフォーマンスが得られる
使用のための準備作業を大幅に削減
•インデックス不要
•RUNSTATSが不要（LOAD時
に自動的に実行）
•パフォーマンス向上のための
構成、追加オブジェクト、操作
が不要
実装の迅速性

19. © 2013 IBM Corporation
BLUアクセラレーションの効果(1):実装の迅速性
19
データベースの設計とチューニング
• パーティショニング戦略を決定する
• 圧縮手法を選択する
• テーブルを作成する
• データをロードする
• パフォーマンスを改善するための構造を作成する
• マテリアライズド・ビュー
• インデックスを作成する
• B+インデックス
• ビットマップ・インデックス
• メモリーをチューニングする
• I/Oをチューニングする
• オプティマイザーのヒントを追加する
• 統計情報を収集する
繰り返し
実行する
同じ処理結果を得るために必要なデータベース・オブジェクトの数が少ない
クエリー処理が最適化され、必要となるデータベース・オブジェクトの数が少ないため
継続的な管理業務を削減可能
BLUにより不要に管理の複雑性を解決

20. © 2013 IBM Corporation
BLUアクセラレーションの効果(2):データ圧縮効率
• 強化された圧縮技術と、カラム・オーガナイズによる圧縮効率向上
• 処理オブジェクトの数を削減、 索引用ストレージが不要
DB2 with BLU Accel.DB2 with BLU Accel.
ストレージ・サイズには、
以下が含まれる
・表データ
・索引
・圧縮ディクショナリー
・列ストアのメタデータ
独立系ソフトウェア・ベンダー
DB2 10.1（圧縮前）
DB2 10.1（圧縮後）
DB2（BLUアクセラレーション）
DB2 10.1の圧縮に比べても
高い圧縮効果
20
投資銀行 メーカー

21. © 2013 IBM Corporation
BLUアクセラレーションの効果(3):パフォーマンス
DB2 10.1 との比較
A社 46.8x
B社 37.4x
C社 13.0x
D社 6.1x
E社 5.6x
「当社が使っている行テーブルのパフォーマンスと比較して、クエリーの大幅なスピード
アップが実現することに驚きました。当社が実行するクエリーのうち4件について、パ
フォーマンスが100倍以上改善したのです! パフォーマンスの改善が最も顕著だったの
は、BLUアクセラレーションによってあるクエリーの処理スピードが137倍になったこと
です」
通常
数倍から
数十倍の
パフォーマンスアップ
21
BNSFRAILWAY

22. © 2013 IBM Corporation
検証結果から見るDB2 10.5 BLU
アクセラレーションの有用性
22

23. © 2013 IBM Corporation
検証の目的
23
 DB2の最新リリース10.5が、BLUアクセラレーションと呼ばれる、列指向
のデータ処理エンジンを搭載するようになった。 この機能により、従来
からのデータベースの運用や既存のアプリケーションを一切変更する
ことなく、高速なデータ分析が可能になる。
 今回の検証では、この新しい技術と、従来から行指向のテーブルを
使った処理との特性の違いを検証し、当技術を利用する上での指針や
ヒントを得る。
実装の迅速性 圧縮効率 パフォーマンス
 確認ポイント
 構築/運用の簡易性
 テーブル作成後に即
時ロード
 チューニング有無
 確認ポイント
 テーブルおよび
関連オブジェクト
のデータ容量
 圧縮率
 確認ポイント
 検索性能が高速である
こと
 分析の軸が変更された
場合でも、チューニング
なしで高速検索が可能

24. © 2013 IBM Corporation
実施テスト：Star Schema Benchmark
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
C_CUSTKEY
C_NAME
C_ADDRESS
C_CITY
C_NATION
C_REGION
C_PHONE
C_MKTSEGMENT
P_PARTKEY
P_NAME
P_MFGR
P_CATEGORY
P_BRAND
P_COLOR
P_TYPE
P_SIZE
P_CONTAINER
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
S_SUPPKEY
S_NAME
S_ADDRESS
S_CITY
S_NATION
S_REGION
S_PHONE
SUPPLIER（20万件）
LINEORDER（6億件)
PART (140万件）
DATES (2556件）
CUSTOMER (300万件)
Star Schema Benchmark のモデルを利用 (www.cs.umb.edu/~poneil/StarSchemaB.pdf )
Scale Factor = 100にてデータ生成
24

25. © 2013 IBM Corporation
Star Schema Benchmarkクエリー
• Star Schema Benchmarkが定める13のクエリー性能を測定
– パターン1： 2つの表の結合と集計を、選択行のレンジを変動させながら
実行
– パターン2： 4つの表を結合し、2つの分析軸で集計
– パターン3： 4つの表を結合し、3つの分析軸で集計
– パターン4： 5つの表を結合し、3つの分析軸で集計
25

26. © 2013 IBM Corporation
-- 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;
検証クエリー・パターン1 (Q1.1～Q1.3）
• ２つの表の結合と集計を、選択行のレンジを変動させながら３種類実行
26

27. © 2013 IBM Corporation
検証クエリー・パターン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.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;
-- 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;
27

28. © 2013 IBM Corporation
-- 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;
-- 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;
 ４つの表を結合し、３つの分析軸で集計
– 選択行のレンジや分析軸の異なる４種類のクエリーを実行
検証クエリー・パターン3 (Q3.1～Q3.4）
28

29. © 2013 IBM Corporation
-- 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.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;
-- 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;
 ５つの表を結合して集計
– 選択行のレンジや分析軸の異なる３種類を実行
検証クエリー・パターン4 (Q4.1～Q4.3）
29

30. © 2013 IBM Corporation
検証環境
IBM Power 740
(Power7 3.7GHz x 8 core, 64GB memory)
AIX 7.1 TL2 SP2
DB2 10.5 Beta
同一DB内に、BLUアクセラレーション機能
利用のためのカラム・オーガナイズ表と、
従来と同じ行オーガナイズ表(2パターン)
を作成し、比較
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8
従来型表
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8
行オーガナイズ表
• 圧縮なし
• 索引なし
行オーガナイズ表
※チューニング有り
• 圧縮あり
• 20索引追加
• MDC次元列追加
カラム・オーガナイズ表
• デフォルトでBLU圧縮
• 索引なし
従来型表 BLUアクセラレーション表
索引
MDC
…
索引
DS4800 (RAID5)
30

31. © 2013 IBM Corporation
①通常のDB2導入と同じ手順で、DB2 10.5
の導入とインスタンス作成
- db2setup等にて導入
②レジストリー変数 DB2_WORKLOAD=ANALYTICS を設定
③データベースの作成 CREATE DATABASE db名
 BLUに適したDBパラメータが設定され、表のデフォルトがカラム・
オーガナイズ表となる(自動設定）
④テーブルの作成 CREATE TABLE table名 …
 データ圧縮は常にオン
 索引は必要としない
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8
分析対象データ
圧縮後
データ ⑤データロード
⑥分析用SQL実行
実装の迅速性
◎構築/運用の簡易性
◎テーブル作成後に
即時ロード
◎チューニング不要
DB2 BLU アクセラレーションの使用開始までの流れ
SQLの述部の評価
JOINのキーマッチングは
圧縮データのまま実行
カラム・オーガナイズ表の場合は、ロード時に以下の処理も
含まれる
• 圧縮辞書の作成と圧縮処理
• 自動で統計情報が更新される
31

32. © 2013 IBM Corporation
カラム・オーガナイズ表（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
32

33. © 2013 IBM Corporation
■ CUSTOMER表
索引１： C_REGION + C_NATION + C_CUSTKEY
索引２： C_REGION + C_CUSTKEY
索引３： C_NATION + C_CITY C_CUSTKEY
索引４： C_CITY C_CUSTKEY
索引５： C_CUSTKEY
■ PART表
索引１： P_MFGR P_CATEGORY P_PARTKEY
索引２： P_CATEGORY P_BRAND P_PARTKEY
索引３： P_BRAND P_PARTKEY
索引４： P_BRAND P_PARTKEY
■ LINEORER表：
索引１： LO_PARTKEY ＋ LO_REVENUE
＋ LO_ORDERDATE + LO_SUPPKEY
索引２： LO_ORDERDATE ＋ LO_DISCOUNT
＋ LO_QUANTITY ＋ LO_EXTENDEDPRICE
(補足)行オーガナイズ表へのチューニング：アドバイザー
による推奨索引追加
• Q1.1～Q4.3までの13個のクエリーをもとに推奨された索引をすべて定義
■ SUPPLIER表
索引１： S_REGION S_NATION S_SUPPKEY
索引２： S_NATION S_CITY S_SUPPKEY
索引３： S_CITY S_SUPPKEY
索引４： S_REGION S_SUPPKEY
■ DATES表：
索引１： D_YEAR ＋ D_DATEKEY
索引２： D_YEARMONTH ＋ D_YEAR ＋ D_DATEKEY
索引３： D_WEEKNUMINYEAR ＋ D_YEAR ＋ D_DATEKEY
索引４： D_YEARMONTH ＋ D_DATEKEY
索引５： D_DATEKEY ＋ D_YEAR
33
BLUでは不要

34. © 2013 IBM Corporation
(補足)行オーガナイズ表へのチューニング：
LINEORDER表の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;
• LINEORDER表をMDC化し、スキャン行数を限定
– 13個のクエリーは日付範囲を指定したクエリーが多いため、日付にて
クラスタリング
• LO_ORDERDATEの年月部分だけを取り出した生成列
（LO_ORDERMONTH）をつくり、MDC表の次元列とした
圧縮も指定
34
BLUでは不要

35. © 2013 IBM Corporation
圧縮効率の検証
• 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’；
35

36. © 2013 IBM Corporation 36
BLU(カラム・オーガナイズ表）ではデフォルトで大きな圧縮効果
表
タイプ
ストレージ消費 （MB ）
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%
圧縮効率の検証
[補足]SYSIBMADM.ADMINTABINFO管理ビューには、カラム・オーガナイズ表の物理データを保管する領域サイズを確認する
COL_OBJECT_P_SIZE列が追加されている。
内部のメタデータを管理するため、カラム・オーガナイズ表も、わずかにデータ・ページ、索引ページの消費がある。
行 ： 行オーガナイズ表 (圧縮なし、索引なし)
MDC ： チューニングした行オーガナイズ表(圧縮あり、索引あり、
MDC次元列あり)
BLU ： カラム・オーガナイズ表(デフォルトでBLU圧縮、索引なし)
圧縮効率
◎索引用ストレージが不要
◎強化された圧縮技術により圧縮効率向上
100%
87%
22%
行 MDC BLU

37. © 2013 IBM Corporation
パフォーマンス検証：
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表への変更で、行オーガナイズ表でも高速化できるクエリーはある
が、効果が十分に発揮されないクエリーもある。
37

38. © 2013 IBM Corporation
パフォーマンス検証：MDCとBLU表の比較のポイント
カラム・オーガナイズ表を使えば、照会の軸、
範囲が急遽変更になってもチューニングなしで対応可能
 BLUではクエリー形式の違いにかかわらず、一貫して高速なレスポンスを維持
クエリーの形式や集計
列の違いに関わらず、
カラム・オーガナイズ
表（BLU）は数秒の応
答時間を維持
MDC化や索引追加
などで最適化した表
を用意しても、すべて
のクエリーの高速化
は難しい
パフォーマンス
◎検索性能が高速である
こと
◎分析の軸が変更された
場合でも、チューニングな
しで高速検索が可能
38

39. © 2013 IBM Corporation
[ご参考]DB2 10.5 BLUアクセラレーション機能対応！
Optim Query Workload TunerによるBLU表への変更
アドバイス例
対象表
一覧
カラム・オーガナイ
ズ表への移行推奨 移行用のスクリプトも
表毎に出力してくれる
変更後のパフォーマンス改善
率も推定してくれる
39

40. © 2013 IBM Corporation
BLUアクセラレーション検証結果サマリー
実装の迅速性 圧縮効率 パフォーマンス
 確認ポイント
◎ 構築/運用の簡易性
◎ テーブル作成後に即
時ロード
◎ チューニング不要
 確認ポイント
◎ 索引用ストレージが不
要
◎ 強化された圧縮技術
により圧縮効率向上
 確認ポイント
◎ 検索性能が高速である
こと
◎ 分析の軸が変更された
場合でも、チューニング
なしで高速検索が可能
 Star Schema Benchmark結果サマリー
– スタースキーマの分析処理に対して、BLUは安定的に性能向上が見られた。
– BLUは、従来表に比べ、25倍～187倍の性能向上
– BLUは、すべてのケースにおいて数秒で応答
– データ・アナリティクスのように、検索条件や分析の軸が随時変わるようなワーク
ロードに対しては、カラム・オーガナイズ表の利用が適していると言える。
– 索引、MDC等の事前設計の困難な非定型検索にBLUが適している
40

41. © 2013 IBM Corporation 41
Cognos BI
BLUアクセラレーションを実現
マルチプラットフォーム・
ソフトウェア
アナリティクスの
データ・マート
（BLUテーブル）
他社のパフォーマンスの
落ちたデータウェアハウス
Cognos BI
BLUアクセラレーションを実現
EDWアプリケーション OLAPアプリケーション
BLUアクセラレーションで構築
された高速なデータ・マートを簡
単に作成・ロードする
DB2 BLUアクセラレーションの活用シナリオ例

42. © 2013 IBM Corporation
BLUアクセラレーションまとめ
• DB2 10.5のひとつの機能として利用可能な
分析処理を加速するソフトウェア
分析処理が速い！
使い方が簡単！
行と列のハイブリッド！
ビッグデータの分析のスタートに最適
DB2
WITH BLU
ACCELERATION
ストレージ
圧縮とエンコードが
行われた列テーブル
従来の行形式の
テーブル
SIMD機能を備えたCPU
BLUアクセラレーションを
実装したDB2 10.5
BLU用データ
管理サービス
クエリー実行環境
従来の
実行環境 BLU実行環境
従来のDB2バッファープール
従来のデータ
管理サービス
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8 C1C2C3 C4C5 C6C7C8C1C2C3 C4C5 C6C7C8
42

43. © 2013 IBM Corporation 43
ワークショップ、セッション、および資料は、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をご覧ください。