パラレル処理の有効性と落とし穴を検証する：Oracleパーティショニング実践講座（4）（1/4 ページ）
本連載では、大規模データベースでのパフォーマンス・チューニングの手法として、Oracleパーティショニングを解説する。単なる機能説明にとどまらず、実機による検証結果を加えて、より実践的な内容をお届けする。（編集部）
前回「パーティショニングとパラレル処理は最高の相性」で説明したように、パーティショニングとパラレル処理を併用することで、パフォーマンス向上に相乗効果が望めます。ただ、パラレル処理はハードウェア・リソース（CPU、メモリ、ディスクI/O）を活用するよう設計されているため、ハードウェア・リソースの空きが十分でないとパラレル処理の利点はなく、かえってパフォーマンス劣化につながる可能性があるともいわれています。
今回は、パラレル処理がどの程度の効果をもたらすのか、ハードウェア・リソースの空きが十分でない場合にどのような結果となるのか、などをご紹介します。
確認するパラレル処理と検証環境
筆者が勤務する株式会社アシストでは、パラレル処理の有効性を確認するために、大規模なデータの検索、挿入やオブジェクトの作成など、以下の3つのケースに分けて検証しました。
- パラレルクエリ
表のスキャン、結合・集合・各種ソート操作など - パラレルDDL
副問い合わせを含む表の作成、索引の作成など - パラレルロード
従来型ロードの分割、1オブジェクトへの同時ロードなど
検証環境には、図1のように「Oracle Real Application Clusters 10g」（以下、Oracle RAC）を利用しました。データベース・サーバのクラスタであるOracle RACは、1つのデータベースへの処理を複数のノードで管理でき、可用性、拡張性、負荷分散に優れた構成を実現できます。
データベース・サーバには1ノード当たりXeonプロセッサを2つ搭載して、ハイパースレッディング機能によりOS側からは4つのCPUが存在しているように見える状態としました。また、ストレージには「DELL｜EMC CX300」を使用し、15本のディスクをRAID0として構成しました（表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リソースを効果的に利用できるといわれています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Copyright © ITmedia, Inc. All Rights Reserved.