インメモリ・パラレル処理、データ圧縮技術がもた …2010/11/26 ·...

<Insert Picture Here>

インメモリ・パラレル処理、データ圧縮技術がもたらす超高速データベース

～システムの運用、そしてビジネスを変える～

日本オラクル株式会社

テクノロジー製品事業統括本部

データベースビジネス推進本部

Copyright© 2010, Oracle. All rights reserved.

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。

また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは

できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン

ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ

い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい

ては、弊社の裁量により決定されます。

Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登

録商標です。その他の名称はそれぞれの会社の商標の可能性があります。

Copyright© 2010, Oracle. All rights reserved. 3

データウェアハウス(DWH)における性能面の課題ディスクI/Oボトルネックとの戦いの歴史

•

大量の履歴データを扱うDWHでは、ディスクI/Oがパフォーマンスのボトルネックになりがち

ディスクI/Oがパフォーマンスのボトルネックの中で最も待機時間が長く、

コストが高い

•

ディスク本数を増やすことでボトルネックの解消を図るが…アクセスを分散させ、ディスクI/Oパフォーマンスの改善につながる

ストレージからサーバーへのデータ転送に新たなボトルネック発生

ボトルネック

ボトルネック


従来までのパラレルクエリーの課題パラレル実行アーキテクチャ

• パラレル実行の際には必ずDirect Path Readでデータにアクセス

QC:クエリーコーディネータープロセス

QS:クエリースレーブプロセス

QSQS QSQS QSQS

QCQC

大量データ読み込みは、バッファ・キャッシュをあえ

てバイパスして各プロセスが直接データを読み込む

「大量データはメモリに載らない」事を前提としたア

ーキテクチャ

大量データをキャッシュする事はオーバーヘッド

キャッシュ


H/Wの進化とパラレルクエリー

• CPUは高速化/マルチコア化クアッドコア、複数CPU搭載サーバーなど

DWH環境ではCPU使用率は低くなる傾向

• メモリは大容量化/低価格化数十GB単位でメモリを搭載したサーバー

従来のアーキテクチャではメモリ使用率は低くなる傾向

従来アーキテクチャの変更の必要

• ディスク装置は大容量化性能（回転数）に大幅な改善は見られず

メモリを効率よく利用するかがポイント


解決策 : In-Memory Parallel クエリーの適用概要

• パラレルクエリー実行時の、メモリ使用効率の最適化パラレルクエリーでもバッファ・キャッシュが利用可能

• パラレルクエリー実行時、メモリ上にキャッシュ

されたテーブルデータにアクセスキャッシュされたデータはユーザー間で共有され、

クエリレスポンスを高速化

メモリやCPUリソースを有効活用

QSQS QSQS QSQS

QCQC



解決策 :データを圧縮して性能改善 Advanced Compression

• 圧縮済みの大量データをメモリに展開可能

• ストレージとサーバー間のデータ転送量を大幅に削減

2-4XCompression

• アプリケーションから透過的なデータ圧縮• OLTPにも、データウェアハウスにも適用可能

• 圧縮により検索パフォーマンスが向上

• すべてのデータを圧縮可能

• 圧縮によりストレージ使用量の削減• 平均2-4倍の圧縮率

• データ圧縮により省エネルギー化

7Copyright© 2010, Oracle. All rights reserved.

インメモリ型データウェアハウス・ソリューションとは

• サーバー＋ストレージのデータウェアハウス向けの検証済みの

最適構成を提供(10g R2,11g R1から引き続き3世代目)

• インメモリ処理による高速化の効果を実証

サーバー搭載メモリ

の大容量化

Oracle Database最新機能の活用

プロセッサ性能を

無駄にしない最適構成が必要

ストレージからデータ転送がボトルネック

プロセッサの高性

能・

マルチコア化

H/Wの進化

In-Memory Parallel Execution

データ圧縮

プロセッサ性能をフルに活かした

高速処理が可能

インメモリ処理・並列処理

インメモリ型データウェアハウス・ソリューション


従来のデータウェアハウスにおける性能面の課題

DBサーバー

ストレージ

大量件数の読み込みが必要となる

集計･分析処理、データ抽出

(全件検索・範囲検索)

メモリは容量が小さく有効に機能しないので、

ディスクからの読み込みが必要

ストレージからサーバーへのデータ転送

あるいはディスクI/Oがボトルネック

検索対象データの増加・

ユーザー数の増加に伴い性能劣化

ボトルネック


インメモリ型データウェアハウス・ソリューション性能向上のポイント

大量件数の読み込みが必要となる

