HIGIS 3/ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ資料/J_GrayA.ppt

(1)

株式会社日立製作所情報通信システム社 ITプラットフォーム事業本部 2015/4/9

Flashの採用はここまで進んでいる！

Oracle DB高速化事例のご紹介

(2)

お願い

スライド内容の撮影は禁止となっております。

甚だ恐縮ではございますが、写真撮影、録画、

録音等はご遠慮いただけますようお願い致し

ます。

お見かけした場合にはスタッフよりお声掛けさせて頂くことがございますが、予めご承知おきください。

(3)

１. なぜ、いまDBにFlashが必要なのか？２. ３. 事例のご紹介

なぜデータベースは遅くなるのか？

夜間バッチが突き抜けそう。今後データが増えたらまずいぞ・・・・チューニングしろと言われても、どこにボトルネックがあるのか？通常業務だけでも目一杯なのに分析もやれと言われた。耐えられるのか？１-１. データベースにとって高速化はもはや必然

(6)

１-２. その遅さ、I/O速度が原因では？ 1 10 20 相対性能 2005 2006 2007 2008 2009 2010 2011 5 15 2012 25 30 2013 HDD回転数 1倍 4core 6core 2core 32倍 8core 12core ※CPU性能はSAP SDベンチマークをベースにした値  取り残されたＨＤＤ性能  HDDにおいて今後ドラスティックな高性能技術の出現は望めない

ストレージI/Oの高速化により

システム性能が劇的に向上する可能性

(7)

産業系お客様１-３. 自動ワークロード・リポジトリによる待機イベント把握信販系お客様銀行系お客様産業系お客様ストレージへのランダムアクセス待ち時間が大半になっているケースが多い

db file sequential read

db file scattered read db file parallel read gc cr grant 2-way DB CPU

db file sequential read db file parallel read read by other session SQL*Net more data to client DB CPU

db file sequential read log file parallel write log file sync

enq: TX - row lock contention CPU time

db file sequential read db file scattered read db file parallel read read by other session CPU time

I/O待機 93％ I/O待機 81％

I/O待機 86％

I/O待機

39％

db file sequential read ：索引を使用してディスクからブロックを取得する際に発生する待機イベント db file scattered read ：表をスキャンする時に発生する待機イベント

(8)

HAF SSD SAS HDD 1 ※性能・時間は構成/使用条件により異なる場合があります。ランダムWRITE (7D+1P, 8KB)のＩＯＰＳ相対比較

119

15

ランダムREAD (7D+1P, 8KB)のＩＯＰＳ相対比較

207

61

１-４. FlashはランダムRead/Writeに強い DBアクセスの大半がランダムREAD/WRITE。Flashの効果は出やすい SSD SAS HDD 1 HAF

HAF : Hitachi Accelerated Flash 大容量、高速アクセスを特徴とした日立自製のFlashドライブ。

(9)

２-１. 実証実験でのFlash化の効果お客様と実施したFlash置換え検証にて抜群の効果実証実験によるDB高速化ソリューションの効果業務により異なるが劇的な高速化を確認業種システム業務内容性能比製造業 ERP 生産管理バッチ 10倍金融業 BI 検索系処理 4～320倍金融業財務処理業務処理最大20倍/平均5.8倍通信業分析 DBロード処理 20倍流通業商品管理データ加工処理 100～230倍

(11)

２-２. 顧客事例生産管理バッチ[導入効果] ＳＡＰＥＲＰで購買・生産管理を実施しており、夜間バッチに時間がかかり過ぎていた。事業所統合や海外部門の統合を控え、夜間バッチ突き抜けの懸念が本格化。

生産管理システム夜間バッチ高速化

ＨＤＤ 22:00 23:00 24:00 1:00 2:00 3:00 4:00 夜間バッチが大幅に短縮され従来の半分程度の時間で終了。特に３時間半以上の長いデータ連携処理バッチが１８％の３６分に。Ｆｌａｓｈ(ＨＡＦ) 22:00 23:00 24:00 1:00 2:00 3:00 4:00 39% 18% 22% 36%

(12)

産業系お客様夜間バッチ高速化

２-２. 顧客事例生産管理バッチ[導入効果] 続きＥＲＰサーバＡＥＲＰサーバＢ月Ｉ/Ｏ待ちＣＰＵ使用率切り替え切り替え Flash切り替え後、I/O待ち時間が大幅に削減されている

(13)

３-１. TIPS1： FLASHの高速性を効果的に活用しようインフラ系お客様の実証検証にて Flash化によりオンライン処理が大幅に高速化 BI処理を同時に実行するとレスポンスが3倍に劣化 - CPUはI/O待ちが高割合 - Flashは1ms以下で応答（ストレージ内統計）

なぜ？？

