Microsoft Word - wp-impq-gridcenter-nec_v1.0.doc

Transcription

1 オラクル ホワイトペーパー 2010 年 3 月 Oracle Database 11g Release 2 In-Memory Parallel Query による NEC Express5800/ スケーラブル HA サーバ上での Data Warehouse システム全体の性能向上

2 はじめに 日本電気株式会社 ( 以降 NEC) は2006 年 7 月に 次世代 IT 基盤を実現するためのITプラットフォームビジョン REAL IT PLATFORM を発表しその指針に沿って 柔軟 安心 かつ 快適 なIT 基盤を実現する製品群を提供してきました 2009 年 10 月には従来のビジョンを元に 今後クラウド コンピューティングによって変化する企業のビジネスニーズに対して 的確に対応するため REAL IT PLATFORM Generation2 としてさらに進化させました REAL IT PLATFORM Generation2 においては 高効率インフラストラクチャ サービス実行基盤 システムサービス管理 の3 領域の製品およびサービスを強化しています 一方 日本オラクル株式会社 ( 以降 日本オラクル ) は Oracle Database 10gを発表した数年前よりグリッドコンピューティングを実現する Oracle GRID 技術を提供しています さらに 2006 年 11 月にはグリッドをベースとした次世代のビジネス ソリューション構築を目的として各協賛ベンダーとの共同の検証施設 Oracle GRID Center を設立しました NECと日本オラクルは20 年に渡る協業関係を基盤とし 次世代 ITインフラ基盤の実現に向けた開発レベルでの戦略協業 (STA:Strategic Technology Alliance) を推進しており NECは REAL IT PLATFORM Generation2 の具現化を強化するために Oracle GRID Center に参画し 共同検証を実施しております Oracle GRID Centerでは2009 年 11 月のOracle Database 11g Release 2 のリリースに向けて 協賛パートナーとともに新機能の事前検証プログラムを実施し 事前検証による検証結果を製品へフィードバックすることで製品を改善 さらに検証を通してリリース前段階から新機能について熟知することでリリースと同時に有効な使用法を提案可能になる活動を実施しました 本文書は NECとの活動での成果物になります

3 概要...3 Oracle 製品機能紹介...3 In-Memory Parallel Query...3 Oracle Partitioning...5 Oracle Databaseの表圧縮機能...7 プラットフォーム紹介...8 Express5800/ スケーラブルHAサーバ...8 検証環境...9 検証モデル...10 検証 1: 従来のPQとIn-Memory PQの比較...12 検証 2: In-Memory PQが適用可能な検索範囲の拡大...17 検証 2-1: NEC Express 5800/A1160のボックス追加による適用範囲の拡大...17 検証 2-2:Oracle Databaseの表圧縮機能による適用範囲の拡大...18 検証 3: In-Memory Parallel QueryによるDWHシステム全体の高速化...20 まとめ...24

