表/索引のメンテナンスとパーティション設計DB2チューニング・ベストプラクティス(7)(2/2 ページ)

» 2005年01月07日 00時00分 公開
[Fraser McArthurDB2 Enablement Consultant/IBM Canada Ltd.]
前のページへ 1|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 
AS (SELECT * FROM source_table
DATA INITIALLY DEFERRED REFRESH IMMEDIATE REPLICATED
(注:赤字は各自の環境に置き換えてください)

 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(*) 
FROM table GROUP BY DBPARTITIONNUM(column)
(注:赤字は各自の環境に置き換えてください)

  • 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー(CLP)→REDISTRIBUTE DATABASE PARTITION GROUP

編集局:第7回は「継続的なメンテナンス」「データベース・パーティショニング・フィーチャー(DPF)のパフォーマンス」を扱いました。最終回となる次回は「使用率とボトルネック」「リソース」を取り上げます。

著者紹介

Fraser McArthur

Fraser McArthur氏は、分散プラットフォーム(Windows/UNIX)用のDB2 UDBを開発しているIBMトロント研究所のコンサルタントです。同氏はData Management Partner Enablement organizationのメンバーであり、IBMビジネス・パートナーとともに、DB2へのアプリケーションの移行とパフォーマンス・チューニングに取り組んでいます。また同氏は、DB2管理とアプリケーション開発の両方におけるDB2 Certified Solutions Expertです。



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。