答えはI/O帯域 - オンラインは、多重度(IOPS)が重要 - 分析処理は帯域を使う。検証環境が8Gbps×2本だったため、分析処理が少ない帯域を使い果たしてしまった。

TIPS1：Flash化したらI/Oの通り道に気を付けよう

サーバ P P ストレージコントローラコントローラ P P P P P P P P RAID構成日立はI/O経路全体を考慮したFlash構成をご提案可能です。

(15)

３-２. TIPS2 非定型分析ではIn-Memoryを活用分析業務は、

定型

分析から

非定型

分析へ広がっている非定型分析：予めどんなSQLが入ってくるか分からない処理ビッグデータに代表されるデータ利活用のニーズを受けて増加非定型分析の課題・分析対象が分からないため列に索引を付けられない。・索引がない列にアクセスすると、原則「全表スキャン」になる。

大量I/O発生。Flashでも負荷が大きい。

Oracle Database 12c In-Memory

メモリ上に列格納データを展開し分析SQLを高速に処理する

(16)

３-３. Oracle Database 12c In-Memoryの実力 In-Memoryの非定型分析処理の実力非定型分析処理（索引なし）で効果を発揮【検証構成】・サーバ：BladeSymphony BS2000 CPU：Xeon E5-2690v2 x2 10コア/20スレッド Memory：256GB （In-Memory時はDBを全て格納）

・ストレージ：Hitachi Unified Storage VM（HUS VM） HDD：RAID6(6D+2P) 7.2Krpm HDD 非定型分析SQLの検証結果 In-Memory

_{約22倍高速}

データ利活用で求められる処理・データ追加や削除（バッチ処理）・名寄せ（アップデート）・通常のデータ参照・レポート出力・大量データのメモリ読込み

非定型検索以外のこれらの処理も高速化が必要

(17)

行（ロー）フォーマット（従来のDBバッファキャッシュ）列（カラムナ）フォーマット（インメモリ・カラムストア）行方向の処理オンライン処理ストレージ Oracle DBのメモリ空間定型分析処理列方向の処理非定型分析処理３-４. Ｆｌａｓｈ＆Ｉｎ-Ｍｅｍｏｒｙの強み Flashで高速化 In-Memoryで高速化 バッチ処理 同期

FlashとIn-Memoryの組み合わせにより、データ利活用

に関わる多くの処理を高速化可能

In-Memoryのアーキテクチャ（ローとカラムのデュアルフォーマット）

(18)

４-１. コストパフォーマンスに優れるハイブリッド構成 Tier1 （フラッシュドライブ） Tier2 （SAS）高速、小容量 Tier3 （NLSAS）ストレージプールストレージにおまかせデータのアクセス頻度をモニタリングし、アクセス頻度に合わせてストレージがデータを自動的に最適配置性能コスト性能/コストコストパフォーマンス Flash比率 HDT使用時のコストパフォーマンス格納先メディア例最適なFlash 搭載比率ストレージの機能にてアクティブなデータは自動的にFlashへ、それ以外をHDDへ企業システムは履歴を扱うため、アクセスは最近のデータに集中アクセス頻度の高いデータだけをFlashへ、その他をHDDに配置できればコストパフォーマンスが良くなる。

(20)

４-２. HDTによるコストパフォーマンス最適化検証結果 OracleDBとHDTの組み合わせでコストパフォーマンスの高いDBへ ALL-HDD HDT(25%) ALL-SSD トランザクション処理数/分 HDD：700G SSD： - HDD： 525GB SSD： 175GB HDD： - _{SSD： 700GB} HDT （SSD：25%） Flash （SSD：100%） HDD （SSD：0%）【検証構成】・サーバ：BladeSymphony BS2000 CPU：Xeon E5690 x2 12コア/24スレッド Memory：96GB

・ストレージ：Hitachi Unified Storage 130（HUS 130） HDD：RAID5(4D+1P)×4 15Krpm Flash：SSD RAID5（6D+1P）×4 ・アプリケーション物流倉庫を模したオンラインベンチマーク

アクセス頻度の高い部分にのみFlashを効果的に割当。

25％のSSDで、100％SSDとほぼ同等のパフォーマンス。

(21)

４-３. 必要な時にFlashを追加しよう HDTを有効にしておけば、最初はHDDだけで開始してもアクセス頻度を監視します。必要な時にFlashを追加すれば・・・・ HDDのみのHDTで導入アクセス頻度管理されている。 Before 管理情報を用いて高アクセス部分を Flashに移動。パフォーマンス良好

HDDで開始しても、必要に応じてFlashを追加可能。

高アクセス頻度部分を業務無停止で移動でき、性能

向上可能。投資コストのさらなる最適化が実現します。

Now 業務を追加。全体の20％にアクセス急増パフォーマンス劣化 Flashを追加 Future パフォーマンス向上

(22)

