大規模化するDWHのチューニング

2.パーティショニング

パーティショニングは、一般的なチューニング手法として確立されており、広く認知されています。大規模DWHにおいても有用な手段であるため、ここではおさらいも兼ねて解説します。特に大規模DWHにおいては、大量のログを時系列単位で扱うケースが多いため、なくてはならない手法の1つです。

パーティショニングとは、分かりやすく言えば、テーブルをある列の値で論理的に分割する機能です。分割することによって、走査するデータの範囲を限定できるため、検索処理が高速になります。

パーティショニングには大きく、日時、数字などの範囲指定で分割するレンジ・パーティションと、区分、県名などの集合値で分割するリスト・パーティションの2つがあります。また、製品の機能に依存しますが、多段階のパーティショニングや、レンジ・パーティションとリスト・パーティションを組み合わせて利用することも可能です。

図2は、レンジ・パーティションとリスト・パーティションを組み合わせた活用例です。月単位のレンジ・パーティションと、サービス区分の区分値単位のリスト・パーティションを定義しています。これにより、例えば「2010年1月」の「区分2」の合計通信時間を知りたい場合、「2010年1月＋区分2」のパーティションの走査だけで済み、走査量を劇的に削減できます。

3.多段階サマリー・テーブルの活用

パーティショニングは非常に有用ですが、絞り込み後のデータ量が多い場合には、パーティショニングだけでは対処できません。

最近では、行動ターゲティングやリコメンデーションのためにWebアクセス・ログをすべて格納して分析する企業も増えています。Webアクセス・ログの場合、1カ月で数十億件になることも多く、月単位の集計をするにはパーティションで絞り込んでも数十億行の走査が必要になってしまいます。

こうした場合（データ量が多い場合）に効果的なのは、粒度の違うサマリー・テーブルを複数使う方法です。

サマリー・テーブルとは、生データをある分析軸（分単位、時間単位等）で集計したテーブルのことです。集計データが格納されているので、生データに比べてデータ量が少なくなっていることが理解できると思います。

極端な例ですが、生データが1カ月分で100億行あり、都道府県別、商品別（1000種類）のアクセス数を、1時間、1日、1週間単位の粒度で集計する場合を想定してみましょう。サマリー・テーブルがない場合、どの粒度の集計でも、常に100億行にアクセスする必要があります。

ここで、1時間単位のサマリー・テーブルを1つ作成します。このサマリー・テーブルの行数は、47都道府県×1000商品×720時間/月なので、データ件数は最大3384万行になります。1時間以上の粒度であれば、このサマリーから作成することができるので、1日、1週間単位の集計も、このサマリーから行えます。この結果、100億行の走査が必要だった処理が、3384万行の走査で済むことになります。

3384万行の走査でもまだ時間がかかるという場合は、1日単位のサマリー・テーブルを作成します。これも同様に計算すると、47都道府県×1000商品×30日/月なので、データ件数は最大141万行になります。元のデータが100億行なので、約0.01％にまでまとめることができる計算です。

今回の例では軸は3つのみですが、これに顧客属性などの軸が加わると、組み合わせの種類が多くなり、1つのサマリーで減らせる行が少なくなってしまいます。この場合は、多段階のサマリー・テーブルを持つことによって、パフォーマンスのメリットを享受できるようになります。

多段階のサマリー・テーブルにはデメリットもあります。サマリー・テーブルの数を増やせば効果が高まる反面、バッチ・ジョブ（定型処理）の本数が増加することによる管理性の悪化や、メンテナンス時間内にバッチ処理が終了しないといった問題が起こります。サマリー・テーブルのデータ量が増加することも問題です。このため、設計には十分注意が必要です。

次ページでは、データ圧縮や分散キーなどを解説します。