4 概要 企業を取り巻く環境の変化はこれまでにないほど急速であり 意思決定者はより迅速な経営判断や業務改善が求められています その迅速な意思決定にあたって 将来の予測分析や過去データの参照に使用するのがデータ ウェアハウス (Data Warehouse: 以降 DWH) であり データ提供に高い性能が求められています 従来から Oracle Database では SQL 実行を並列処理することで ディスク I/O 性能と CPU リソースを最大限活用した高速処理を実現してきました しかし近年では グローバル化や事業の複雑化などにより企業が抱えるデータ量が増加し ストレージに対して求められるディスク I/O 性能が増してきています 一方 ディスクドライブの大容量化により容量を基準にしてディスク本数を設計すると 性能の面ではディスク本数が不足する傾向があります その結果 ストレージのディスク I/O 性能がボトルネックになり CPU や物理メモリのリソースが使いきれず DWH システム全体の性能が制限されているケースが増えてきています この課題を解決するために Oracle Database 11g Release2( 以降 Oracle Database 11g R2) では データを物理メモリ上にキャッシュし並列処理する In-Memory Parallel Query( 以降 In-Memory PQ) が実装されました 本文書では 大容量メモリを持つサーバ NEC Express5800/ スケーラブル HA サーバ上で In-Memory PQ を採用することで DWH システムのハードウェアリソースが効率的に使用されるようになり システム全体の性能向上を実現するソリューションを紹介します Oracle 製品機能紹介 In-Memory Parallel Query 大量データを扱う従来の Parallel Query( 以降 PQ) では データベース バッファ キャッシュ ( 以降 バッファ キャッシュ ) を経由しないでディスクから直接読み込む Direct Path Read でデータにアクセスしていました もちろん ディスクから読み込むよりもメモリ ( バッファ キャッシュ ) から読み込む方が高速ですが 一昔前は大容量の物理メモリは非常に高価でありサーバに搭載可能な物理メモリも少なかったことから 大量データをすべてキャッシュさせる為には バッファ キャッシュのサイズが不十分な環境がほとんどでした もしそのような環境で 通常の数件の小さなデータを扱うクエリと同様にバッファ キャッシュ経由でデータへアクセスした場合 ディスクから読み込んでバッファ キャッシュにキャッシュしても 次々とディスクから読み込まれる別のデータによって追い出されるため キャッシュされたデータが再利用されることが期待できません さらに 再利用できないデータのためのキャッシュ管理のオーバーヘッドがクエリのレスポンスタイムを劣化させます このような理由から 従来より Oracle Database における大量データを扱う PQ では Direct Path Read でデータにアクセスする最適化された方式を採用していました しかしながら 近年では大容量な物理メモリを搭載したサーバが普及してきました 本検証で使用した NEC Express5800/ スケーラブル HA サーバでは 最大構成で 1024GB(256GB 4 ボックス ) の物理メモリを搭載することができます このように 大量データを扱う PQ でもバッファ キャッシュ上のデータを利用する In-Memory PQ を適用し易い環境が整ってきました 3

5 図 1 Direct Path ReadとIn-Memory PQ In-Memory PQ はデータ ( 表や索引等のデータベース セグメント ) をバッファ キャッシュ上にキャッシュして PQ を実施する機能であり 検索対象のデータがバッファ キャッシュ上にある状態ではストレージ性能の限界よりもはるかに高速な処理を実現します さらに 物理メモリ以上のデータを扱う場合を想定し バッファ キャッシュの約 80% よりも大きなデータの際は SQL の実行計画作成時に Direct Path Read が実行されるよう自動判別される仕組みが実装されています ( 図 2) 4

6 図 2 In-Memory PQ 設定時の検索対象のデータサイズによる動作形式の判別フロー In-Memory PQ の設定は 初期化パラメータ PARALLEL_DEGREE_POLICY=AUTO を設定することでアプリケーションの変更無しに適用することができます デフォルトの設定である MANUAL の場合は従来と同様 Direct Path Read で動作します また In-Memory PQ は次に説明する Oracle Partitioning や Oracle Database の表圧縮機能との併用が有効です この点につきまして以下の各機能説明で紹介します Oracle Partitioning Oracle Partitioning は 大きな表や索引をデータベース内部で複数の領域 ( パーティション ) に分割して管理する機能です ユーザーからは 通常通り 1 つの表としてアクセス可能で アプリケーションの変更なしに適用することができます 分割手法として レンジ ( キー値の範囲による分割 ) ハッシュ( キー値をハッシュ関数で分割 ) リスト ( キー値による分割 ) およびそれらを 2 つ組み合わせたコンポジット パーティションを選択可能です 次の表 1 に 組み合わせ可能なコンポジット パーティションとそれが可能になった Oracle Database のバージョンを示します 5

