<Insert Picture Here> インメモリ パラレル処理 データ圧縮技術がもたらす超高速データベース ~ システムの運用 そしてビジネスを変える ~ 日本オラクル株式会社テクノロジー製品事業統括本部データベースビジネス推進本部
以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle PeopleSoft JD Edwards 及び Siebel は 米国オラクル コーポレーション及びその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標の可能性があります Copyright 2010, Oracle. All rights reserved.
データウェアハウス (DWH) における性能面の課題ディスク I/O ボトルネックとの戦いの歴史 大量の履歴データを扱う DWH では ディスク I/O がパフォーマンスのボトルネックになりがち ディスク I/O がパフォーマンスのボトルネックの中で最も待機時間が長く コストが高い ディスク本数を増やすことでボトルネックの解消を図るが アクセスを分散させ ディスク I/O パフォーマンスの改善につながる ストレージからサーバーへのデータ転送に新たなボトルネック発生 ボトルネック ボトルネック Copyright 2010, Oracle. All rights reserved. 3
従来までのパラレルクエリーの課題パラレル実行アーキテクチャ パラレル実行の際には必ず Direct Path Read でデータにアクセス 大量データ読み込みは バッファ キャッシュをあえてバイパスして各プロセスが直接データを読み込む 大量データはメモリに載らない 事を前提としたアーキテクチャ 大量データをキャッシュする事はオーバーヘッド QS QC QS QS キャッシュ QC: クエリーコーディネータープロセス QS: クエリースレーブプロセス Copyright 2010, Oracle. All rights reserved. 4
H/W の進化とパラレルクエリー CPU は高速化 / マルチコア化 クアッドコア 複数 CPU 搭載サーバーなど DWH 環境ではCPU 使用率は低くなる傾向 メモリは大容量化 / 低価格化 数十 GB 単位でメモリを搭載したサーバー 従来のアーキテクチャではメモリ使用率は低くなる傾向 従来アーキテクチャの変更の必要 ディスク装置は大容量化 性能 ( 回転数 ) に大幅な改善は見られず メモリを効率よく利用するかがポイント Copyright 2010, Oracle. All rights reserved. 5
解決策 : In-Memory Parallel クエリーの適用概要 パラレルクエリー実行時の メモリ使用効率の最適化 パラレルクエリーでもバッファ キャッシュが利用可能 パラレルクエリー実行時 メモリ上にキャッシュされたテーブルデータにアクセス キャッシュされたデータはユーザー間で共有され クエリレスポンスを高速化 メモリや CPU リソースを有効活用 QS QC QS QS QC: クエリーコーディネータープロセス QS: クエリースレーブプロセス Copyright 2010, Oracle. All rights reserved. 6
解決策 : データを圧縮して性能改善 Advanced Compression 圧縮済みの大量データをメモリに展開可能 ストレージとサーバー間のデータ転送量を大幅に削減 アプリケーションから透過的なデータ圧縮 OLTP にも データウェアハウスにも適用可能 圧縮により検索パフォーマンスが向上 すべてのデータを圧縮可能 圧縮によりストレージ使用量の削減 平均 2-4 倍の圧縮率 データ圧縮により省エネルギー化 2-4X Compression Copyright 2010, Oracle. All rights reserved. 7
インメモリ型データウェアハウス ソリューションとは H/W の進化 Oracle Database 最新機能の活用 プロセッサの高性能 マルチコア化 サーバー搭載メモリの大容量化 In-Memory Parallel Execution データ圧縮 ストレージからデータ転送がボトルネック インメモリ処理 並列処理 プロセッサ性能を無駄にしない最適構成が必要 プロセッサ性能をフルに活かした高速処理が可能 インメモリ型データウェアハウス ソリューション サーバー + ストレージのデータウェアハウス向けの検証済みの最適構成を提供 (10g R2,11g R1 から引き続き 3 世代目 ) インメモリ処理による高速化の効果を実証 Copyright 2010, Oracle. All rights reserved. 8
従来のデータウェアハウスにおける性能面の課題 DB サーバー 大量件数の読み込みが必要となる集計 分析処理 データ抽出 ( 全件検索 範囲検索 ) メモリは容量が小さく有効に機能しないので ディスクからの読み込みが必要 ボトルネック ストレージからサーバーへのデータ転送あるいはディスク I/O がボトルネック ストレージ 検索対象データの増加 ユーザー数の増加に伴い性能劣化 Copyright 2010, Oracle. All rights reserved. 9
インメモリ型データウェアハウス ソリューション性能向上のポイント 大量件数の読み込みが必要となる集計 分析処理 データ抽出 ( 全件検索 範囲検索 ) メモリは容量が小さく有効に機能しないので ディスクからの読み込みが必要 ストレージからサーバーへのデータ転送あるいはディスク I/O がボトルネック 検索対象データの増加 ユーザー数の増加に伴い性能劣化 大規模キャッシュによりディスク読み込みを削減 In Memory Parallel Execution により大量データをキャッシュ処理 圧縮によりキャッシュ可能な データ件数を増加 圧縮によりデータ転送量を削減 FC 4 本によるデータ転送帯域の確保 (32Gb/s) ASM によるディスク I/O の分散 データウェアハウスのシステム性能のボトルネックを排除した最適構成 Copyright 2010, Oracle. All rights reserved. 10
インメモリ型データウェアハウス ソリューション検証結果 検証内容 インメモリ DWH(1TB モデル ) に 一般的な受注管理システムの DWH 環境を構築 13 パターンのクエリを発行し それぞれのレスポンスタイムを測定 検証結果 従来までの DWH 環境と比較し 全てのクエリで性能向上することを実証 ( 最大 14.1 倍 平均 9.6 倍 ) データ分析用のクエリを発行 160 140 レスポンスタイムが大幅に向上 BI ユーザ 120 Express5800/R120b-2 レスポンスタイム 100 80 60 40 20 istorage D3-30 0 q1 q2 q3 q4 q5 q6 q7 q8 q9 q10 q11 q12 q13 クエリ番号 インメモリ DWH 1TB モデル 従来 インメモリ DWH Copyright 2010, Oracle. All rights reserved. 11
本ソリューションの適用範囲について データベースサイズ 2TB 以下のデータウェアハウス 高速バッチ処理のデータベースサーバーに適用 通常の Oracle Database としてトランザクション処理も可能 データ容量 2TB 専用 HW でカバーする領域 最小構成 (**TB) 数千万円 ~ 1TB 最小構成 (500GB) 約 1300 万円 ~ インメモリ DWH 構成モデルで カバーする領域 性能要件 Copyright 2010, Oracle. All rights reserved. 12
参考 : Oracle TimesTen IMDB / Oracle IMDB Cache との違い Application Server 層 高速な SQL アクセス Oracle Database との自動データ同期 Database 層 Application Oracle TimesTen Replication Oracle TimesTen Cache Connect 最小限の開発工数 期間で DB アプリケーション高速化を実現 Oracle TimesTen In-Memory Database メモリ上にデータを展開 高速応答実現 標準 ODBC/JDBC SQL 92 で容易な開発 組み込み機器用途で開発 ほぼ管理不要 ディスク ロギング レプリケーション機能による可用性担保 Oracle Database との互換性 Oracle In-Memory Database Cache Oracle DB 表 / 表の一部を AP サーバ上の Oracle TimesTen に切り出し可能 Microseconds Oracle Database との自動データ同期 複数台で構成することで処理のスケールが可能 16 12 8 4 0 Update a record 平均レスポンス時間 15 マイクロ秒 5 マイクロ秒 Read a record Copyright 2010, Oracle. All rights reserved. 13
参考 : Oracle TimesTen IMDB / Oracle IMDB Cache との違い In-Memory Parallel クエリーに適合する処理 = DWH 処理 従来のパラレルクエリー : 単体の重い SQL In-Memory Parallel クエリー : 単体の重い SQL 一度に多件数のデータを取得する処理 集計処理 バッチ処理に向いている Oracle IMDB Cache に適合する処理 = OLTP 処理 Oracle Database: 大量の軽い SQL Oracle IMDB Cache: 大量の軽いSQL CPU 時間 CPU 時間 I/O 時間 効果大 CPU 時間 I/O CPU 時間 I/O CPU 時間 I/O CPU 時間 I/O 効果大 少件数データへのアクセスや小さなトランザクションに向いている Copyright 2010, Oracle. All rights reserved. 14
In-Memory Parallel クエリーの概要 Copyright 2010, Oracle. All rights reserved. 15
In-Memory Parallel クエリーの適用対象となるオブジェクト バッファ キャッシュの 80% 以下のサイズのテーブルが メモリに読み込まれる 正確な機能名は In-Memory Parallel Execution (PX) クエリー ( 問い合わせ ) だけでなく 更新処理もメモリ上で並列処理可能 In-Memory Parallel クエリーは当該機能の一部 QS QC QS QS QC: クエリーコーディネータープロセス QS: クエリースレーブプロセス Copyright 2010, Oracle. All rights reserved. 16
In-Memory Parallel クエリー複数インスタンスの SGA 利用 複数インスタンスの SGA を利用してデータをキャッシュ RAC 環境では 複数インスタンスの SGA を利用可能 複数インスタンスにセグメントを分散してキャッシュ可能 RAC 環境の場合 複数インスタンスのバッファ キャッシュ総量の 80% 以下のサイズであるテーブルが対象 SGA + SGA + SGA インスタンス 1 インスタンス 2 インスタンス 3 Copyright 2010, Oracle. All rights reserved. 17
検索対象のデータサイズと Parallel 実行のタイプとの関係 NEC 様との共同検証結果 検索対象となるデータサイズがバッファキャッシュの 80% 以上のパラレル実行には Direct Path Read バッファ キャッシュの 約 80%=19.6GB Copyright 2010, Oracle. All rights reserved. 18
In-Memory Parallel クエリー動作概要 SQL 実行参照される表 ( テーブル ) のサイズを特定する 表が適した大きさの場合 表を各インスタンスに分散し バッファキャッシュに読み込む 表が非常に小さい場合 表が非常に大きい場合 QS QC QS インスタンスのバッファキャッシュから読み込み 常に Direct Path Read で読み込みを行う スレーブプロセスはメモリ上のデータにアクセスする QC: クエリーコーディネータープロセス QS: クエリースレーブプロセス Copyright 2010, Oracle. All rights reserved. 19
In-Memory Parallel クエリーと圧縮との組み合わせ Advanced Compression 圧縮前はキャッシュ不可能なサイズ 圧縮後はキャッシュ可能なサイズ 圧縮 圧縮してデータサイズを小さくすることでキャッシュ可能に Copyright 2010, Oracle. All rights reserved. 20
NEC 様との共同検証結果 In-Memory Parallel クエリーと圧縮との組み合わせ Advanced Compression 圧縮による In-Memory Parallel クエリー適用範囲の拡大 2 倍圧縮された表を使用 約 2 倍 Copyright 2010, Oracle. All rights reserved. 21
NEC 様との共同検証結果 In-Memory Parallel クエリーと圧縮との組み合わせ Advanced Compression DWH 系クエリのレスポンス タイムの大幅削減が可能 同じ行数をストレージから読み込む場合でも 物理的なデータ移動量が減少した効果 データの総容量の削減だけではなく クエリ性能の向上も期待できる 約 2 倍圧縮 約 2 倍高速化 Copyright 2010, Oracle. All rights reserved. 22
In-Memory Parallel クエリー設定方法 PARALLEL_DEGREE_POLICY=AUTO に設定 コマンド : alter system / alter session 文で変更可能 alter system set parallel_degree_policy=auto scope=both; Copyright 2010, Oracle. All rights reserved. 23
データベースの圧縮設定方法 Copyright 2010, Oracle. All rights reserved. 24
In-Memory Parallel クエリーの詳細 Copyright 2010, Oracle. All rights reserved. 25
従来までのパラレル実行の課題 DBA によるパラレル度設定 最適なパラレル実行環境の実現は困難!? 全てのクエリーに対して 単一のパラレル度が最適ではない それぞれのクエリーに対して 最善のパラレル度を設定 コストが高いクエリーの調査 調整 リソース制御 システムで利用できるリソースには限界がある 単一ユーザーのための環境 は稀なケース マルチユーザーの環境 公平な量のリソースを割り当てが必要? Copyright 2010, Oracle. All rights reserved. 26
自動パラレル度設定概要 Oracle Database 11g Release 2 からの新たなパラレル度設定の方法 それぞれの SQL に対して Oracle が最適なパラレル度を設定 クエリー,DML,DDL に対応 パラレル度設定に関する負担を大幅軽減 初期化パラメータの設定のみ パラレル実行の簡易化 リソースの有効活用 Copyright 2010, Oracle. All rights reserved. 27
自動パラレル度設定動作概要 自動パラレル度設定の動作概要は以下の通り SQL 実行 SQL 文が解析され シリアルでの実行計画を作成 推定した実行時間を閾値と比較 オプティマイザが最適な DOP を決定 長い場合 短い場合 シリアルで実行 適用される DOP = MIN( デフォルト DOP, 最適な DOP) パラレルで実行 DOP: Degree of Parallelism ( 並列度 ) Copyright 2010, Oracle. All rights reserved. 28
自動パラレル度設定さらに細かくチューニングするために ( 必須の設定ではありません ) パラレル実行の対象となる SQL の基準 設定した値以上の時間がシリアル実行で必要と見積もられた場合 自動パラレル実行の対象になる PARALLEL_MIN_TIME_THRESHOLD : デフォルト [AUTO(10 秒 )] alter system 文 alter session 文で変更可能 alter system set parallel_min_time_threshold=20 scope=both; Copyright 2010, Oracle. All rights reserved. 29
Parallel Statement キューイングリソースを有効活用 性能と処理効率をバランス化 パラレルクエリーをキューイングする機能 FIFO(First In First Out) アルゴリズムを使用 Parallel Statement キューイングの動作概要は以下の通り SQL 実行 SQL 文が解析され Oracle が自動的に DOP を割り当て 十分なスレーブプロセスが確保できない場合 キューに入る 64 32 16 128 FIFO キュー 十分なスレーブプロセスが確保できるのならば 即時実行する 要求されたスレーブプロセス数が獲得されたら 先頭の SQL からデキューされ 実行される 8 128 DOP: Degree of Parallelism ( 並列度 ) Copyright 2010, Oracle. All rights reserved. 30
Parallel Statement キューイングさらに細かくチューニングするために ( 必須の設定ではありません ) キューイングは一定の閾値を超える場合に行われる PARALLEL_SERVERS_TARGET の値が閾値になる デフォルト : 4*PARALLEL_THREADS_PER_CPU*CPU_COUNT クエリーがキューに入るまでに利用できるスレーブ数 Copyright 2010, Oracle. All rights reserved. 31
Parallel Statement キューイング PARALLEL_ADAPTIVE_MULTI_USER との併用 PARALLEL_ADAPTIVE_MULTI_USER ( デフォルト : TRUE) 問合せが実行されたときの リソース状況に応じて パラレル度を自動的にダウングレードしてリソース競合を解消する PARALLEL STATEMENT キューイング PARALLEL STATEMENT キューイングはパラレル度を下げず キューに入れることによって リソース競合を解消する 併用が可能併用しない場合 併用した場合 SQL1 : DOP 4 SQL2 : DOP 4 SQL3 : DOP 4 QS QSQS QSQS QSQS QSQS ダウングレードされず キューに入る SQL1 : DOP 4 SQL2 : DOP 2 SQL3 : DOP 4 キューに入る QS QSQS QSQS QSQS QSQS ダウングレードされ 実行される DOP: Degree of Parallelism ( 並列度 ) Copyright 2010, Oracle. All rights reserved. 32
自動パラレル度設定 PARALLEL_DEGREE_POLICY Oracle Database 11g Release 2 でのパラレル実行に関する新機能を有効化するパラメータ このパラメータを変更することで利用できる機能は以下の通り MANUAL ( デフォルト ) LIMITED AUTO 自動パラレル度設定 In-Memory Parallel クエリー Parallel Statement キューイング Copyright 2010, Oracle. All rights reserved. 33
自動パラレル度設定適用ケースの例 MANUAL ( デフォルト ) 既にパラレル実行により満足なパフォーマンスを享受しており 変更の必要がない場合 LIMITED OLTP や DWH 系処理が混在する環境であるため パラレル度の個別設定が難しい場合 AUTO CPU, ディスク I/O 帯域, ネットワークでボトルネックのない構成で I/O の激しいワークロードが実行される場合 Copyright 2010, Oracle. All rights reserved. 34
In-Memory Parallel クエリーの監視 Copyright 2010, Oracle. All rights reserved. 35
Parallel クエリの監視とチューニング手法パラレル実行の監視 パラレル実行は Enterprise Manager(EM) で監視をすることが可能 Copyright 2010, Oracle. All rights reserved. 36
従来の手法 : 手間と工数を掛けた SQL チューニング TKPROF: Release 9.2.0.8.0 - Production on 金 3 月 26 16:49:21 2010 ( 略 ) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.06 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 6 49.76 217.56 107265 108648 0 66 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 8 49.77 217.62 107265 108648 0 66 Rows Row Source Operation ------- --------------------------------------------------- 66 HASH GROUP BY (cr=108648 pr=107265 pw=107265 time=0 us cost=74184 size=149310 card=1422) 8127334 HASH JOIN (cr=108648 pr=107265 pw=107265 time=2287676 us cost=73633 size=846531420 card=8062204) 102000 TABLE ACCESS FULL ITEM (cr=7387 pr=7383 pw=7383 time=19963 us cost=2019 size=5712000 card=102000) 8127334 HASH JOIN (cr=101261 pr=99882 pw=99882 time=2110269 us cost=47733 size=398239366 card=8127334) 73049 TABLE ACCESS FULL DATE_DIM (cr=1373 pr=0 pw=0 time=417 us cost=377 size=730490 card=73049) 8127334 TABLE ACCESS FULL STORE_SALES (cr=99888 pr=99882 pw=99882 time=1922464 us cost=27571 size=316966026 card=8127334) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 6 0.00 0.00 direct path read 951 0.04 0.64 SQL*Net message from client 5 0.00 0.01 Copyright 2010, Oracle. All rights reserved. 37
これからの手法 : リアルタイム SQL 監視 : 実行中の SQL のボトルネック発見 Oracle 11g 新機能 今ここ! 進行状況がわかるため あとどれくらいで ( バッチなどの ) 処理が終了するか 見当をつけられる Copyright 2010, Oracle. All rights reserved. 38
Parallel Statement キューイングパラレル実行の監視 EM からの監視 パフォーマンス SQL 監視 とクリック 使用されているインスタンス数 キューイングされている時間 割り当てられたパラレル度 キューイングをされていることを示す Copyright 2010, Oracle. All rights reserved. 39
Oracle Database 11g Release 2 パラレル実行の新機能 In-Memory Parallel クエリー パラレルクエリの高速化 自動パラレル度設定 容易なパラレル実行 Parallel Statement キューイング リソース競合の解消 容易なパラレル実行の制御 ハードウェア資産を有効に活用し DWH 環境の高速化を実現 Copyright 2010, Oracle. All rights reserved. 40
バックアップを含めた運用も安心 NEC と日本オラクル バックアップ業務を効率化する データベース超圧縮バックアップソリューション を提供開始 ~ バックアップ容量を約 1/6 に バックアップ時間を約 1/2 に削減することを実証 ~ Copyright 2010, Oracle. All rights reserved. 41
DWH の様々な課題が解決実現不可能 実現可能へ インデックス サマリテーブルの削減 圧縮機能によるストレージコストの大幅圧縮 リアルタイムなシステム連携 OLTP/DWH の共存 サーバ統合で データセンターコストの圧縮 グリーン 明細データからの高速アドホック検索 長期間 大量データの保持 バッチ処理の高速化 統合環境で必要な優れたリソース管理 少ないリソースで分散していたデータベースインフラの統合 Copyright 2010, Oracle. All rights reserved. 42
Copyright 2010, Oracle. All rights reserved. 44