Flashの採用はここまで進んでいる！ Oracle DB高速化事例のご紹介 2015/4/9 株式会社日立製作所 情報通信システム社 ITプラットフォーム事業本部 © Hitachi, Ltd. 2015. All rights reserved. お願い スライド内容の撮影は禁止となっております。 甚だ恐縮ではございますが、写真撮影、録画、 録音等はご遠慮いただけますようお願い致し ます。 お見かけした場合にはスタッフよりお声掛けさせて頂く ことがございますが、予めご承知おきください。 © Hitachi, Ltd. 2015. All rights reserved. 1 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 2 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 3 １-１. データベースにとって高速化はもはや必然 データの増加、ビッグデータ分析、データベース統合等により、 データベース処理への要求は急激に増加 通常業務だけでも目一杯 なのに分析もやれと言われた。 耐えられるのか？ 夜間バッチが突き抜け そう。今後データが増えたら まずいぞ・・・・ ＤＢ担当者 チューニングしろと言われ ても、どこにボトルネックが あるのか？ なぜデータベースは遅くなるのか？ © Hitachi, Ltd. 2015. All rights reserved. 4 １-２. その遅さ、I/O速度が原因では？ 32倍 相対性能 30 12core 25 8core 20 15 6core 10 5 2core 1 2005 2006 4core HDD回転数 2007 2008 2009 2010 2011 2012 1倍 2013 ※CPU性能はSAP SDベンチ マークをベースにした値 取り残されたＨＤＤ性能 HDDにおいて今後ドラスティックな高性能技術の出現は望めない ストレージI/Oの高速化により システム性能が劇的に向上する可能性 © Hitachi, Ltd. 2015. All rights reserved. 5 １-３. 自動ワークロード・リポジトリによる待機イベント把握 産業系お客様 銀行系お客様 I/O待機 93％ db file sequential read db file sequential read db file scattered read log file parallel write db file parallel read log file sync gc cr grant 2-way I/O待機 81％ DB CPU CPU time 産業系お客様 信販系お客様 db file sequential read db file sequential read I/O待機 86％ enq: TX - row lock contention db file scattered read I/O待機 db file parallel read db file parallel read 39％ read by other session read by other session SQL*Net more data to client CPU time DB CPU db file sequential read ： 索引を使用してディスクからブロックを取得する際に発生する待機イベント db file scattered read ： 表をスキャンする時に発生する待機イベント ストレージへのランダムアクセス待ち時間が大半になっているケースが多い © Hitachi, Ltd. 2015. All rights reserved. １-４. FlashはランダムRead/Writeに強い DBアクセスの大半がランダムREAD/WRITE。Flashの効果は出やすい ランダムWRITE (7D+1P, 8KB)のＩＯＰＳ相対比較 SAS HDD 1 15 SSD 119 HAF ランダムREAD (7D+1P, 8KB)のＩＯＰＳ相対比較 SAS HDD SSD HAF : Hitachi Accelerated Flash 大容量、高速アクセスを特徴とした 日立自製のFlashドライブ。 1 61 HAF ※性能・時間は構成/使用条件により異なる場合があります。 ※HAFはHitachi Virtual Storage PlatformでFlash accelerationを適用した場合の値です。 207 © Hitachi, Ltd. 2015. All rights reserved. 7 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 8 ２-１. 実証実験でのFlash化の効果 お客様と実施したFlash置換え検証にて抜群の効果 実証実験によるDB高速化ソリューションの効果 業種 システム ERP 製造業 BI 金融業 業務内容 生産管理バッチ 性能比 10倍 検索系処理 4～320倍 金融業 財務処理 業務処理 最大20倍/平均5.8倍 通信業 分析 DBロード処理 20倍 流通業 商品管理 データ加工処理 100～230倍 業務により異なるが劇的な高速化を確認 © Hitachi, Ltd. 2015. All rights reserved. 9 ２-２. 顧客事例 生産管理バッチ[導入効果] 生産管理システム夜間バッチ高速化 ＳＡＰ ＥＲＰで購買・生産管理を実施しており、夜間バッチに時間がかかり過ぎていた。 事業所統合や海外部門の統合を控え、夜間バッチ突き抜けの懸念が本格化。 ＨＤＤ Ｆｌａｓｈ(ＨＡＦ) 39% 18% 22% 36% 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 夜間バッチが大幅に短縮され従来の半分程度の時間で終了。 特に３時間半以上の長いデータ連携処理バッチが１８％の３６分に。 © Hitachi, Ltd. 2015. All rights reserved. 10 ２-２. 顧客事例 生産管理バッチ[導入効果] 続き 産業系お客様 夜間バッチ高速化 ＥＲＰサーバＡ ＥＲＰサーバＢ Ｉ/Ｏ 待ち 月 ＣＰＵ 使用率 切り替え 切り替え Flash切り替え後、I/O待ち時間が大幅に削減されている © Hitachi, Ltd. 2015. All rights reserved. 11 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 12 ３-１. TIPS1： FLASHの高速性を効果的に活用しよう インフラ系お客様の実証検証にて Flash化によりオンライン処理が大幅に高速化 BI処理を同時に実行すると レスポンスが3倍に劣化 サーバ なぜ？？ P P - CPUはI/O待ちが高割合 - Flashは1ms以下で応答（ストレージ内統計） 答えはI/O帯域 - オンラインは、多重度(IOPS)が重要 - 分析処理は帯域を使う。 検証環境が8Gbps×2本だったため、 分析処理が少ない帯域を使い果たしてしまった。 P P P P コントローラ P P P P コントローラ RAID構成 ストレージ TIPS1：Flash化したらI/Oの通り道に気を付けよう 日立はI/O経路全体を考慮したFlash構成をご提案可能です。 © Hitachi, Ltd. 2015. All rights reserved. 13 ３-２. TIPS2 非定型分析ではIn-Memoryを活用 分析業務は、定型分析から非定型分析へ広がっている 非定型分析 ： 予めどんなSQLが入ってくるか分からない処理 ビッグデータに代表されるデータ利活用のニーズを受けて増加 非定型分析の課題 ・ 分析対象が分からないため列に索引を付けられない。 ・ 索引がない列にアクセスすると、原則「全表スキャン」になる。 大量I/O発生。Flashでも負荷が大きい。 このような課題を解決するソリューション Oracle Database 12c In-Memory メモリ上に列格納データを展開し分析SQLを高速に処理する © Hitachi, Ltd. 2015. All rights reserved. 14 ３-３. 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 非定型分析SQLの検証結果 HDD In-Memory 約22倍高速 データ利活用で求められる処理 ・データ追加や削除（バッチ処理） ・名寄せ（アップデート） ・通常のデータ参照 ・レポート出力 ・大量データのメモリ読込み 非定型検索以外のこれらの処理も高速化が必要 © Hitachi, Ltd. 2015. All rights reserved. 15 ３-４. Ｆｌａｓｈ＆Ｉｎ-Ｍｅｍｏｒｙの強み In-Memoryのアーキテクチャ（ローとカラムのデュアルフォーマット） In-Memoryで高速化 Flashで高速化 行方向の処理 Oracle DBのメモリ空間 列方向の処理 オンライン処理 定型分析処理 非定型分析処理 同期 バッチ処理 行（ロー）フォーマット （従来のDBバッファキャッシュ） 列（カラムナ）フォーマット （インメモリ・カラムストア） ストレージ FlashとIn-Memoryの組み合わせにより、データ利活用 に関わる多くの処理を高速化可能 © Hitachi, Ltd. 2015. All rights reserved. 16 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 17 ４-１. コストパフォーマンスに優れるハイブリッド構成 企業システムは履歴を扱うため、アクセスは最近のデータに集中 アクセス頻度の高いデータだけをFlashへ、その他をHDDに配置 できればコストパフォーマンスが良くなる。 ストレージの機能にてアクティブなデータは自動的にFlashへ、それ以外をHDDへ HDT： Hitachi Dynamic Tiering 性能/コスト ストレージプール 性能 格納先メディア例 Tier1 （フラッシュ ドライブ） Tier2 （SAS） 高速、小容量 Tier3 （NLSAS） 低速、大容量 ストレージにおまかせ コスト データのアクセス頻度を モニタリングし、アクセス頻度に 合わせてストレージがデータを 自動的に最適配置 コストパフォーマンス 最適なFlash 搭載比率 Flash比率 HDT使用時のコストパフォーマンス © Hitachi, Ltd. 2015. All rights reserved. 18 ４-２. HDTによるコストパフォーマンス最適化 検証結果 OracleDBとHDTの組み合わせでコストパフォーマンスの高いDBへ 【検証構成】 ・サーバ：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 ・アプリケーション 物流倉庫を模したオンラインベンチマーク トランザクション処理数/分 HDD：700G SSD： - HDD： 525GB SSD： 175GB HDD ALL-HDD （SSD：0%） HDT HDT(25%) （SSD：25%） HDD： SSD： 700GB Flash ALL-SSD （SSD：100%） アクセス頻度の高い部分にのみFlashを効果的に割当。 25％のSSDで、100％SSDとほぼ同等のパフォーマンス。 © Hitachi, Ltd. 2015. All rights reserved. 19 ４-３. 必要な時にFlashを追加しよう HDTを有効にしておけば、最初はHDDだけで開始してもアクセス頻度を 監視します。必要な時にFlashを追加すれば・・・・ Before パフォーマンス良好 Now Future パフォーマンス劣化 パフォーマンス向上 Flashを追加 HDDのみのHDTで導入 アクセス頻度管理され ている。 業務を追加。 全体の20％に アクセス急増 管理情報を用いて 高アクセス部分を Flashに移動。 HDDで開始しても、必要に応じてFlashを追加可能。 高アクセス頻度部分を業務無停止で移動でき、性能 向上可能。投資コストのさらなる最適化が実現します。 OSやOracleの操作は一切不要。デモにて確認頂けます。 © Hitachi, Ltd. 2015. All rights reserved. 20 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. 性能改善TIPS ４. FlashとHDDの混在によるコスト最適化 ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 21 ５-１. デモンストレーション概要 性能比較とFlash追加の観点の二つのデモンストレーション DEMO1. Flashの性能とHDDの限界 DEMO2. これからのFlashはこう使おう 【性能比較】オンライン処理が増大していくDB 【簡単追加】DB無停止でHDDからHybrid構成に 仮想LU HDD Flash HDD、Flashはそれぞれどのような 挙動になるのか？ HDD Hybrid(Flash+HDD) 後からでもFlashを簡単に追加 できるシステムとは。 © Hitachi, Ltd. 2015. All rights reserved. 22 ５-２．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ 増え続ける処理をHDDとFlashのDBで測定 ・ディスク以外の条件は同じ ・物流倉庫を模したオンラインベンチマークDB（320GB） ・ReadとWriteがバランスよく実行される ユーザが増え、トランザクション 投入量が増加していくと・・・ SELECT INSERT HDD SELECT INSERT INSERT INSERT Flash © Hitachi, Ltd. 2015. All rights reserved. 23 ５-３．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ 秒間トランザクション処理数と投入量の推移 TPS： Transaction Per Second 単位時間当たりの実行トランザクション数 © Hitachi, Ltd. 2015. All rights reserved. 24 ５-３．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ 秒間トランザクション処理数と投入量の推移 2500 TPS： Transaction Per Second 単位時間当たりの実行トランザクション数 © Hitachi, Ltd. 2015. All rights reserved. 25 ５-３．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ Transaction/s Transaction/s [tps] [tps] 5000 5000 4000 4000 3000 頭打ち Transaction投入量に 実行数が追従 3000 2000 2000 1000 1000 [Time] TPS 480 [Time] Response 3400ms TPS Transaction 投入量 Response 4400 Response 100ms Response Transaction 投入量 [ms] [ms] 3000 Transaction 3000 2000 投入量急増 Transaction 2000 投入量急増 1000 1000 [Time] HDD環境 HDDでは実行トランザクション数が頭打ち TPS： Transaction Per Second 単位時間当たりの実行トランザクション数 [Time] Flash環境 Flashでは投入量に実行数が追従 © Hitachi, Ltd. 2015. All rights reserved. 26 ５-３．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ 秒間トランザクション処理数とレスポンス（トランザクション）の推移 TPS： Transaction Per Second 単位時間当たりの実行トランザクション数 © Hitachi, Ltd. 2015. All rights reserved. 27 ５-３．ＤＥＭＯ１ 【性能比較】オンライン処理が増大するＤＢ Transaction Transaction 投入量急増 投入量急増 安定したレスポンス 増大するI/O負荷に耐えられない 処理量の増大に負けない安定したレスポンス TPS： Transaction Per Second 単位時間当たりの実行トランザクション数 © Hitachi, Ltd. 2015. All rights reserved. 28 ５-４．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に オンライン処理をしながら必要なデータだけがFlash領域に自動移動 ・物流倉庫を模したオンラインベンチマークDB（320GB） ・処理開始時はHDDのみ搭載 ・処理途中でFlashを追加 処理途中でFlash領域を追加 INSERT SELECT DB Tier1 Flash HDT Tier2 HDD © Hitachi, Ltd. 2015. All rights reserved. 29 ５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に HDDのみで稼働 DEMO2はトランザクション量はテストを通じて一定 （HDDでは頭打ち、SSDではまだ余裕あり） © Hitachi, Ltd. 2015. All rights reserved. 30 ５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に DEMO2はトランザクション量はテストを通じて一定 （HDDでは頭打ち、SSDではまだ余裕あり） © Hitachi, Ltd. 2015. All rights reserved. 31 ５-５．ＤＥＭＯ２【簡単追加】ＤＢ無停止でＨＤＤからＨｙｂｒｉｄ構成に [tps] 5000 Flashのスピードで安定 4000 3000 2000 1000 0 [ms] 3000 2000 1000 0 DEMO2はトランザクション量はテストを通じて一定 （HDDでは頭打ち、SSDではまだ余裕あり） HDD Hybrid（HDD+Flash） オンライン処理を継続したまま、Flashの性能に変更可能 © Hitachi, Ltd. 2015. All rights reserved. 32 ５-６．まとめ Flashの性能は業務を変える、採用事例も急激に 増えている これからのFlashの使い方は、仮想化・階層化による 簡単高速化 ビッグデータ・クラウド時代の要求に最適なDB インフラの採用を 変化への 迅速な対応 24h 365Day 最適な コストパフォーマンス © Hitachi, Ltd. 2015. All rights reserved. 33 Contents １. なぜ、いまDBにFlashが必要なのか？ ２. 事例のご紹介 ３. ＯｒａｃｌｅＤＢにおけるＨＲＴの検証結果 ４. パフォーマンスだけでよいのか？ ５. デモンストレーション ６. 最後に © Hitachi, Ltd. 2015. All rights reserved. 34 ６-１. アセスメントサービスのご紹介 Oracle DBがI/Oネックで遅い場合 Flash導入で大きな効果、でも… I/Oネックか どうかわからない 日立ならOracleからストレージまで、 DBシステムの課題を見える化できます。 貴社のOracleをI/Oの観点で診断 Flash導入効果を予測します！ 自社のシステム での効果はどれくらい だろうか・・・ Oracle OS OracleシステムへのFlashの導入効果を推定 FLASH性能を最大化 Oracle on Flash アセスメントサービス セットモデル Storage 短期間、コスト重視 ストレージのみ交換 性能追求モデル ベストなFlash構成決定のお手伝い 検証支援サービス 設計コンサルティングサービス FLASH搭載ストレージ かんたん高速モデル 内蔵Flashモデル © Hitachi, Ltd. 2015. All rights reserved. 35 ６-２. Ｆｌａｓｈの効果を診断してみませんか？ HDD/Flash比較サマリー Oracle on Flash アセスメントサービス １．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 以下がほとんどになっています。 １．DB待機イベント割合 4% 1% 1.4% 3.5% 3.5%3% 0.2% db file sequential read 7% 13% 5.9% 1% 4%1.4% 5.9% 7% 0.2% 12% 12% 単一ブロック読込 db file scattered read 連続した複数ブロック読込 DB CPU 24% 17.2% CPU演算 DB CPU 17.2% CPU演算 db file scattered read 14% gc cr連続した複数ブロック読 multi block request 59.1% クラスタによる待機 込 gc cr multi block request 59.1% 30.4% db file sequential read クラスタによる待機 76% 単一ブロック読込 46% 93.2% Others 30.4% ２．DB待機イベントのレスポンス db file sequential read 単一ブロック読込 dbfile file sequential db scatteredread read 単一ブロック読込 DB CPU DB CPU 連続した複数ブロック読込 DB CPU CPU演算 DB CPU CPU演算 CPU演算 DB CPU 100% HDD (db file scattered read) HDD (db file sequential read) Flash (db file scattered read) Flash (db file sequential read) 80% CPU演算 dbCPU演算 file scattered read db scattered read dbfile file scattered read 連続した複数ブロック読込 db file scattered read 連続した複数ブロック読 連続した複数ブロック読 gc cr multi block request 連続した複数ブロック読込 込multi block request gc込 cr gc cr multi block request クラスタによる待機 クラスタによる待機 gc cr multi block request クラスタによる待機 gc cr multi block request 60% 40% Oracle統計から効果ありと予測！ 93.2% 76% HDD構成 20% 0% <1ms <2ms <4ms <8ms <16ms<32ms <=1s Flash構成 待機時間(sec) 500 600 500400 400300 300200 200 100 100 0 0 クラスタによる待機 db file sequential read Others クラスタによる待機 Others 単一ブロック読込 Others Others >1s 待機時間 Flash導入時の効果推定 Flash導入時の効果推定 Others Others gc cr block request dbmulti file sequential read クラスタによる待機 単一ブロック読込 約9倍程度の 処理性能向上 gc crscattered multi block read request db file クラスタによる待機 連続した複数ブロック読込 db file scattered read DB CPU 連続した複数ブロック読込 CPU演算 DB CPU HDD HDD Flash Flash CPU演算 db file sequential read 単一ブロック読込 Flash化により、DB以下レイヤーの処理性能は約9倍程度になると推測されます。 Oracleの統計レポート（AWR）を分析しFlash導入効果を推定 © Hitachi, Ltd. 2015. All rights reserved. 36 ６-３. 日立とオラクル様のアライアンス 日立はオラクル様と最上位のパートナ関係 ◆ グローバルで９社、国内は日立含め２社！ ◆日立はオラクル様とのアライアンスをより強固にし、 お客様に最高のパフォーマンスを提供していきます。 © Hitachi, Ltd. 2015. All rights reserved. 37 他社商品名、商標等の引用に関する表示 ご清聴ありがとうございました。 • HITACHIは、（株）日立製作所の登録商標です。 • OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。 • Intel Xeonは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。 • SAP，および本文書に記載されたその他の SAP 製品，サービス，ならびにそれぞれのロゴは，ドイツおよび その他の国々における SAP AG の商標または登録商標です。 • その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。 • 製品の改良により予告なく記載されている仕様が変更になることがあります。 © Hitachi, Ltd. 2015. All rights reserved. 38 END Flashの採用はここまで進んでいる！ Oracle DB高速化事例のご紹介 2015/4/9 株式会社日立製作所 情報通信システム社 ITプラットフォーム事業本部 © Hitachi, Ltd. 2015. All rights reserved. 39
© Copyright 2024 ExpyDoc