7 レンジ 11gR1 9iR2 8i メイン 表 1 選択可能なコンポジット パーティション サブ レンジリストハッシュ リスト 11gR1 11gR1 11gR1 SQL 文による検索や DML 処理の実行 管理操作などをパーティション単位で実施することができることで SQL 処理の性能向上 管理性の向上 および可用性が向上するメリットがあります 本文書では 性能面でのメリットのうち 特に DWH 系クエリで効果の高いパーティション プルーニングについて解説します パーティション プルーニングとは 必要なデータが存在するパーティションにのみ自動的にアクセスを絞って検索する機能です 例えば Sales 表から 2009 年 10 月のデータを検索する場合 where 句に を指定して SELECT 文を実行します 非パーティション表の場合は 表全体を検索する全件検索が実施されますが パーティション表の場合 2009 年 10 月のパーティションのみの検索となり データアクセス範囲が絞られるため高速な処理が可能になります ( 図 3) 図 3 パーティション プルーニング 6

8 また パーティション表は In-Memory PQ との併用が有効です クエリで処理するデータが 必要なパーティションのみに絞られることでバッファ キャッシュ上にキャッシュされやすくなります 大規模な DWH に対する PQ の場合 表単位ではデータのサイズが大きすぎてキャッシュできないような PQ も必要なパーティションのみに絞ることで In-Memory PQ が有効になる可能性があります ( 図 4) 図 4 パーティションと In-Memory PQ の併用 Oracle Database の表圧縮機能 Oracle Database の表圧縮機能とは Oracle データベース ブロック ( 以降 ブロック ) 内のデータを重複排除し 1 ブロックあたりに格納可能な行数を増やすことで表データのサイズを圧縮する機能です 本機能を活用することで 同じ行数を取り出すために必要なデータ量が減少するため 特えに大量データを扱う DWH 系のクエリにおいては ストレージのディスク I/O 時間が削減され レスポンスタイムの改善が期待できます さらにバッファ キャッシュ上には 圧縮された状態でキャッシュされるため In-Memory PQ が適用可能な検索範囲が拡大されることを期待できます ( 図 5) 図 5 圧縮による In-Memory PQ が適用可能なデータサイズの範囲の拡大 7

9 プラットフォーム紹介 Express5800/ スケーラブル HA サーバ NEC のスケーラブルサーバである Express5800/ スケーラブル HA サーバ は メインフレームやスーパーコンピュータで培った NEC の技術を投入した高性能サーバです Express5800/ スケーラブル HA サーバは 4U のボックス ( 筐体 ) に 4 プロセッサを搭載したエントリモデル Express5800/A1040 と 最大 16 プロセッサまで拡張可能なスケーラブルモデル Express5800/A1160 の 2 製品をラインナップしております 1 プロセッサに 6 コア搭載可能なインテル Xeon プロセッサ搭載しており 使用するプロセッサやコア数を最大で 16 プロセッサ 96 コアまで増やすことが可能です 図 6 Express5800/ スケーラブルHAサーバの拡張さらに EXPRESSSCOPE エンジン SP とマネージメントソフトウェア ESMPRO により システムが停止している状態であっても リモート管理サーバからの遠隔操作や状態確認が可能となります また サーバ監視機能や通報機能はもちろん WEB のリモートコンソールから設定情報 ログ情報の参照ができ 信頼ある運用環境を実現します 図 7 リモートからの遠隔操作や状態確認 8

10 検証環境 本検証で使用したシステム構成は次の通りです Express5800/A1160 上に Oracle Database 11g Release 2 をインストールし 4Gbps の Fibre Channel ( 以降 FC)4 本で接続された istorage D3 上にデータベースを配置しました 本検証では総計約 1TB のデータベースを使用し スキーマには実際の販売管理 DWH を想定したものを用いました データベース クライアント :Express5800/R120a-2 CPU インテル Xeon プロセッサ X5570(2.93GHz)[ コア数 :4] 2 Memory 26GB OS Red Hat Enterprise Linux 5 Update3 x86-64 データベース サーバ :Express5800/A1160 1ボックス : インテル Xeon プロセッサ E7440(2.4GHz) [ コア数 :4] 4 CPU 2ボックス : インテル Xeon プロセッサ E7440(2.4GHz) [ コア数 :4] 8 ECC 付きDDR2-667 FB-DIMM Memory 1ボックス :64GB(8GB 8) 2ボックス :128GB(8GB 16) OS Oracle Database Red Hat Enterprise Linux 5 Update3 EM64T Oracle Database 11g Enterprise Edition Release (Single Instance 構成 ASM 使用 ) 9