５-１. デモンストレーション概要性能比較とFlash追加の観点の二つのデモンストレーション HDD Flash 【性能比較】オンライン処理が増大していくDB 【簡単追加】DB無停止でHDDからHybrid構成に HDD Hybrid(Flash+HDD) 仮想LU HDD、Flashはそれぞれどのような 挙動になるのか？ 後からでもFlashを簡単に追加 DEMO1. Flashの性能とHDDの限界 DEMO2. これからのFlashはこう使おう

(24)

５-２．ＤＥＭＯ１【性能比較】オンライン処理が増大するＤＢ増え続ける処理をHDDとFlashのDBで測定 HDD Flash SELECT INSERT INSERT SELECT INSERT INSERT ・ディスク以外の条件は同じ・物流倉庫を模したオンラインベンチマークDB（320GB）・ReadとWriteがバランスよく実行されるユーザが増え、トランザクション投入量が増加していくと・・・

(25)

５-３．ＤＥＭＯ１【性能比較】オンライン処理が増大するＤＢ

(26)

秒間トランザクション処理数と投入量の推移

(27)

Transaction投入量 Transaction_Response投入量５-３．ＤＥＭＯ１【性能比較】オンライン処理が増大するＤＢ

HDD環境

Flash環境

Response TPS 5000 4000 3000 2000 1000 Transaction/s 3000 2000 1000 Transaction/s Response 5000 4000 3000 2000 1000 [Time] 3000 2000 1000 [Time] [Time] [Time] Response TPS [ms] [ms] 100ms 3400ms ₄₄₀₀ 480 [tps] [tps] HDDでは実行トランザクション数が頭打ち Flashでは投入量に実行数が追従 Transaction 投入量急増 Transaction _{投入量急増} 頭打ち Transaction投入量に実行数が追従

(28)

(29)

増大するI/O負荷に耐えられない処理量の増大に負けない安定したレスポンス

Transaction

投入量急増 Transaction _{投入量急増}

(30)

DB ５-４．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成にオンライン処理をしながら必要なデータだけがFlash領域に自動移動 SELECT INSERT ・物流倉庫を模したオンラインベンチマークDB（320GB）・処理開始時はHDDのみ搭載・処理途中でFlashを追加 _{処理途中でFlash領域を追加} Tier1 Tier2 HDD Flash HDT

(31)

５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に

HDDのみで稼働

DEMO2はトランザクション量はテストを通じて一定（HDDでは頭打ち、SSDではまだ余裕あり）

(32)

５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に

DEMO2はトランザクション量はテストを通じて一定（HDDでは頭打ち、SSDではまだ余裕あり）

(33)

５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に HDD Hybrid（HDD+Flash）

オンライン処理を継続したまま、Flashの性能に変更可能

5000 4000 3000 2000 1000 0 3000 2000 0 1000 Flashのスピードで安定 [ms] [tps] DEMO2はトランザクション量はテストを通じて一定（HDDでは頭打ち、SSDではまだ余裕あり）

(34)

５-６．まとめ

Flashの性能は業務を変える、採用事例も急激に

増えている

これからのFlashの使い方は、仮想化・階層化による

簡単高速化

ビッグデータ・クラウド時代の要求に最適なDB

インフラの採用を

24h 365Day 最適なコストパフォーマンス変化への迅速な対応

(35)

６-１. アセスメントサービスのご紹介 Oracle on Flash アセスメントサービス性能追求モデル内蔵Flashモデルかんたん高速モデルセットモデル OracleシステムへのFlashの導入効果を推定検証支援サービス設計コンサルティングサービスベストなFlash構成決定のお手伝い I/Oネックかどうかわからない自社のシステムでの効果はどれくらいだろうか・・・貴社のOracleをI/Oの観点で診断 Flash導入効果を予測します！ Oracle DBがI/Oネックで遅い場合 Flash導入で大きな効果、でも… ストレージのみ交換 FLASH搭載ストレージ FLASH性能を最大化短期間、コスト重視日立ならOracleからストレージまで、 DBシステムの課題を見える化できます。 OS Oracle Storage

(37)

１．DB待機イベント割合２．DB待機イベントのレスポンス１．HDD構成ではディスクI/O系の待機イベントがDB全体の93％を占めており、I/Oがボトルネックになっています。 Flash化によりディスクI/O系の待機イベントは30％まで減少し、I/Oボトルネックは減少しています。２．I/O系待機イベントのレスポンスではHDD構成の場合、キャッシュミスによる32ms以上かかるI/Oが 30％程度あり、HDDがボトルネックになっています。Flash化によりキャッシュミス時のI/Oも4ms 以下がほとんどになっています。 HDD/Flash比較サマリー 93.2% 5.9% 1.4%

0.2% db file scattered read 連続した複数ブロック読込 DB CPU

