More Related Content Similar to 増える実績データ、投資できない現実。少ない投資で最大限のパフォーマンスを得るにはどうするか?他のユーザーはどうしているか?
Similar to 増える実績データ、投資できない現実。少ない投資で最大限のパフォーマンスを得るにはどうするか?他のユーザーはどうしているか? (20) 増える実績データ、投資できない現実。少ない投資で最大限のパフォーマンスを得るにはどうするか?他のユーザーはどうしているか?3. データ量の
増加
アプリケーションやサービスの高度化・多様化への対応
基幹DB
トランザクション 88%
ログ・データ 73%
イベント 59%
Eメール 57%
ソーシャル・メディア 43%
センサー 42%
外部フィード 42%
RFIDスキャンまたはPOSデータ 41%
フリー・フォーム・テキ
スト 41%
地理情報 40%
音声 38%
静止画/ビデオ 34% すでにビッグデータに取り組んでいる組織に占める割合
( )
組織における
ビッグデータに対する
積極的な取り組みの
一環として、
現在収集して分析している
データ・ソースについて
質問した。
2012年、IBM Institute for Business Valueとサイード・ビジネス・スクールが共同で、
全世界のビッグデータに対する取り組みを調査
13. 例)集計・分析業務で実行されるクエリー
-- Query 02 - Minimum Cost Supplier Query
select
s_acctbal,
s_name,
n_name,
p_partkey,
p_mfgr,
s_address,
s_phone,
s_comment
from
tpcd.part,
tpcd.supplier,
tpcd.partsupp,
tpcd.nation,
tpcd.region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 15
and p_type like '%BRASS'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE‘
and ps_supplycost = (
select
min(ps_supplycost)
from
tpcd.partsupp,
tpcd.supplier,
tpcd.nation,
tpcd.region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
)
order by
s_acctbal desc,
n_name,
s_name,
p_partkey
fetch first 100 rows only
;
サンプルクエリ ー
特定の部品を特定地域から注文する場合の、最もコスト低い取引先一覧を取得しよう
とするクエリー。
4つの表を結合する副照会と、5つの表の結合処理とが組み合わさっています。
27. 27
(参考)MP Performance 4 Processor
Commercial Workload: OLTP, Decision Support (Database),
Search Engine
• True sharing and
false sharing
unchanged going
from 1 MB to 8 MB
(L3 cache)
• Uniprocessor cache
misses
improve with
cache size increase
(Instruction,
Capacity/Conflict,
Compulsory)
28. 28
(参考)MP Performance 2MB Cache
Commercial Workload: OLTP, Decision Support
(Database), Search Engine
• True sharing,
false sharing
increase going
from 1 to 8
CPUs
31. 必要なデータのみにアクセスする
一定のデータ件数毎に、各列に出現し
たデータの最大値と最小値を保持
条件に適合しないデータブロックは自動
的にスキップ
本当に必要なデータだけを読み込むこ
とにより、I/O量、メモリー容量、CPU時
間を大幅削減
発売日
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
ヒット!
圧縮データ
データ範囲のタグ
© 2013 IBM Corporation
必要なブロックだけがバッファープールに展開
アクセス頻度の高いデータが格納されている
インメモリー表ができあがる
35. © 2013 IBM Corporation
BLUアクセラレーションの特徴
メモリー
CPU
I/O 読み取りデータ量の削減
データ・スキッピング
メモリー使用量の削減
並列処理による
効率向上
CPU使用量の削減
強力な圧縮機能
CPU間並列処理
SIMDによるCPU内
並列処理
カラム・オーガナイズ表
ストレージ
格納データ量の削減
最適化される要素 テクノロジーの効果 BLUのテクノロジー
made by IBM研究所の
テクノロジー
36. BLUが実現する高速処理 - 非定型分析に強い
表名 データ件数
CUSTOMER 3,000,000
DATES 2,556
PART 1,400,000
SUPPLIER 200,000
LINEORDER 600,038,145
DB2 V10.5 / AIX 7.1、POWER 7 :
3.7GHz x 8core, 64 GB Memory
TPC-H で利用されるオブジェクトとデータを利用して
シンプルな集計処理の4つのクエリ(1~4)を作成し、
4つのクエリそれぞれに対し、照会範囲を変化させる
通常表(チューニング有り)と BLU表を比較
条件がばらついても、コンス
タントに速いBLU ( 平均5秒)
照会の軸、範囲が急遽変更
になってもNon Tuningで対
応可能
37. 同一基盤でのDB2 10.5(BLU) vs 他社性能比較Responsetime
BLU
他社DB
BLUでは、クエリ
ー形式の違いにか
かわらず安定した
パフォーマンス
DB2 10.5 BLUアクセラレーション 検索処理性能
お客様
クエリーの
スピード向上(平均)
大規模金融機関様 46.8 倍
グローバルISV様データマート 37.4 倍
BI (Cognos) 処理 18.0 倍
一般消費財ベンダー様 14.0 倍
39. DB2 BLU Design and Tuning
• Create Table
• Load data
DB2では表にデータをロードするのみで利用可能
CREATE TABLE T1 ( C1 int, C2 char(200)) ORGANIZED BY COLUMN
これだけ
索引や
サマリー表も
必要ない
アプライアンスに置き換える。ではなく、
汎用のRDBMSであるDB2の中で利用出来る
41. A社事例 : アドホッククエリの高速化
[目的]
全顧客情報を保有するDWHから作成される目的別データベース
(データマート)のレスポンス向上を目的とした更改
[要件]
ユーザー要件の変化への対応
(定型照会からBIツールによる非定型/アドホックな自由検索の増加)
同一データを利用するOLTP処理との共存
障害時の業務の継続性
既存IaaS環境の利用
上記の要件より、調査の結果、以下の技術は適合しないとの結論
NoSQL:データの一貫性が一部保てない
インメモリDBMS:障害発生時のデータ再ロードが必要でありデータの永続性が一部保てない
DWHアプライアンス(Nettezaテクノロジー):既存IaaS環境への適合ができず,また同一デー
タを利用するOLTP処理との共存に考慮が必要
検索・集計処理のパフォーマンス(同一環境で実機検証したパフォーマン
ス比較)、および処理特性に応じた最適なテーブル形式(行オーガナイズ表
/カラム・オーガナイズ表)を組み合わせて利用可能であることが評価ポイ
ントとなり、DB2 10.5 BLU Accelerationを採用
42. B社事例 : データマートのスモールスタート
[目的]
Webからのログを収集蓄積する分析基盤としてのDMの構築
[要件]
分析データの一元管理(データ一貫性の確保,集計差異等の混乱排除)
容易に集計・分析を実現できる基盤の構築
データ管理基盤として,今後の多様化への対応が可能であること
(追加拡張可能な基盤としての構築)
標準DBはPostgresSQLであったが、検索・集計処理のパフォーマンス(同一環境で実
機検証したパフォーマンス比較)、および処理特性に応じた最適なテーブル形式(行オ
ーガナイズ表/カラム・オーガナイズ表)を組み合わせて利用可能であることが評価ポ
イントとなり、DB2 10.5 BLU Accelerationを採用
43. 小中規模のデータマートにおける優先要件と
DB2 BLU Acceleration
データマートにおける優先要件 DB2 10.5 BLU Acceleration
高速性 アドホックな分析クエリーの高速性
○
BLU Acceleration Technology
により実現
複雑性 エンドユーザー部門の利用容易性/変更容易性
○
自動メンテナンス
自動チューニング
量 スモールスタート
○
RDBMSとしてスタートし、BLU
を機能として利用
クラウド環境でも利用可能
多様性 ミックスワークロードへの柔軟な対応
○
用途に応じて行表と列表を使
い分ける
別途製品を必要としないため、
小中規模の統合データベース
基盤としてのニーズを満たす