Download to read offline
![A社事例 ： アドホッククエリの高速化
[目的]
全顧客情報を保有するDWHから作成される目的別データベース
(データマート)のレスポンス向上を目的とした更改
[要件]
ユーザー要件の変化への対応
(定型照会からBIツールによる非定型/アドホックな自由検索の増加)
同一データを利用するOLTP処理との共存
障害時の業務の継続性
既存IaaS環境の利用
上記の要件より、調査の結果、以下の技術は適合しないとの結論
NoSQL：データの一貫性が一部保てない
インメモリDBMS：障害発生時のデータ再ロードが必要でありデータの永続性が一部保てない
DWHアプライアンス(Nettezaテクノロジー)：既存IaaS環境への適合ができず，また同一デー
タを利用するOLTP処理との共存に考慮が必要
検索・集計処理のパフォーマンス(同一環境で実機検証したパフォーマン
ス比較)、および処理特性に応じた最適なテーブル形式(行オーガナイズ表
/カラム・オーガナイズ表)を組み合わせて利用可能であることが評価ポイ
ントとなり、DB2 10.5 BLU Accelerationを採用](https://image.slidesharecdn.com/db2dbtechshowcase2014osa2-160329145728/85/slide-41-320.jpg)
![B社事例 ： データマートのスモールスタート
[目的]
Webからのログを収集蓄積する分析基盤としてのDMの構築
[要件]
分析データの一元管理(データ一貫性の確保，集計差異等の混乱排除)
容易に集計・分析を実現できる基盤の構築
データ管理基盤として,今後の多様化への対応が可能であること
(追加拡張可能な基盤としての構築)
標準DBはPostgresSQLであったが、検索・集計処理のパフォーマンス(同一環境で実
機検証したパフォーマンス比較)、および処理特性に応じた最適なテーブル形式(行オ
ーガナイズ表/カラム・オーガナイズ表)を組み合わせて利用可能であることが評価ポ
イントとなり、DB2 10.5 BLU Accelerationを採用](https://image.slidesharecdn.com/db2dbtechshowcase2014osa2-160329145728/85/slide-42-320.jpg)
増える実績データ、投資できない現実。少ない投資で最大限のパフォーマンスを得るにはどうするか？他のユーザーはどうしているか？
- 1.
- 2. Please note ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反 映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導 や助言を意図したものではなく、またそのような結果を生むものでもありません。本講演資料に含まれている情報につい ては、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保 証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる 損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤ ーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定 する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むものでもありませ ん。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれら が使用可能であることを暗示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場 機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将 来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含まれている内容 は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示する ことを意図したものでも、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境において 標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォー マンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処 理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで 述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成 した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があ ります。 IBM、IBM ロゴ、ibm.com、DB2、およびPureDataは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。 他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。 現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。
- 3. データ量の 増加 アプリケーションやサービスの高度化・多様化への対応 基幹DB トランザクション 88% ログ・データ 73% イベント59% Eメール 57% ソーシャル・メディア 43% センサー 42% 外部フィード 42% RFIDスキャンまたはPOSデータ 41% フリー・フォーム・テキ スト 41% 地理情報 40% 音声 38% 静止画/ビデオ 34% すでにビッグデータに取り組んでいる組織に占める割合 （ ） 組織における ビッグデータに対する 積極的な取り組みの 一環として、 現在収集して分析している データ・ソースについて 質問した。 2012年、IBM Institute for Business Valueとサイード・ビジネス・スクールが共同で、 全世界のビッグデータに対する取り組みを調査
- 4. 新マスターへ の統合 実績データの 集計 属性データの追加 実績データの 集計・分析 要件 商品や地域等 のカテゴリーを 切り口とした高 速検索 実績データの集 計およびレポート 作成 季節属性、揮発性 の高いサービス属 性など、正規化が 難しい属性データ の追加・拡張 蓄積された大量デー タの集計および分析。 レポート作成 必要な技術 および製品 ・データのパー ティション分割 ・並列処理 ・検索ワードに 関連した検索 ・データのパーテ ィション分割 ・集計クエリの並 列・分散処理 ・商品データと実 績データの関連 性の可視化 ・構造化データの格 納（JSONやXMLな ど） ・構造化データに対 するクエリ処理 ・NOSQLDB ・属性データも含め た関連性の可視化 ・データのパーティシ ョン分割またはデー タベースの分割 ・集計・分析の並列・ 分散処理 ・高速ストレージ ・インメモリ処理 ・高度な関連性の可 視化 ・利用ユーザー毎の パーソナライゼーシ ョン あるお客様の新システム移行ステップ 新マスタDB 実績DB NoSQLDB
- 5. 新マスターへ の統合 実績データの 集計 属性データの追加 実績データの 集計・分析 要件 商品や地域等 のカテゴリーを 切り口とした高 速検索 実績データの集 計およびレポート 作成 季節属性、揮発性 の高いサービス属 性など、正規化が 難しい属性データ の追加・拡張 蓄積された大量デー タの集計および分析。 レポート作成 必要な技術 および製品 ・データのパー ティション分割 ・並列処理 ・検索ワードに 関連した検索 ・データのパーテ ィション分割 ・集計クエリの並 列・分散処理 ・商品データと実 績データの関連 性の可視化 ・構造化データの格 納（JSONやXMLな ど） ・構造化データに対 するクエリ処理 ・NOSQLDB ・属性データも含め た関連性の可視化 ・データのパーティシ ョン分割またはデー タベースの分割 ・集計・分析の並列・ 分散処理 ・高速ストレージ ・インメモリ処理 ・高度な関連性の可 視化 ・利用ユーザー毎の パーソナライゼーシ ョン あるお客様の新システム移行ステップ 新マスタDB 実績DB NoSQLDB 新システム追加 新システム追加
- 6. 新マスターへ の統合 実績データの 集計 属性データの追加 実績データの 集計・分析 要件 商品や地域等 のカテゴリーを 切り口とした高 速検索 実績データの集 計およびレポート 作成 季節属性、揮発性 の高いサービス属 性など、正規化が 難しい属性データ の追加・拡張 蓄積された大量デー タの集計および分析。 レポート作成 必要な技術 および製品 ・データのパー ティション分割 ・並列処理 ・検索ワードに 関連した検索 ・データのパーテ ィション分割 ・集計クエリの並 列・分散処理 ・商品データと実 績データの関連 性の可視化 ・構造化データの格 納（JSONやXMLな ど） ・構造化データに対 するクエリ処理 ・NOSQLDB ・属性データも含め た関連性の可視化 ・データのパーティシ ョン分割またはデー タベースの分割 ・集計・分析の並列・ 分散処理 ・高速ストレージ ・インメモリ処理 ・高度な関連性の可 視化 ・利用ユーザー毎の パーソナライゼーシ ョン あるお客様の新システム移行ステップ 新マスタDB 実績DB NoSQLDB いまコ コを なんとかしたい！
- 7.
- 8. データストア毎の優先要件 情報系データストア データストアごとの優先要件 データマート 高速性 アドホックな分析クエリーの高速性 複雑性 エンドユーザー部門の利用容易性/変更容易 性 量スモールスタート 多様性 ミックスワークロードへの柔軟な対応 データウエアハウス 量 企業全体のデータを格納出来る大容量とスケ ーラビリティ 高速性 大量データのバッチ処理性能 複雑性 高可用性とパフォーマンス、スケーラビリティ の両立 多様性 バッチ処理、オンライン処理のミックスワークロ ードへのタイポ宇 ビッグデータ基盤 多様性 ストリーミングデータやWeb上のデータなど多 様かつ複雑なデータの分析 量 超大容量の非構造/半構造化データに対する 高速処理 高速性 データ急増に対応出来るスケーラビリティ 複雑性 ストリーミングデータやWeb上のデータなど、デ ータの種類に応じたリアルタイム性 データ量小 データ量大 構造化データ 非構造化データ
- 9. 小中規模のデータマートにおける優先要件と製品選定 データマートにおける優先要件 汎用RDBMS (MPP製品含む） DB2 Oracle SQLServer PostgresSQL MySQL など DWHアプライア ンス Netezza OracleExadata Tradata カラムストア型 DB SAP HANA SybaseIQ HP Vertica 高速性 アドホックな分析ク エリーの高速性 × 設計とチューニングが必須 ○ ○ 複雑性 エンドユーザー部 門の利用容易性/ 変更容易性 × クエリ高速化のために索引チ ューニングが必須であり、索 引の増大とメンテナンス負荷 有り ○ △ 汎用RDBMSと比 べ、スキル、リソ ース確保の観点 で難易度が高い 量 スモールスタート ○ × 大規模向けの製 品が主であり、ス モールスタートに 向かない ○ 多様性 ミックスワークロー ドへの柔軟な対応 ○ △ アプライアンスと して機能を特化 × 集計や分析処理 に特化している
- 10.
- 11.
- 12.
- 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つの表を結合する副照会と、５つの表の結合処理とが組み合わさっています。
- 14.
- 15.
- 16.
- 17. 複数パーティションにハッシュ分割 （データベース・パーティション） P 1 P2 P 3 ひとつのクエリーを複数のCPUを使っ て並列に処理することができる
- 18. データをレンジ分割して保存（パーティション表） P 1 Jan Feb Mar P 2P 3 条件に合致したパーティショ ンのみを参照すればよい パーティションの高速削除と 追加が可能
- 19. 各行をブロックに整理して保管 ※DB2 の 多次元クラスター表を利用 P1 Jan Feb Mar P 2 P 3 同じ値を持った行同士を同じ ブロックに集めて保管。 必要な行を取り出すための I/Oが最小限で済む
- 20. 各ブロックに格納される行数を増やす（圧縮） P 1 Jan Feb Mar P 2P 3 各ブロックにより多くの行を保管 し、ディスク容量の削減が可能。 必要な行を取り出すためのI/O がさらに少なくなる。
- 22. 列ストア 汎用RDBMSでの行ストア 列ストア型 参照処理における不要データの 読み込みをなくし、ディスクI/Oの 回数を削減 カラム内には特定のデータが繰り 返し現れることが多いので、圧縮 効率が良い 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 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 関係のない行まで読み込んでし まう 一つのブロックに様々なタイプの データが格納されている
- 23. 列ストア（イメージ） 列1 列2 列3列4 列5 列6 列ごとにデータをブロック化して格納 必要なデータを取り出すためのI/Oが少なくなる。
- 24. 列ストア （BLU Acceleration における最終的な格納イメージ） 列1 値の出現頻度も加味した圧縮 必要な行を取り出すためのI/Oがさらに少なくなる。 列2列3 列4 列5 列6 * X * Y *Z * X * Y *Z * X * Y *Z * X * Y *Z * X * Y *Z * X * Y *Z
- 26. 1985 33 MHz 3X 1989 100 MHz 3X 1993 233MHz >2X 1997 450 MHz 2X 1999 1.4 GHz >3X 2000 3.8 GHz > 2X 現在 3.2 GHz 2 cores 3.2 GHz 4 cores クロックアップの時代 時代はマルチコア クロックも限界？ （参考）CPUの進化
- 27. 27 （参考）MP Performance 4Processor 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 2MBCache Commercial Workload: OLTP, Decision Support (Database), Search Engine • True sharing, false sharing increase going from 1 to 8 CPUs
- 29.
- 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 必要なブロックだけがバッファープールに展開 アクセス頻度の高いデータが格納されている インメモリー表ができあがる
- 32. ダイナミック・イン・メモリー技術 ダイナミック・イン・メモリー技術でコンパクトなイン・メモリー・デー タベース環境を提供可能 1TB以上の Memory 128GBMemory 1TB Storage 1TB Storage 一般的なインメモリー技術 BLU Accelerationの ダイナミック・イン・メモリー技術 すべてのデータを メモリーに展開 使用頻度の高い、必 要なデータを メモリーに随時展開
- 34. 数TBのデータ 強化された圧縮技術 によりデータ容量を数 分の一に削減 複数CPUコアにて 並列にスキャン ベクトル処理(SIMD) により各 コア内で複数データを 一度に処理 数秒以内で 処理が完了 カラム・オーガナイ ズ表の必要な列に のみアクセス データ・スキッピングによ ってアクセス対象 絞り込み DATA DATA DATA DATA DATA DATA DATA DATA DATA DATA DATADATA DATA DATA DATA © 2013 IBM Corporation BLU Acceleration Technology
- 35. © 2013 IBMCorporation 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 倍
- 38. DB2は行ストアと列ストアが共存できる ランダムアクセスは非効率 OLTPには向かない DB2は混在可能 行ストア表と列ストア表をJOIN出来る 列ストア型 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
- 39. DB2 BLU Designand Tuning • Create Table • Load data DB2では表にデータをロードするのみで利用可能 CREATE TABLE T1 ( C1 int, C2 char(200)) ORGANIZED BY COLUMN これだけ 索引や サマリー表も 必要ない アプライアンスに置き換える。ではなく、 汎用のRDBMSであるDB2の中で利用出来る
- 40. 現行システムの方式との比較 DB2 BLUの導入により、利用部門からの要望に対し、従来の仕 組みと比べ、柔軟・迅速（即時性）にデータ抽出要求、データアク セス要求に応えられる DB 作業現行 DB2 BLU ①パーティション設計 ②テーブル作成 ③データロード ④チューニング ・インデックス・ サマリー表の設計 ・既存更新処理への 影響調査 ・インデックス作成 ・サマリー表作成 ・メモリーチューニング ・ヒント句の利用 【新規要件Ａ】 新しい業務要件で 新規のデータ項目 要望 【新規要件Ｂ】 別の軸での分析、集 計項目追加の依頼 【新規要件C】 自由検索したい 利用部門 必要なデータ提供 自由検索の許可 BLUによる 簡単・迅速化 こ こ の 作 業 が 不 要
- 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 を機能として利用 クラウド環境でも利用可能 多様性 ミックスワークロードへの柔軟な対応 ○ 用途に応じて行表と列表を使 い分ける 別途製品を必要としないため、 小中規模の統合データベース 基盤としてのニーズを満たす
- 44. 新マスターへ の統合 実績データの 集計 属性データの追加 実績データの 集計・分析 要件 商品や地域等 のカテゴリーを 切り口とした高 速検索 実績データの集 計およびレポート 作成 季節属性、揮発性 の高いサービス属 性など、正規化が 難しい属性データ の追加・拡張 蓄積された大量デー タの集計および分析。 レポート作成 必要な技術 および製品 ・データのパー ティション分割 ・並列処理 ・検索ワードに 関連した検索 ・データのパーテ ィション分割 ・集計クエリの並 列・分散処理 ・商品データと実 績データの関連 性の可視化 ・構造化データの格 納（JSONやXMLな ど） ・構造化データに対 するクエリ処理 ・NOSQLDB ・属性データも含め た関連性の可視化 ・データのパーティシ ョン分割またはデー タベースの分割 ・集計・分析の並列・ 分散処理 ・高速ストレージ ・インメモリ処理 ・高度な関連性の可 視化 ・利用ユーザー毎の パーソナライゼーシ ョン あるお客様の新システム移行ステップ すべてのステップをDB2 の機能で対応可能
- 45. Big Solution fromSmall BOX !