11 ストレージ :istorage D3 Hard Disk Drive SAS 300GB(15000rpm) 36 ( 本体 + ディスクエンクロージャ 2の総数 ) Cache Memory 4GB Host interface Fibre Channel 4Gbps 4 検証モデル 一般的に DWH ユーザーは一般ユーザーと経営層ユーザーの 2 つに分けることができます 本文書では両タイプのユーザーを実際の DWH システムを元に次の仮説でモデル化しました 一般ユーザーは 営業社員など日々直面する問題を解決するために主に直近のデータを使用し 経営層ユーザーは 中長期的な計画の策定や検証のために数年間といった長期間のデータを使用する傾向があります それぞれのユーザーが発行するクエリには次の傾向があります 一般ユーザーの発行するクエリは 多数のユーザーによって実行され 発行頻度が高い傾向があります 一方 経営層ユーザーの発行するクエリは 極めて少数のユーザーで実行され 発行頻度が低い傾向があります ( 図 8 表 2) 図 8 一般ユーザーと経営層ユーザーのユーザー数と検索範囲の違い 表 2 一般ユーザーと経営層ユーザーの発行するクエリの違い 検索範囲 ユーザー数 一般ユーザー短期 ( 直近 ) 多い 経営層ユーザー長期少ない 10

12 DWH システムでは 両ユーザーのクエリが同時に処理されている状態であり 従来の物理メモリの少ないサーバでは 大容量データをキャッシュできないため両ユーザーの PQ とも Direct Path Read で実行されます この場合 データの供給元がストレージに集中するため 実行中の PQ の性能がストレージの I/O 帯域の限界で頭打ちになる傾向があります さらに 直近データにアクセスする多数の一般ユーザーは 同じ検索範囲にアクセスするにも関わらず 毎回ディスクから読み込むためストレージの I/O 帯域を圧迫しやすくなっています ( 図 9) 図 9 従来のPQでのハードウェアリソースの使い方この課題を 大容量メモリを搭載したサーバ (NEC Expres5800/ スケーラブル HA サーバ ) と Oracle Database 11g R2 の新機能 In-Memory PQ を組み合わせることでいかに解決できるかを検証します 11

13 検証 1: 従来の PQ と In-Memory PQ の比較 検証モデルで述べたように 実際の DWH システムでは 複数のユーザーから異なる種類のクエリが発行されていますが ここでは 1 ユーザーが同一クエリを用いた場合の従来の PQ と In- Memory PQ の単純な比較をします 従来の PQ は In-Memory PQ の設定無しとすることで実施します また In-Memory PQ 設定有りのとき 検索対象のデータサイズが大きい場合 Direct Path Read が実行されるよう自動判別される仕組みについても確認します この検証で実施した検証方法は下記の通りです 1. 月単位でレンジ パーティション化されたパーティション表を準備 2. In-Memory PQの設定有り無しにおいて 同じ検索期間が指定された同一クエリの性能を測定 3. クエリの指定する月数を増やすことで 検索で使用されるパーティション数を増やし 検索対象のデータサイズを拡張 4. 手順 2へ戻る 図 10 検証方法 この検証で使用した検証環境は以下の通りです データベース サーバ PGA+SGA バッファ キャッシュ使用したクエリの内容テーブル Express 5800/A1160 1ボックス ( 物理メモリ :64GB, 総 CPUコア数 :16コア) 50GB 24.5GB( 約 80% は 19.6GB) 指定した期間のデータを全件検索し合計を集計するクエリ 月単位でパーティション化されたテーブル (1 パーティション辺り約 2.5GB) 12

