Oracle ExadataによるDWH高速化
フロントDBサーバー側でも処理を高速化
Oracle Exadata V2における高速化ポイントの最後は、バックエンドのStorage Serverの手前に位置する、フロント側のDB Serverにおける並列処理とリソース制御による高速化手法です。
■パラレル・クエリ
単一のクエリを複数のプロセスに分割し、CPU（core）を効果的に使って高速に処理するパラレル・クエリ機能は、ほとんどのデータベース製品に実装されています。Oracle Exadataは、Oracle Real Application Clusters（RAC）の構成をとっているので、高可用性/拡張性に加えて、インターノード・パラレルクエリ（IPQ）により、DBサーバー側のクエリ処理をスケールアウトできます。
IPQは、単一のクエリをRAC環境の複数のノードでパラレルに実行する仕組みです。サービス単位でクエリの実施ノードを制御することも可能です（図3-1）。
特に、以下のような条件に当てはまる場合、IPQを実行することで、パフォーマンスの改善やハードウエア・リソースの有効活用につながると考えられます。
・DWHのDSS（意思決定支援システム）処理のような非常に大きな問い合わせ処理を行っている
・単一ノードのみでのパラレル処理ではCPUネックになるがディスクI/Oには余裕がある
・問い合わせ実行ノード以外のノードではCPU、メモリのリソースに余裕がある
また、Oracle Database 11gR2では、新たなパラレル処理機能として、Oracle Database自体でのインメモリー・パラレル実行が可能となりました。
DWHのクエリなどのような大容量データに対する複雑なクエリに対して、RAC環境の複数のノードのメモリにオブジェクトを分散して、パラレル検索をインメモリーで実行することにより、高速化を図ります。
優先度合いに応じてCPUやI/Oリソースを割り当てる
■リソース制御によるワークロードの管理
これまで、単一のクエリの高速化機能について説明しましたが、最後に、さまざまなワークロードを抱えるDBシステムについて考えます。これは、優先順位に応じてリソース配分を明示的に行うことにより、性能を維持するという考え方です。
最後のグラフ（図3-2）は、Oracle Exadataにおける、混在ワークロード時の検証結果です。OLTP系の更新処理を実施しつつ、同時に大量データの検索処理を実施した場合、どういった影響が出るのかを確認したものになります。
Oracle Exadataでは、従来から可能だったCPUのリソース管理に加えて、I/Oリソースの制御も可能となりました。異なるユーザー（サービス）間、異なるDB間で、I/Oレベルでリソースを制御できます。
折れ線は、Oracle Exadataで処理したトランザクション数を時間経過で表したものです。縦軸はTPS（1秒あたりのトランザクション処理数）値、横軸は時間です。
グラフの上側については、特別な処理は行わず、検索／更新処理を実施しています。検索処理が始まると、更新処理にも影響が出てきており、検索終了に合わせてTPSも回復しています。
下側のグラフは、I/Oのリソース制御を実施した場合の結果です。OLTPには90％、検索処理には10％のI/Oリソース割り当てを行っています。検索処理へのI/Oリソースを制限することで、OLTP処理への影響が出ないように実行するわけです。
このように、Oracle Exadataでは、DWH処理だけでなくOLTP系の業務システムを混在させることができます。これにより、実現が難しいと言われていたリアルタイム検索も可能となり、鮮度の高い新しいデータにアクセスできるため、より質の高い意思決定に役立てることができます。
■まとめ
さて、これまで4回にわたり「データベースの高速化」というテーマで、DBベンダーが提供する機能について説明してきました。
DB製品の説明をしていると、特にアプライアンス製品の場合ですが、「どちらが速いんですか？」とよく聞かれます。ですが、速い／遅いは、なにを速くしたいのか、目的は何か、によって変わります。
ハードウエアで実現できる高速化、ソフトウエアで実現できる高速化、それぞれ一長一短ありますが、一番重要なことは、第1回でも述べた「明確なゴール」です。性能改善の目的は何か、本当に高速化が必要なのか、事前に整理を行った上で、適切な手法を選択してください。
今回の連載が、皆さまの今後のシステム構築の参考になれば幸いです。