CPU演算 gc cr multi block request クラスタによる待機 db file sequential read 単一ブロック読込 59.1% 30.4% 17.2% 3.5% DB CPU CPU演算 db file scattered read 連続した複数ブロック読込 gc cr multi block request クラスタによる待機 Others

93.2% 5.9%

1.4%

0.2% db file scattered read 連続した複数ブロック読込 DB CPU

CPU演算

gc cr multi block request クラスタによる待機 db file sequential read 単一ブロック読込 59.1% 30.4% 17.2% 3.5% DB CPU CPU演算 db file scattered read 連続した複数ブロック読込 gc cr multi block request クラスタによる待機 Others 0% 20% 40% 60% 80% 100% <1ms <2ms <4ms <8ms <16ms<32ms <=1s >1s 待機時間

HDD (db file scattered read) HDD (db file sequential read) Flash (db file scattered read) Flash (db file sequential read)

HDD構成 Flash構成 0 100 200 300 400 500 HDD Flash 待機時間(sec) _{Flash導入時の効果推定} Others

db file sequential read 単一ブロック読込 gc cr multi block request クラスタによる待機 db file scattered read 連続した複数ブロック読込 DB CPU CPU演算 Flash化により、DB以下レイヤーの処理性能は約9倍程度になると推測されます。約9倍程度の処理性能向上 0 100 200 300 400 500 600 HDD Flash Flash導入時の効果推定 Others

gc cr multi block request クラスタによる待機 db file scattered read 連続した複数ブロック読込 DB CPU

CPU演算

db file sequential read 単一ブロック読込 24% 46% 14% 13% 3%

db file sequential read 単一ブロック読込 DB CPU CPU演算 db file scattered read 連続した複数ブロック読込

gc cr multi block request クラスタによる待機 Others 76% 12% 7% 4% 1%

gc cr multi block request クラスタによる待機 Others ６-２. Ｆｌａｓｈの効果を診断してみませんか？ Oracle on Flash アセスメントサービス Oracleの統計レポート（AWR）を分析しFlash導入効果を推定

Oracle統計から効果ありと予測！

(38)

６-３. 日立とオラクル様のアライアンス

◆ グローバルで９社、国内は日立含め２社！日立はオラクル様と最上位のパートナ関係

◆日立はオラクル様とのアライアンスをより強固にし、お客様に最高のパフォーマンスを提供していきます。

(39)

• HITACHIは、（株）日立製作所の登録商標です。

• OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。 • Intel Xeonは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。

• SAP，および本文書に記載されたその他の SAP 製品，サービス，ならびにそれぞれのロゴは，ドイツおよびその他の国々における SAP AG の商標または登録商標です。

• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。

ご清聴ありがとうございました。

(40)

END

株式会社日立製作所情報通信システム社 ITプラットフォーム事業本部 2015/4/9

Flashの採用はここまで進んでいる！

Oracle DB高速化事例のご紹介

(41)

(42)

HIGIS 3/ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ資料/J_GrayA.ppt

Flashの採用はここまで進んでいる！

Oracle DB高速化事例のご紹介

スライド内容の撮影は禁止となっております。

甚だ恐縮ではございますが、写真撮影、録画、

録音等はご遠慮いただけますようお願い致し

ます。

Contents

Contents

なぜデータベースは遅くなるのか？

ストレージI/Oの高速化により

システム性能が劇的に向上する可能性

119

15

207

61

Contents

生産管理システム夜間バッチ高速化

産業系お客様 夜間バッチ高速化

Contents

なぜ？？

TIPS1：Flash化したらI/Oの通り道に気を付けよう

定型

非定型

大量I/O発生。Flashでも負荷が大きい。

Oracle Database 12c In-Memory

約22倍高速

非定型検索以外のこれらの処理も高速化が必要

FlashとIn-Memoryの組み合わせにより、データ利活用

に関わる多くの処理を高速化可能

Contents

アクセス頻度の高い部分にのみFlashを効果的に割当。

25％のSSDで、100％SSDとほぼ同等のパフォーマンス。

HDDで開始しても、必要に応じてFlashを追加可能。

高アクセス頻度部分を業務無停止で移動でき、性能

向上可能。投資コストのさらなる最適化が実現します。

Contents

HDD環境

Flash環境

オンライン処理を継続したまま、Flashの性能に変更可能

Flashの性能は業務を変える、採用事例も急激に

増えている

これからのFlashの使い方は、仮想化・階層化による

簡単高速化

ビッグデータ・クラウド時代の要求に最適なDB

インフラの採用を

Contents

Oracle統計から効果ありと予測！

ご清聴ありがとうございました。

END

Flashの採用はここまで進んでいる！

Oracle DB高速化事例のご紹介

産業系お客様夜間バッチ高速化

_{約22倍高速}