14 検索対象のデータサイズを拡張させつつ In-Memory PQ 設定有り無しのレスポンスタイムを比較した結果を次の図 11 に示します 図 11 の相対レスポンスタイムには 検索範囲のデータサイズが約 15GB の In-Memory PQ の設定無し (Direct Path Read) のレスポンスタイムを基準値 100 とした相対値を使用しています これ以降 検証 1 および 2 のレスポンスタイムの表示にはこの相対レスポンスタイムを使用します 図 11 In-Memory PQ 設定有り無しにおける検索範囲のデータサイズとレスポンスタイム比較 In-Memory PQ 設定有りのグラフより 検索範囲のデータサイズがバッファ キャッシュの約 80% に収まる場合 In-Memory PQ を実施し それを超えると Direct Path Read で動作する様子が確認できます 次に 従来の PQ である Direct Path Read からキャッシュから読み込む In-Memory PQ になることによる性能向上とリソースの使用傾向の違いを確認するため 検索対象のデータサイズがバッファ キャッシュの 80% に収まるサイズである約 15GB のデータに注目して調査します この場合 In- Memory PQ 設定無しでは Direct Path Read 設定有りでは In-Memory PQ として動作します 検索対象のデータサイズが約 15GB のときの In-Memory PQ 設定有り無しにおける相対レスポンスタイムの比較を次の図 12 に示します 13

15 図 12 Direct Path ReadとIn-Memory PQのレスポンスタイム比較この検証では In-Memory PQ は Direct Path Read に比べて約 5 倍高速であることが確認できました ただし In-Memory PQ はバッファ キャッシュ上に検索対象のデータがキャッシュされていることが前提となるため この性能はバッファ キャッシュ上に検索対象データをキャッシュさせた後の値となります 検索対象データがキャッシュされていない場合は キャッシュするオーバーヘッドが発生するため Direct Path Read に比べて処理時間が長くなります 次に Direct Path Read と In-Memory PQ でのディスク I/O の時系列グラフを次の図 13 に示します ここで使用した相対 Disk I/O 速度 (Read) は 事前に調査したストレージの読み込みのディスク I/O 性能の最大値を基準値 100 とした相対値を使用しています 図 13 Direct Path ReadとIn-Memory PQのストレージリソース使用傾向比較 Direct Path Read の場合 ストレージ性能の上限値付近までストレージを使用しています 一方 In-Memory PQ では ほぼディスク I/O がなくなっていることが確認できます また Direct Path Read と In-Memory PQ での CPU 使用率の時系列グラフの比較を次の図 14に示します 14

16 図 14 Direct Path ReadとIn-Memory PQのCPU 使用率比較 Direct Path Read では CPU 使用率 (usr+sys) が高々 10% 前後になっています これは CPU のデータ処理速度に対してストレージのデータ供給速度が不足しており CPU リソースを使いきれていない状態です 一方 In-Memory PQ では CPU 使用率 (usr+sys) が 100% 付近まで到達しており CPU リソースを限界まで活用しています 以上より 同じクエリに対して 従来の Direct Path Read と In-Memory PQ の性能を比較した結果 In-Memory PQ の方が高速であり かつストレージリソースを消費せず CPU リソースを活用できることが確認できました 次に 処理対象となるデータサイズがバッファ キャッシュの約 80% に収まらない場合の検証結果を示します この場合 In-Memory PQ 設定有りの場合も Direct Path Read で動作する PQ になります 以下に 検索対象のデータサイズが 20GB( バッファ キャッシュの 80%=19.6GB) のときの In-Memory PQ 設定有り無しのレスポンスタイムの比較を示します 図 15 バッファ キャッシュの約 80% を超えたときの In-Memory PQ 有り無しのレスポンスタイム比較 In-Memory PQ の設定有りの場合でも Direct Path Read が実行されるため どちらも同程度のレスポンスタイムであることが確認できます 15

17 以下に In-Memory PQ 設定有り無しにおける Top 5 イベントを示します どちらも 90% 以上の時間を direct path read のイベントに使用しており In-Memory PQ 設定有りの場合も確かに Direct Path Read が実施されていることが確認できます 以上より In-Memory PQ 設定有りのとき 検索対象のデータサイズがバッファ キャッシュの約 80% に収まっている場合 バッファ キャッシュを利用する高速な PQ を実施し 約 80% よりも大きくなる場合は Direct Path Read が実施されるように自動判別されることが確認できました このことから 実際の DWH システムでは 直近のクエリを実施する一般ユーザーは In-Memory PQ によって高速化され 長期のクエリを実施する経営層ユーザーは Direct Path Read で実行される可能性が高くなると考えられます 16

