パラレル処理の有効性と落とし穴を検証する：Oracleパーティショニング実践講座（4）（1/4 ページ）

　前回「パーティショニングとパラレル処理は最高の相性」で説明したように、パーティショニングとパラレル処理を併用することで、パフォーマンス向上に相乗効果が望めます。ただ、パラレル処理はハードウェア・リソース（CPU、メモリ、ディスクI/O）を活用するよう設計されているため、ハードウェア・リソースの空きが十分でないとパラレル処理の利点はなく、かえってパフォーマンス劣化につながる可能性があるともいわれています。

　今回は、パラレル処理がどの程度の効果をもたらすのか、ハードウェア・リソースの空きが十分でない場合にどのような結果となるのか、などをご紹介します。

確認するパラレル処理と検証環境

　筆者が勤務する株式会社アシストでは、パラレル処理の有効性を確認するために、大規模なデータの検索、挿入やオブジェクトの作成など、以下の3つのケースに分けて検証しました。

　検証環境には、図1のように「Oracle Real Application Clusters 10g」（以下、Oracle RAC）を利用しました。データベース・サーバのクラスタであるOracle RACは、1つのデータベースへの処理を複数のノードで管理でき、可用性、拡張性、負荷分散に優れた構成を実現できます。

　データベース・サーバには1ノード当たりXeonプロセッサを2つ搭載して、ハイパースレッディング機能によりOS側からは4つのCPUが存在しているように見える状態としました。また、ストレージには「DELL｜EMC CX300」を使用し、15本のディスクをRAID0として構成しました（表1）。

図1　検証環境のシステム構成

表１　検証環境のスペック

パラレル・クエリの検証条件

　第2回「パーティション・プルーニングの有効性を検証する」のときと同様に検証用のSQLとして、筆者の勤務するアシストが提供する「Rapid Warehouse Pack」のERモデルと、Webレポーティング・ツール「WebFOCUS」のテンプレートから、単純なSQLを抽出しています。詳細は第2回の「図4　検証で使用する表構成（Rapid Warehouse Pack ERモデル）」「表2　売上実績表の組み合わせとパーティション数」を参照してください。

　パラレル・クエリの検証で使用する売上実績表は更新日列をレンジ・キーとして月単位でパーティション化、さらに商品番号列をハッシュ・キーとして8つのサブパーティションに分割したコンポジット・レンジ−ハッシュ・パーティションです。リスト1のように、上記の売上実績表に対して、ある年の全商品の売上実績を集計するSQLを、並列度：2、4、8、16、32と変化させて応答時間を計測しました。

　また、パラレル・クエリの検証ではOracle RACを使用しているため、インターノード・パラレル・クエリの効果も確認しています。インターノード・パラレル・クエリとは、1つのSQLの処理を複数ノードに分散して実施できる機能です。単一のノードでパラレル処理を実施する場合に比べ、より多くのCPUリソースを効果的に利用できるといわれています。