表／索引のメンテナンスとパーティション設計：DB2チューニング・ベストプラクティス（7）（2/2 ページ）
データベース・パーティショニング・フィーチャー（DPF）のパフォーマンス
DB2 v8.1 ESE（Enterprise Server Edition）のデータベース・パーティショニング・フィーチャー（DPF：Database Partitioning Feature）を使用すると、単一のサーバ内で、または複数のサーバにまたがって、データベースをパーティション化することができます。これによりスケーラビリティが向上し、大規模なデータベースや複雑なワークロードをサポートすることができ、管理タスクの並列処理が強化されます。DPFによって最善のパフォーマンスを得るための推奨事項を次に説明します。
どのような場合にパーティション化するか？
64ビットのDB2が登場するまでは、主に32ビット・アーキテクチャの共有メモリの制限（通常、データベースごとに約2Gbytes）を回避する方法としてパーティション化が利用されていました。現在では、メモリを有効活用するためのよりよい方法は、大規模なSMP 64ビット・サーバを使用することです。これにより、パーティション化に伴う複雑さとオーバーヘッドが完全に排除されます。
しかし、場合によっては、パーティション化を利用するとSELECT、LOAD、BACKUP、RESTOREの実行が大幅に高速化されることがあります。パーティションを追加することで、各パーティション上でプロセッサが処理しなければならないデータ量が減るからです。ただし、パーティションの数が少ないデータベースでは、このような効果はほとんど得られません。なぜなら、行をハッシュしてデータを送信することによるオーバーヘッドの方が、処理するデータ量が減ることによるパフォーマンス向上の度合いよりも大きくなってしまうからです。
パーティション化を行うもう1つの理由は、パーティションごとのデータベース・マネージャの制限（例えば4Kbytesページ・サイズの場合、パーティションごとの最大表サイズは64Gbytes）を回避することです。
パーティションの数をいくつにするか？
これは難しい質問です。なぜなら、1つのパーティションに1つのCPUを割り当てた方が快適に動作するシステムもあれば、8つ以上のCPUを割り当てた方が快適に動作するシステムもあるからです。基本的な考え方は、各パーティションに割り当てたCPUをビジー状態に保つということです。SMPマシンの場合は、1つのパーティションに4つ程度のCPUから始めるとよいでしょう。CPU使用率が常に低いようであれば（例えば40％未満）、パーティションをさらに追加することを検討します。
一般的には、マシンごとのパーティションの数は少ない方がよいといえます。ローカル・バイパスとコロケーション（後で説明します）の可能性が増えるからです。
最適なパーティション・キーの選択
適切なパーティション・キーを選択することで、バランスの取れたデータ分散とワークロード、および効率のよい表コロケーションが可能になります。
パーティション・キーを選択するときには、以下の点に留意してください。
- デフォルトのままにせず、常にパーティション・キーを指定します。
- パーティション・キーは、主キーまたはユニーク索引のサブセットでなければなりません。
- 異なる値を数多く持つ列を、パーティション・キーとして使用します。異なる値の数が極めて少ない列の場合は、わずかな数のハッシュ値しか生成されないため、データの偏りやワークロードの不平衡が生じやすくなります。
- パーティション・キーを構成する列の数が多過ぎると（一般に4つ以上）、ハッシュ値の生成だけでパフォーマンスの低下が起こります。
- コロケーテッド結合を増やすために、頻繁に結合される表同士については、同じ列の集まりをパーティション・キーとして使用します。
- DECIMAL型の列より文字型の列の方が効率的ですが、文字型の列より整数型の列の方がさらに効率的です。
- 参照情報→SQL→言語エレメント→データ・タイプ→パーティションの互換データ・タイプ
表コロケーション
表コロケーションを使用すると、（同じ論理パーティション内での）照会のローカル処理が可能になり、パーティション間での無駄なデータ移動を排除できます。表コロケーションが確実に行われるようにするには、表の結合列をパーティション・キーとして使用し、それらの結合される表を、同じパーティション・グループを共有する表スペースの中に配置します。結合される表同士のパーティション・キーは、列の数が同じで、データ型が一致していなければなりません。
頻繁に結合される相手の表と同じキーでパーティション化できない表があり、その表が一般的に読み取り専用で、サイズが小さい場合は、複製マテリアライズ照会表（複製MQT）を使用するとパフォーマンスが向上する場合があります。複製MQTを使用すると、表全体（または表の一部）の内容を、データベース・パーティション・グループ内の各パーティションに複製できるからです。ただし、表が頻繁に更新される場合は、リソース使用量が増えるため、パフォーマンスが低下する恐れがあります。
単純な複製MQTを作成するには、次の構文を使用します。
CREATE TABLE replicated_table |
| （注：赤字は各自の環境に置き換えてください） |
MQTの詳しい情報については、下記のドキュメントの該当セクションを参照してください。
AIXを使用していて、DB2プロファイル・レジストリ変数「DB2_FORCE_FCM_BP=YES」を設定している場合は、（同じマシン上で）複数の論理パーティションを使用すると、パーティション間でのデータ転送が共有メモリを介して非常に高速に行われます。
- 製品概要→データベース・システム→バージョン 8.1→パフォーマンスの機能強化→マテリアライズ照会表
- 参照情報→SQL→関数→スカラー関数→DBPARTITIONNUM
データの再平衡化
パーティション間でのデータの再平衡化を行い、ハッシュ・パーティション・マップを更新して、よりバランスの取れたものにするには、REDISTRIBUTE DATABASE PARTITION GROUPを使用します。これは、パーティションを追加した場合や、現在のパーティションの中に不平衡なデータ・ボリュームを発見した場合に役立ちます。
SQL関数のHASHEDVALUEとDBPARTITIONNUMを使用すると、ハッシュ・パーティション間またはデータベース・パーティション間の現在のデータ分散を判別できます。1つまたは複数のパーティション上のデータが多すぎたり少なすぎたりすることは避けなければなりません。PARTITION関数は表の各行についてのパーティション・マップ索引を戻しますが、DBPARTITIONNUM関数は各行のパーティション番号を戻します。例えば、ある表の現在のデータ分散を知るには次のようにします。
SELECT DBPARTITIONNUM(column), COUNT(*) |
| （注：赤字は各自の環境に置き換えてください） |
- 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー（CLP）→REDISTRIBUTE DATABASE PARTITION GROUP
編集局：第7回は「継続的なメンテナンス」「データベース・パーティショニング・フィーチャー（DPF）のパフォーマンス」を扱いました。最終回となる次回は「使用率とボトルネック」「リソース」を取り上げます。
著者紹介
Fraser McArthur氏は、分散プラットフォーム（Windows／UNIX）用のDB2 UDBを開発しているIBMトロント研究所のコンサルタントです。同氏はData Management Partner Enablement organizationのメンバーであり、IBMビジネス・パートナーとともに、DB2へのアプリケーションの移行とパフォーマンス・チューニングに取り組んでいます。また同氏は、DB2管理とアプリケーション開発の両方におけるDB2 Certified Solutions Expertです。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。