18 検証 2: In-Memory PQ が適用可能な検索範囲の拡大 検証 1の結果から推測できるように In-Memory PQ で実行されているクエリであっても 事業の複雑化などにより DWH のデータ量がさらに増大するとバッファ キャッシュの約 80% を超えるようになり In-Memory PQ が適用されなくなる可能性があります このような課題の解決策として 物理メモリを追加してバッファ キャッシュのサイズを拡張する または検索対象データのサイズを縮小することで In- Memory PQ の適用可能な範囲を拡張する方法が考えられます 検証 2-1 では NEC Express 5800/A1160 のボックス追加機能を活用したバッファ キャッシュのサイズ拡張を 検証 2-2 では Oracle Database の表圧縮機能を活用した検索対象データのサイズを縮小する方法を紹介します 検証 2-1: NEC Express 5800/A1160 のボックス追加による適用範囲の拡大ここでは NEC Express 5800/A1160 の機能であるボックス追加を活用してサーバリソースを追加することで In-Memory PQ の適用範囲を拡大する方法を検証します ボックスを追加すると物理メモリが増加するため より多くのバッファ キャッシュを割り当てることが可能となります 検証では In-Memory PQ 設定有りで 2 ボックスでの Express 5800/A1160 上で検証 1 と同様の検証を実施し 検証 1 の結果 (1 ボックス ) と比較することで ボックス追加により In-Memory PQ の適用範囲を拡大できることを確認しました この検証で使用した検証環境は次の通りです データベース サーバ PGA+SGA バッファ キャッシュ使用したクエリの内容対象テーブル Express 5800/A1160 1ボックス ( 物理メモリ : 64GB, 総 CPUコア数 :16コア) 2ボックス ( 物理メモリ :128GB, 総 CPUコア数 :32コア) 1ボックス :50GB 2ボックス :100GB 1ボックス :24.5GB( 約 80% は19.6GB) 2ボックス :51.8GB( 約 80% は41.4GB) 指定した期間のデータを全件検索し合計を集計するクエリ 月単位でパーティション化されたテーブル (1 パーティション辺り約 2.5GB) 17

19 Express 5800/A1160 の構成が 1 ボックス時と 2 ボックス時とでの In-Memory PQ の適用範囲を比較した検証結果を次の図 16 に示します 図 16 Express5800/A1160のボックス追加前後におけるIn-Memory PQの適用範囲比較 1 ボックスでは約 20GB の検索範囲のクエリで既に Direct Path Read に切り替わっていますが ボックスを追加してバッファ キャッシュのサイズを 2 倍に拡大することで 最大約 40GB(1 ボックス時の約 2 倍 ) の検索範囲のクエリでも In-Memory PQ で動作していることが確認できます 以上より NEC Express 5800/A1160 のボックス追加機能を活用することで In-Memory PQ の適用範囲の容易な拡張が可能となります 検証 2-2:Oracle Database の表圧縮機能による適用範囲の拡大ここでは Oracle Database の表圧縮機能を活用して検索対象データのサイズを縮小することで In- Memory PQ の適用範囲を拡張する方法を検証します 表圧縮機能は 1 ブロックあたりにより多くの行を格納できるため 非圧縮時より大きな検索範囲のデータをバッファ キャッシュ上にキャッシュさせることが可能となります また 圧縮しても In-Memory PQ が適用されないクエリについても 同じ行数を取り出すために必要なデータ量が減少することでディスク I/O 時間の削減が期待できます 上記のことを確認するために In-Memory PQ 設定有りで表圧縮機能を用いて約 2.1 倍に圧縮したパーティション表に対して検証 1 と同様の検証内容を実施し 検証 2-1 の結果 ( 非圧縮 ) と比較しました この検証で使用した環境は次の通りです 18