集計･分析処理、データ抽出

(全件検索・範囲検索)

メモリは容量が小さく有効に機能しないので、

ディスクからの読み込みが必要

ストレージからサーバーへのデータ転送

あるいはディスクI/Oがボトルネック

検索対象データの増加・

ユーザー数の増加に伴い性能劣化

大規模キャッシュにより

ディスク読み込みを削減

In Memory Parallel Execution により大量データをキャッシュ処理

圧縮によりキャッシュ可能な

データ件数を増加

圧縮によりデータ転送量を削減

FC×4本による

データ転送帯域の確保(32Gb/s)

ASMによるディスクI/Oの分散

データウェアハウスのシステム性能のボトルネックを排除した最適構成


インメモリ型データウェアハウス・ソリューション検証結果

Express5800/R120b-2

iStorage D3-30

BIユーザ

データ分析用のクエリを発行

検証内容

インメモリDWH(1TBモデル)に、一般的な受

注管理システムのDWH環境を構築。13パタ

ーンのクエリを発行し、それぞれのレスポン

スタイムを測定

検証結果従来までのDWH環境と比較し、全てのクエリ

で性能向上することを実証(最大14.1倍、平

均9.6倍)

インメモリDWH

1TBモデル

0

20

40

60

80

100

120

140

160

q1 q2 q3 q4 q5 q6 q7 q8 q9 q10 q11 q12 q13

クエリ番号

レスポンスタイ

ム

従来インメモリDWH

レスポンスタイムが大幅に向上


1TB

2TB

データ容量

性能要件

・

・最小構成(**TB) 数千万円～

本ソリューションの適用範囲について

最小構成(500GB) 約1300万円～

インメモリDWH構成モデルで

カバーする領域

専用HWでカバーする領域

データベースサイズ２TB以下のデータウェアハウス、高速バッチ処理のデータベースサーバーに適用

通常のOracle Databaseとしてトランザクション処理も可能



0

4

8

12

16

Mic

rose

cond

s

Update a record Read a record

平均レスポンス時間

15マイクロ秒

5マイクロ秒

参考 : Oracle TimesTen IMDB / Oracle IMDB Cacheとの違い

Oracle TimesTen In-Memory Database

メモリ上にデータを展開、高速応答実現

標準ODBC/JDBC、SQL 92で容易な開発

組み込み機器用途で開発、ほぼ管理不要

ディスク・ロギング、レプリケーション機能による

可用性担保

Oracle Database との互換性

Oracle In-Memory Database Cache

Oracle DB 表/表の一部を

AP サーバ上の

Oracle TimesTen に切り出し可能

Oracle Database との自動データ同期

複数台で構成することで処理のスケールが可能

Oracle TimesTen

Database 層

ApplicationApplication Server 層

ReplicationOracle

TimesTen

高速な

SQLアクセス

Oracle Database との

自動データ同期

最小限の開発工数、期間で

DB アプリケーション高速化を実現

最小限の開発工数、期間で

DB アプリケーション高速化を実現

Cache Connect


• In-Memory Parallel クエリー

に適合する処理

= DWH 処理

• 従来のパラレルクエリー: 単体の重いSQL

• In-Memory Parallel クエリー: 単体の重いSQL

• Oracle IMDB Cache に適合する処理

= OLTP 処理

• Oracle Database: 大量の軽いSQL

• Oracle IMDB Cache: 大量の軽いSQL

一度に多件数のデータを取得する処理、集計処理、バッチ処理に向いている

少件数データへのアクセスや小さなトランザクションに向いている

CPU時間 I/O時間

CPU時間効果大

効果大

CPU時間 I/O CPU時間 I/O CPU時間 I/O CPU時間 I/O

参考 : Oracle TimesTen IMDB / Oracle IMDB Cacheとの違い

In-Memory Parallel クエリーの概要



In-Memory Parallel クエリーの適用対象となるオブジェクト

• バッファ・キャッシュの80%以下のサイズのテーブルが

メモリに読み込まれる

QSQS QSQS QSQS

QCQC



• 正確な機能名はIn-Memory Parallel Execution (PX)• クエリー(問い合わせ) だけでなく、更新処理もメモ

リ上で並列処理可能

• In-Memory Parallel クエリーは当該機能の一部


In-Memory Parallel クエリー複数インスタンスのSGA利用

• 複数インスタンスのSGAを利用してデータをキャッシュ• RAC環境では、複数インスタンスのSGAを利用可能

• 複数インスタンスにセグメントを分散してキャッシュ可能

• RAC環境の場合、複数インスタンスのバッファ・キャッシュ総量

の80%以下のサイズであるテーブルが対象

インスタンス1 インスタンス2 インスタンス3

＋＋SGA SGA SGA

検索対象のデータサイズと Parallel実行のタイプとの関係


• 検索対象となるデータサイズがバッファキャッシュの80%以上のパラレル実行にはDirect Path Read

バッファ・キャッシュの

約80%=19.6GBバッファ・キャッシュの

約80%=19.6GB

※NEC様との共同検証結果


In-Memory Parallel クエリー動作概要

SQL実行参照される表(テーブル) のサイズを特定する

表が非常に

小さい場合

表が非常に

大きい場合

表が適した

大きさの場合

表を各インスタンスに分散し、バ

ッファキャッシュに読み込む

インスタンスのバッファキ

ャッシュから読み込み常にDirect Path Read

で読み込みを行う

QSQS QSQS

スレーブプロセスはメモリ上

のデータにアクセスする

QCQC



In-Memory Parallel クエリーと圧縮との組み合わせ Advanced Compression

圧縮圧縮後はキャッシュ

可能なサイズ

圧縮前はキャッシュ不可能なサイズ

圧縮してデータサイズを

小さくすることでキャッシ

ュ可能に

圧縮してデータサイズを

小さくすることでキャッシ

ュ可能に


• 圧縮によるIn-Memory Parallel クエリー適用範囲の拡大• 2倍圧縮された表を使用


約約22倍倍



• DWH系クエリのレスポンス・タイムの大幅削減が可能

• 同じ行数をストレージから読み込む場合でも、物理的なデータ移動量

が減少した効果

• データの総容量の削減だけではなく、クエリ性能の向上も期待できる


約2倍高速化

約2倍圧縮




In-Memory Parallel クエリー設定方法

• PARALLEL_DEGREE_POLICY=AUTOに設定

コマンド

: alter system / alter session文で変更可能

alter system set parallel_degree_policy=AUTO scope=both;alter system set parallel_degree_policy=AUTO scope=both;

データベースの圧縮設定方法


In-Memory Parallel クエリーの詳細



従来までのパラレル実行の課題

• DBAによるパラレル度設定• 最適なパラレル実行環境の実現は困難 !?全てのクエリーに対して、単一のパラレル度が最適ではない

それぞれのクエリーに対して、最善のパラレル度を設定

コストが高いクエリーの調査、調整

• リソース制御• システムで利用できるリソースには限界がある

• “単一ユーザーのための環境”は稀なケース

• マルチユーザーの環境

公平な量のリソースを割り当てが必要

?


自動パラレル度設定概要

• Oracle Database 11g Release 2からの新たなパラレル度設定の方法

それぞれのSQLに対してOracleが最適なパラレル度を設定

クエリー,DML,DDLに対応

• パラレル度設定に関する負担を大幅軽減初期化パラメータの設定のみ

パラレル実行の簡易化

リソースの有効活用


自動パラレル度設定動作概要

• 自動パラレル度設定の動作概要は以下の通り

SQL実行 SQL文が解析され、シリア

ルでの実行計画を作成

推定した実行時間

を閾値と比較

シリアルで実行

オプティマイザが最

適なDOPを決定

適用されるDOP = MIN(デフォルト

DOP, 最適なDOP)

パラレルで実行

短い場合

長い場合

DOP: Degree of Parallelism (並列度)


自動パラレル度設定さらに細かくチューニングするために (※必須の設定ではありません)

• パラレル実行の対象となるSQLの基準

設定した値以上の時間がシリアル実行で必要と見積もられた

場合、自動パラレル実行の対象になる

PARALLEL_MIN_TIME_THRESHOLD : デフォルト

[AUTO（10秒）]

alter system set parallel_min_time_threshold=20 scope=both;alter system set parallel_min_time_threshold=20 scope=both;alter system文、alter session文で変更可能


Parallel Statement キューイングリソースを有効活用、性能と処理効率をバランス化

• パラレルクエリーをキューイングする機能FIFO（First In First Out）アルゴリズムを使用

• Parallel Statement キューイングの動作概要は以下の通り

SQL実行 SQL文が解析され、Oracleが

自動的にDOPを割り当て

163264 128

FIFO キュー

十分なスレーブプロセス

が確保できるのならば、

即時実行する

要求されたスレーブプロセ

ス数が獲得されたら、先

頭のSQLからデキューさ

れ、実行される

8 128

十分なスレーブプロセスが確保で

きない場合、キューに入る



Parallel Statement キューイングさらに細かくチューニングするために (※必須の設定ではありません)

• キューイングは一定の閾値を超える場合に行われるPARALLEL_SERVERS_TARGETの値が閾値になる

デフォルト: 4*PARALLEL_THREADS_PER_CPU*CPU_COUNT

クエリーがキューに入るまで

に利用できるスレーブ数

32

Parallel Statement キューイング PARALLEL_ADAPTIVE_MULTI_USERとの併用

• PARALLEL_ADAPTIVE_MULTI_USER (デフォルト: TRUE)問合せが実行されたときの、リソース状況に応じて、パラレル度を自動的

にダウングレードしてリソース競合を解消する

• PARALLEL STATEMENT キューイング

PARALLEL STATEMENTキューイングはパラレル度を下げず、キュー

に入れることによって、リソース競合を解消する

• 併用が可能

併用しない場合

併用した場合

QSQSQSQSQSQSQSQSQSQSQSQS QSQSQSQSQSQSQSQSQSQSQSQSSQL1 : DOP 4SQL2 : DOP 4

SQL1 : DOP 4SQL2 : DOP 2SQL3 : DOP 4

ダウングレードされず、

キューに入る

ダウングレードされ、

実行されるキューに入る


SQL3 : DOP 4



自動パラレル度設定 PARALLEL_DEGREE_POLICY

• Oracle Database 11g Release 2 でのパラレル実行に関する新機能を有効化するパラメータ

• このパラメータを変更することで利用できる機能は以下の通り

MANUAL （デフォルト）

LIMITED AUTO

自動パラレル度設定 × ○ ○

In-Memory Parallel クエリー × × ○

Parallel Statement キューイング × × ○


自動パラレル度設定適用ケースの例

• MANUAL （デフォルト）

既にパラレル実行により満足なパフォーマンスを享受しており、

変更の必要がない場合

• LIMITEDOLTPやDWH系処理が混在する環境であるため、パラレル度の

個別設定が難しい場合

• AUTOCPU,ディスクI/O帯域,ネットワークでボトルネックのない構成で、

I/Oの激しいワークロードが実行される場合

In-Memory Parallel クエリーの監視



Parallel クエリの監視とチューニング手法パラレル実行の監視

• パラレル実行はEnterprise Manager(EM)で監視をすることが可能

従来の手法

:

手間と工数を掛けた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


これからの手法

: リアルタイムSQL監視 :

実行中のSQLのボトルネック発見

進行状況がわかるため、

「あとどれくらいで(バッチなどの)処理

が終了するか」、見当をつけられる

「今ここ！」

Oracle 11g

新機能



Parallel Statement キューイングパラレル実行の監視

• EMからの監視• 「パフォーマンス」

→「SQL監視」とクリック

キューイングされている時間割り当てられたパラレル度

使用されているインスタンス数

キューイングをされていることを示す


Oracle Database 11g Release 2 パラレル実行の新機能

• In-Memory Parallel クエリー

• パラレルクエリの高速化パラレルクエリの高速化

• 自動パラレル度設定• 容易なパラレル実行容易なパラレル実行

• Parallel Statement キューイング

• リソース競合の解消、容易なパラレル実行の制御リソース競合の解消、容易なパラレル実行の制御

ハードウェア資産を有効に活用し、 DWH 環境の高速化を実現

バックアップを含めた運用も安心ＮＥＣと日本オラクル、バックアップ業務を効率化する「データベース超

圧縮バックアップソリューション」を提供開始

～バックアップ容量を約1/6に、バックアップ時間を約1/2に削減することを実証

～


DWH の様々な課題が解決実現不可能

実現可能へ

42

明細データからの高速アドホック検索明細データからの高速アドホック検索

インデックス・サマリテーブルの削減

インデックス・サマリテーブルの削減

長期間・大量データの保持長期間・大量データの保持圧縮機能によるストレージコストの大幅圧縮

圧縮機能によるストレージコストの大幅圧縮

OLTP/DWHの共存OLTP/DWHの共存

バッチ処理の高速化バッチ処理の高速化

少ないリソースで分散していたデータベースインフラの統合

少ないリソースで分散していたデータベースインフラの統合

リアルタイムなシステム連携リアルタイムなシステム連携

統合環境で必要な優れたリソース管理統合環境で必要な優れたリソース管理

サーバ統合で、データセンターコストの圧縮⇒グリーン

サーバ統合で、データセンターコストの圧縮⇒グリーン


インメモリ・パラレル処理、データ圧縮技術がもた …2010/11/26 ·...

Documents