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

はじめに

前回は、DWHの性能を高める方策として、DWHアプライアンスやカラムストアDBなど、製品面での工夫について解説しました。今回は、SEの視点に立ったチューニング・ポイントを中心に解説します。具体的には、数百T～P（ペタ）バイトの大規模DWHを想定し、インデックスに代表される一般的なOLTP系のチューニング手法とは異なるノウハウを解説します。

昨今、特にDWHアプライアンスなどの製品では「チューニング不要」といったセールス・トークが見受けられます。ですが、これはあくまでもハードウエア性能に頼った対策であり、膨大な投資コストとのトレード・オフに過ぎません。

また、レコード数が数兆件に及ぶ数百T～P（ペタ）バイトのデータを扱う大規模DWHの場合、現実的な投資コストを考えると、ハードウエア性能や製品性能に頼る対策だけでは限界があります。

実際には、カラムストアやパーティショニング、サマリー・テーブルなどによってクエリーにかかるコストを削減する、いわゆる細かいチューニング手法の組み合わせが必要になります。今回はあくまでも筆者の経験の範囲内ですが、日ごろ利用しているチューニング手法の代表例として、いくつかを紹介します。

1.カラムストア

カラムストアについては前回も触れましたが、チューニングの観点では非常に有用なので、今回も引き続いて解説します。

カラムストアは、テーブルを行単位ではなく列単位で格納する機能です。走査（スキャン）するデータの範囲をSQLで指定した列に限定できるため、検索処理が早くなります。

カラムストアの具体的な動作は、図1の通りです。

受発注履歴テーブル（1億レコード）の合計金額を求めたい場合、通常の行ストア方式のケースではレコード・サイズ200バイト×1億レコード＝合計約18Gバイトの走査量が発生してしまいます。

一方、カラムストア方式であれば、購入金額のみの走査となるため、レコード・サイズ8バイト×1億レコード＝合計約0.7Gバイト、つまり通常の行ストア方式と比べて約25分の1の走査量で済みます。

このように、特定カラムのフルスキャンを行う場合、カラムストアは非常に有効なチューニング手段となります。

ただし、カラムストアは万能というわけではありません。走査対象の列サイズが増えるごとに、比例して検索実行時間が増加してしまいます。

あくまでも筆者の検証経験からの推察となりますが、全体の列サイズの5割程度を超えると、カラムストア型の方が遅くなる傾向にあるようです。よって、用途に応じた使い分けが必要です。

アプリケーションのクエリー特性を踏まえて、どちらの方式を選択すべきかを判断し、場合によっては行ストア、カラムストア両方の形式で格納するなど、使い分けることが必要です。

次ページからは、SE視点での、そのほかのチューニング方法を解説します。