20 データベース サーバ PGA+SGA バッファ キャッシュ使用したクエリの内容対象テーブル Express 5800/A1160 2ボックス ( 物理メモリ :128GB, 総 CPUコア数 :32コア) 100GB 51.8GB( 約 80% は41.4GB) 指定した期間のデータを全件検索し合計を集計するクエリ月単位でパーティション化されたテーブル非圧縮 (1パーティション辺り約 2.5GB) 圧縮 (1パーティション辺り約 1.2GB) 非圧縮時と圧縮時での In-Memory PQ のレスポンスタイムを比較した検証結果を次の図 17 に示します 図 17 非圧縮時と圧縮時でのIn-Memory PQのレスポンスタイム比較図 17 より 非圧縮時では In-Memory PQ が適用される検索範囲のデータサイズが約 40GB であったものが 圧縮することにより最大約 85GB(= バッファ キャッシュの 80%(41.4GB) 圧縮率 (2.1)) 付近まで拡大していることが確認できます これは圧縮によってデータサイズが縮小されたため それだけ多くの行のデータをキャッシュ可能になったことを示しています また 非圧縮時のデータサイズが約 85GB 以降においては 非圧縮時も圧縮時も同様に Direct Path Read で動作する PQ が実施されていますが 圧縮時の方が非圧縮時より約 2.1 倍高速になっています これは圧縮によってディスク I/O が削減された効果です 以上より DWH システムの一般ユーザーのクエリの処理対象となるデータ量が増大しても Oracle Database の表圧縮機能を活用することで In-Memory PQ の適用範囲を拡大することが可能となることを確認しました さらに 経営層ユーザーが実行するような検索範囲が長期であるため 圧縮しても In-Memory PQ が適用されにくいクエリに対しても ディスク I/O 時間が削減し高速化されることを確認しました 19

21 検証 3: In-Memory Parallel Query による DWH システム全体の高速化 一般ユーザーの検索範囲は直近でかつバッファ キャッシュ上にキャッシュ可能なサイズです そのため Direct Path Read で実行されていた従来の PQ から In-Memory PQ に置き換わることで より高速なレスポンスを期待できます さらに 同じ検索範囲にも関わらず毎回発生していたディスクアクセスが発生しなくなると考えられます 一方 経営層ユーザーのクエリは 一般的に検索範囲が長期でバッファ キャッシュのサイズに比べて大規模であるため 従来通り Direct Path Read で実施される傾向があります しかし 同時に実行されている一般ユーザーのクエリで使用しなくなったストレージの I/O 帯域も利用できるため 経営層ユーザーのクエリにたいしても高速なレスポンスが期待できます ( 図 18) 図 18 In-Memory PQ による使用リソースの変化 20

22 ここでは 上記の理由から In-Memory PQ を設定することによって DWH システム全体が性能向上することを検証します この検証で使用したモデルは次の図 19 の通りです 図 19 検証で使用したDWHシステムのモデル一般ユーザーは 9 セッション 経営層ユーザーは 1 セッション 合計 10 セッション使用しました すべての一般ユーザーは直近 1 カ月にアクセスするクエリを実行し 経営層ユーザーは直近 1 年にアクセスするクエリを実行します また 各セッションから連続的にクエリを発行させることで常に 10 セッションが同時実行している状態を作ります この状態を一定時間継続し 両ユーザーのクエリの平均レスポンスタイムを計測しました 本検証を実施した環境は以下の通りです データベース クライアント データベース サーバ PGA+SGA バッファ キャッシュ 使用したクエリの内容 対象テーブル Express5800/R120a-2 ( 物理メモリ :26GB, 総 CPUコア数 :8コア) Express 5800/A1160 2ボックス ( 物理メモリ :128GB, 総 CPUコア数 :32コア) 100GB 51.8GB( 約 80% は41.4GB) 一般ユーザー : 直近 1カ月のデータ ( 約 6GB) を全件検索し合計を集計するクエリ経営層ユーザー : 直近 1 年間のデータ ( 約 72GB) を全件検索し合計を集計するクエリ月単位でパーティション化されたテーブル圧縮 (1パーティション辺り約 6GB) 21

