PR

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

2010年3月18日(木)
TIS株式会社 サービス&コミュニケーション事業部 ソリューションチーム

はじめに

前回は、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視点での、そのほかのチューニング方法を解説します。

著者
TIS株式会社 サービス&コミュニケーション事業部 ソリューションチーム
戦略の高度化に向けたシステム支援を専門にしているチームです。我々はDWHやBIを使いビジネスロジックをいかに既存のビジネスに活かしていくか、営業の高度化におけるSFAや、ポイントカードに代表されるFSPなどとDWHやBIの連携により、お客様の営業支援に役立てられればと考えております。
03-5402-2086/sales3-info@mbgx.tis.co.jp

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています