最新のOracle Databaseでストレージと賢く付き合う 第3回 Oracle Database 11g Release 2 Enterprise Editionだからできる、SQLのパラレル実行によるバッチ/DWH処理のカンタン高速化

企業で扱うデータ量が増大し続けていることから、昨今、「バッチ処理やデータウェアハウス(DWH)でのSQL処理の長時間化」という問題がクローズアップされています。例えば、日中のオンライン業務が終わった後で夜間に実施する日次のバッチ処理が長引き、翌朝の営業開始までに終了しなかった場合、オンライン業務の開始時刻が遅れてしまうという問題が発生します。また、DWHの面では、急速に変化、発展を続けるビジネス環境に対応していち早く業務改善や経営判断をするために、企業が保有する大容量データをより速く分析することが求められています。今回は、こうした問題の解決策として、今や当たり前となったマルチコアCPUをフル活用してバッチ/DWH処理を高速化するためのポイントを紹介します。

語り手:
日本オラクル株式会社
テクノロジー製品事業統括本部
データベースソリューション本部
データベースソリューション部
エンジニア
辻研一郎

■バッチ/DWH処理では、SQLをパラレル実行しないとCPUコアを有効活用できない

 OLTPのように1つのSQLの扱うデータ量が小さく短時間で完了する処理では、1CPUコア上で十分にデータを処理することができます。OLTPの大量実行によって複数のSQLが同時実行される場合にも、各処理がそれぞれのCPUコア上で実行されるプロセスに分散され、自然に複数のCPUコアを有効活用しながら処理が行われることになります。

 しかし、バッチやDWH処理のように1つのSQLで大量のデータを扱う必要がある場合はどうでしょうか。通常、1つのSQLは1つのプロセス、1つのCPUコア上で実行されることになります。複数のCPUコアが搭載されていても、1CPUコアしか利用しません。この結果、すべてのCPUコアを有効に使うことができず、処理時間が長引く傾向があります。つまり、日中のOLTP処理は複数のCPUコアをうまく使って処理されていたとしても、夜間バッチでは複数CPUコアが有効に使われず、処理が時間内に終わらないといった問題が起きるのです。
img_storage_110519_01.png
 このようなときに有効なのが、1つのSQLが扱うデータを分割し、CPUコアごとに複数プロセスで並列処理する方法です。これがOracle Database Enterprise Editionで標準使用できるSQLのパラレル実行です。
img_storage_110519_02.png
 マルチコア化が進んで高性能化している中で、SQLのパラレル実行はますます有効性が高まっていますが、パラレル実行というと何となく難しそうに聞こえたり、リソース管理、分析が大変そうだというイメージを持たれている方が多いかもしれません。そのため、これまでは、例えばマネージャーとエンジニアの間で次のようなやり取りが交わされるケースが多かったのではないでしょうか。

マネージャー:「今日もバッチ処理が始業時間ギリギリまでかかっていたようだな。早くこの状況を改善しないとマズいことになるぞ。最近はマルチコアCPUが当たり前になってハードウェアのパフォーマンスも向上しているみたいだから、とりあえずサーバを新しいものに入れ替えるか。CPUコアが増えるから、その分だけ速くなるんだろ?」

エンジニア:「実は、単にマルチコアCPUにしても、SQLをパラレル化しないとあまり意味がないんですよ」

マネージャー:「でも、SQLのパラレル実行は難しいイメージがあるんだよなぁ。SQLごとに適切なパラレル度も違うだろうし、リソース管理も厄介そうだ。分析も大変だと聞いたことがあるぞ」

エンジニア:「では、とりあえず日次で処理する必要性が薄いものを、週次で対応することにしましょうか?」

■簡単にSQLのパラレル度を自動設定

 上の会話の中でもありましたように、今までのパラレル実行では、SQLごとに必要なデータ量に基づいた適切な「パラレル度」を設定し、必要十分なリソースを割り当てる必要がありました。しかし実際には、データ量が変動することもあり、適切に設定するのはなかなか難しいものでした。そのため、ある程度のリソース消費を覚悟して高めのパラレル度を設定するか、もしくは特に処理時間がかかるSQLだけをパラレル化するといった対応をするケースもありました。

 これに対し、Oracle Database 11g Release 2 Enterprise Editionの「自動パラレル度設定」では、パラレル度の設定の難しさ、煩雑さから解放されます。本機能では、SQLごとに必要とするデータ量とストレージ能力を照らし合わせて、パラレル度を自動決定します。また、パラレル化の必要がないSQLに対しては、パラレル化しないという判断もしてくれます。しかも、この機能は事前にストレージ能力を測るプロシージャを実行し、パラメータを1つ設定するだけで使用できるようになります。これにより、今までデータベース管理者が適宜検討してパラレル度を設定していた作業工数が不要となり、より導入しやすくなっています。
img_storage_110519_03.png
■SQLのパラレル実行の同時実行も自動制御

 近年では、DWHのWeb化が進んでアクセス・ユーザーが増加する傾向にあり、DWHの重い分析処理が同時に実行されるケースも出てきています。複数のCPUコアを同時に使用するパラレル実行が同時に複数行われてしまうと、リソースがビジーになり、逆に性能が劣化する問題が起きる可能性があります。そのため、パラレル実行の同時実行をどのようにして制御するかが重要な課題になります。

 Oracle Database 11g Release 2 Enterprise Editionでは、この課題に対して「パラレル・ステートメント・キューイング」で対処します。この機能は、上限値を超えるようなパラレル度のSQLが発行された場合にキューに入れて待たせることで、パラレル実行の同時実行を制御しながらリソースがビジーになるのを防ぎ、すべてのSQLが適切なパラレル度で実行できるようにします。
img_storage_110519_07.png
 このパラレル・ステートメント・キューイングも、自動パラレル度設定と同じパラメータを設定するだけで簡単に使用できます。

■SQLのパラレル実行を容易に分析

 SQLをパラレル化した場合、その分析が難しいと考えている方や、実際にそうした経験をお持ちの方もおられるでしょう。特に、Oracle Database 10gまでは実行計画、動的パフォーマンスビューやstatspackなどの分析レポートからパラレル実行の動作を確認しつつ、mpstatやiostatなどのOS統計から作成した時系列グラフと突き合わせてリソースの使い方の具合を見るといった分析をしていました。このため、分析にはパラレル実行用の実行計画の知識や、出力される待機イベント、リソース使用の傾向などを知る必要があり、高度なスキルが必要とされていました。

 Oracle Database 11gのDiagnostic PackオプションとTuning Pack オプションで使用できる「リアルタイムSQL監視」を使うと、そうしたパラレル化したSQLの分析が非常に楽になります。

 リアルタイムSQL監視機能は、実行中のSQLを自動監視し、詳細な統計や取得レポートを自動生成するというものです。レポートでは、実行計画の各実行ステップにかかっている時間や、SQLごとのOS統計の時系列グラフなどの情報がグラフィカルに表示され、パラレル実行の様子も一目で確認できます。もちろん、レポート出力も可能であり、素早く状況を共有できるというメリットがあります。
img_storage_110519_04.png
 これにより、分析が楽になるほか、SQL文の実行が完了するのを待たずにリアルタイム分析できるという点もポイントです。バッチ処理の遅延に気づくのは、バッチ処理開始からある程度時間が経過した後になるのが一般的です。このときに困るのが、現在のバッチ処理の進捗状況がわからないため、もう少し待てば終わるのか、処理を中断してSQLを見直したうえで再実行したほうが早いのかをすぐに判断できないことです。リアルタイムSQL監視では、実行計画の実行ステップのうち、「今はこのステップを実行中で、何%完了している」ということが一目で確認できるので、継続か打ち切りかをすぐに判断できます。
img_storage_110519_05.png
■効率的なキャッシュ利用でストレージの性能限界を超えるパラレル実行の高速化

 最後に、Oracle Database 11g Release 2 Enterprise Editionから実装された、従来のパラレル実行を大幅に高速化させる機能「In-Memory Parallel Execution(In-Memory PX)」を紹介します。その前に、まず従来バージョンのパラレル実行について復習しておきましょう。

 Oracle Database 11g Release 1以前のパラレル実行では、メモリを経由せずにディスクから直接データを読み込んでいました。もちろん、ディスクよりもメモリから読み込んだほうが高速です。しかし、かつて大容量メモリは非常に高価でサーバに搭載可能な容量も少なかったことから、パラレル実行が対象とする大量データを扱うにはメモリ容量が不十分でした。このような状態でデータをキャッシュしようとしても、キャッシュしたそばからこぼれ落ちてしまい、キャッシュを有効に利用できません。それどころか、データをキャッシュするための余計なオーバーヘッドがかかるだけです。

 このような理由から、従来はメモリを経由せずに、ディスクから直接読み込むパラレル実行を採用していました。しかし、第1回で取り上げたように、容量ベースでサイジングされたストレージでは、マルチコアCPUの性能にストレージの性能が追いつきません。このため、そのような環境のOracle Database 11g Release 1以前のパラレル実行では、CPUをフル活用する前にストレージの性能限界で頭打ちになる傾向にありました。

 このストレージ性能のボトルネックを打破すべく、近年のメモリの大容量化を背景として、Oracle Database 11g Release 2で搭載されたのがIn-Memory PXです。In-Memory PXでは、メモリ上にキャッシュされたデータを使ってパラレル実行するため、ストレージ性能の限界を超えた高速化が可能となります。
img_storage_110519_06.png
 また、In-Memory PXは、自動パラレル度設定やパラレル・ステートメント・キューイングと同じパラメータを1つ設定するだけで簡単に使うことができます。これら3つの機能はアプリケーションに対して透過的に処理されるため、アプリケーションを改修する必要はありません。

 In-Memory PXをさらに有効に活用するには、本連載で紹介している「Oracle Partitioning」や「Oracle Advanced Compression」との組み合わせが有効です。Oracle PartitioningでSQLの対象データを必要な部分に絞り、Oracle Advanced Compressionでデータ自体を小さくして、より多くのレコードをキャッシュするのです。これにより、大規模なDWHにおいて効率的なキャッシュ利用が可能になり、In-Memory PXによるメモリ上での高速処理のメリットを享受できます。

 このように、Oracle Database 11g Release 2 Enterprise Editionを利用すれば、ストレージの性能限界を超えて高速にパラレル実行を行うことが可能になります。また、SQLのパラレル化を容易に実現するための仕組みも用意されており、バッチ処理やDWH処理の高速化に大きく貢献します。

Comments:

Post a Comment:
Comments are closed for this entry.
About

Twitter
Facebook

Search

Recent Posts
Archives
« 4月 2014
  
1
2
3
4
5
6
7
9
10
11
12
13
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today