23 In-Memory PQ の設定有り無しにおける 一般ユーザーと経営層ユーザーの平均レスポンスタイムの比較を次の図 20 に示します 図 20 In-Memory PQ 設定有り無しにおけるユーザータイプ毎の平均レスポンスタイム比較 In-Memory PQ の設定を有りにすることで一般ユーザーのクエリは約 5 倍 経営層ユーザーのクエリは約 9 倍高速化し DWH システム全体の性能が向上することが確認できました 参考として In-Memory PQ の設定有り無しにおける CPU 使用率 (usr+sys) の時系列グラフを次の図 21 に示します 22

24 図 21 In-Memory PQ 設定有り無しでのCPU 使用率比較 In-Memory PQ 設定無しの場合 つまりすべてのクエリが Direct Path Read で動作している状態では ディスクの I/O ボトルネックにより CPU 使用率が 10% 付近と低い状態が続いています これはディスクからのデータの供給速度が CPU のデータ処理速度に比べて不足しているため CPU がディスクからのデータの供給を待っている状態です この状態では CPU リソースを有効に活用できません 一方 In-Memory PQ 設定有りの場合は 一般ユーザーからのデータ供給は物理メモリから 経営層ユーザーからのデータ供給はストレージから行われ データの供給元が分散されます ディスクからのデータ供給による CPU の I/O ウェイトが起きている間も物理メモリから供給されるデータを CPU が効率的に処理することが可能な状態です このため 高い CPU 使用率を保つことができ リソースを有効に活用できていることが確認できます 23

25 まとめ 本検証では In-Memory PQ を適用することで ハードウェアリソースが効率的に使用され DWH システム全体の性能向上が可能であることを確認しました 一般的な DWH システムでは ストレージのディスク I/O 性能がボトルネックになる傾向がありますが In-Memory PQ を適用することで Direct Path Read から In-Memory PQ の動作に変わったクエリが ストレージ性能の限界よりはるかに高速に実行されることを確認しました さらに In- Memory PQ の動作になることで解放されたストレージ I/O 帯域を活用し In-Memory PQ が適用されない大量データを検索するクエリまでも高速化できることを確認しました また In-Memory PQ が適用可能な検索範囲を拡大する方法として 今回検証で使用した NEC Express5800/ スケーラブル HA サーバはサーバリソースを追加して物理メモリを拡張できることから In-Memory PQ と相性が良いことを確認できました さらに In-Memory PQ の適用範囲の拡大には Oracle Database の表圧縮機能を使用したデータサイズの縮小が有効であることを確認しました この場合 圧縮してもなお In-Memory PQ が適用されない大量データのクエリに対しても ディスク I/O 時間の削減により高速化されることが確認できました 以上より NEC Express5800/ スケーラブル HA サーバと Oracle Database 11g Release 2 の新機能 In- Memory Parallel Query の組み合わせは 近年求められている高性能 DWH システムにとって 最適なソリューションを提供します 24

26 共著者 : 正木宏和丸山陽太郎 日本電気株式会社東京都港区芝 Copyright 2010 NEC Corporation, All Rights Reserved. 本書の内容の一部または全部を無断で転載および複写することは禁止されています 本書の内容は将来予告なしに変更することがあります 日本電気株式会社は 本書の技術的もしくは編集上の間違い 欠落について 一切責任を負いません 日本電気株式会社は 本書の内容に関し その正確性 有用性 確実性その他いかなる保証もいたしません WebSAM istoragemanagerは日本電気株式会社の商標および登録商標です 本書に記載のシステム名 会社名 製品名は 各社の登録商標もしくは商標です 著者 : 辻研一郎共著者 : 荒田圭哉日下部明柴田長日本オラクル株式会社東京都港区北青山 オラクル青山センター Copyright 2010, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は その内容に誤りがないことを保証するものではなく また 口頭による明示的保証や法律による黙示的保証を含め 商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません オラクルは本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracleは米国 Oracle Corporationおよびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です