TOP>企業情報>コラム>技術情報>DWH系処理に汎用DBMSを利用する課題 Vol.1

DWH系処理に汎用DBMSを利用する課題 Vol.1

本連載では、DWH系処理における汎用DBMSの課題を確認しながら、よりDWH系処理に特化したDWH専用DBMSの優位性について解説します。第1回目となる今回は、現在最も利用されている行ベースの汎用DBMSをDWH系処理で利用する課題について検討します。

(全3回連載)

Vol.1 行ベースの汎用DBMSをDWH系処理で利用する課題

なぜDWHが必要なのか


これまで汎用DBMSとして利用されてきたRDBMS(関係データベース管理システム)ですが、近年では基幹系システムのOLTP(オンライン・トランザクション処理)のみならず、情報系システムのデータ・ウェアハウス(以下、DWH)系処理でも広く利用されています。

第1回目となる今回は、DWH系処理の特徴を踏まえた上で、現在最も普及している汎用DBMSのDWH系処理における課題について検討します。まず本題に入る前に「なぜDWHが必要とされているのか」について、時代背景にも触れながら確認しておきます。

1969年にE.F.コッドが提唱し、1980年代には実用化を経て普及期を迎えるRDBMSですが、1990年代にはネオダマ(ネットワーク、オープンシステム、ダウンサイジング、マルチメディアの略)と呼ばれる急激な技術革新により、大型汎用機で統合化されていたデータは、ローカル組織ごとに構築されたサーバに分散されます。その結果、分断されたシステム間ではデータの横串しができなくなり、経営のための情報活用は一層困難な時代を迎えます。そこで登場したのが、1990年代後半にW.H.インモンが提唱したDWH(データ・ウェアハウス)という仕組みです。DWHとはその名のとおり「データの倉庫」であり、データ分析で用いられるデータが長期間にわたって蓄積されます。DWHは様々な情報活用ニーズに対応するため、格納されるデータは顧客や売上など目的別に整理/統合され、削除/更新されずに時系列に保持されます。また、DWHには基幹系システムの業務データだけでなく、分析に必要となる様々なデータも取り込まれるようになります。

例えば、ネオダマで分散したローカル組織のデータや、国内外の工場や営業拠点で管理されているデータ、グループ会社や取引先が提供するデータ、分析用に購入する市場データなどの外部データです。最近では、Webサイトのログ・データやソーシャル・メディア・データ、さらには、GPSやICカードなどの検知により発生するセンサー・データなども入手できるようになり、分析対象として注目する企業が増えています。例えば、顧客の購買履歴/行動履歴/プロファイルなどのデータを分析することで、担当者の経験や勘といった曖昧な将来予測ではなく、より的確で戦略的なダイレクト・マーケティング(例:ダイレクト・メール、クーポン、レコメンデーションなど)ができるようになります。ビッグデータ時代とも言われる現在、これまで以上に大規模なデータをいかに高速かつ高い頻度で分析できるかが、情報活用基盤であるDWHに求められています。

それでは、DWH系処理とは一体どのような処理なのか、その特徴についてご紹介します。

DWH系処理における特徴


DWHという言葉は知っていても、DWH系のデータ・モデルやDWH系特有のSQLについては、意外と知られていないように見受けられます。ここでは、DWH系ならではのテーブル設計とSQLについてご紹介します。

DWH系のテーブル設計


DWH系の代表的なデータ・モデルである、「スター・スキーマ」を例に説明します。図1のように、スター・スキーマは、エンティティ・リレーションシップ・ダイアグラム(以下、ER図)で表すと、中央のテーブルから放射状に各テーブルが配置されるため、その形状(星状)からそのように呼ばれています。 分析対象となる「ファクト表」を中央に配置し、分析軸となる「ディメンジョン表」をその周りに配置することで、データを分析するユーザから見てもわかりやすいモデルだと言えます。

図1:Star Schema BenchmarkのER図(スター・スキーマ型)

図1:Star Schema BenchmarkのER図(スター・スキーマ型)

ここに例示したスター・スキーマ型のデータ・モデルは、DWH向けのベンチマーク・ツール「Star Schema Benchmark」から引用したものです。

Star Schema Benchmarkでは、LINEORDER表がファクト表であり、商品の購入履歴が時系列に蓄積されます。ファクト表は、分析対象となる実績値が格納される明細データであり、データ件数は億単位になります。

そして、残りの表(CUSTOMER表、SUPPLIER表、PART表、DATE1表)がディメンジョン表であり、顧客やサプライヤなどの識別キーや名称などが格納されます。ディメンジョン表は、ビジネス上の分析の軸になるマスター・データであり、データ件数は少ないのが特徴です。

また、スター・スキーマ型にすることで、ファクト表に購入者の名前や住所といった冗長な文字列を保持する必要がなくなり、データ量の増加を抑えるメリットもあります。

DWH系のSQL


次に、DWH系処理で用いられるSQLの特徴について見ます。ここでも、Star Schema BenchmarkのSQLを引用します。図2のSQLには次のような特徴が確認できます。

 ①選択リストは分析軸と集約値
 ②ファクト表と複数のディメンジョン表を結合
 ③ディメンジョン表の分析軸が多様
 ④分析軸に対するグループ処理

図2:Star Schema BenchmarkのSQL

図2:Star Schema BenchmarkのSQL

また、SQL全体を俯瞰してみると、次のような特徴についても確認できます。

  ・返される結果は数件だが、広範囲のデータがアクセス対象
  ・ファクト表の列数は多いが、SQLで指定されるのはごく一部

このような特徴を持つDWH系処理において、汎用DBMSを利用する課題とはどのようなものなのか、ご紹介します。

汎用DBMSが抱える表走査の課題


汎用DBMSは行単位で処理されるため、データの格納形式も行単位のアクセスに最適化された構造になっています。具体的には、図3のように、1つが8KB~32KBのデータ・ブロックに対して、行単位に隣接する形でデータが格納されます。そのため、列数が多いとブロックに格納できる行数が少なくなり、結果としてブロック数が増加することになります。

図3:汎用DBMSのブロック構造イメージ

図3:汎用DBMSのブロック構造イメージ

図1のStar Schema BenchmarkのER図と図2のSQLを見比べるとわかりますが、DWH系処理の場合、各表には多くの列が存在する一方で、アクセスされる列が少ない傾向にあります。

しかし、汎用DBMSは行単位アクセスのため、DWH系処理で利用した場合には、「処理対象でない列にもアクセスする」といったI/O効率の課題があります。

例えば、図4の表に対して、「注文日:2011年」を条件に「売上高(sum(価格×数量))」を集計する場合、処理に必要のない列(注文番号、顧客ID、製品ID)への無駄なアクセスでI/Oが増加し、パフォーマンス低下の原因となります。

図4:汎用DBMSの表走査

図4:汎用DBMSの表走査

Indyコラム

Indy

はじめまして、ボク「インディ」!
 
DWH専用DBMS「InfinDB」のマスコットです。Infiniは英語でInfinity(無限)。記号で書くと∞だから、数字の8に似ていることからハチの姿になったんだ。

今回は出番がないって言われたんだけど、連載の主人公はボクだからね。コラムだけでもブンブン言っちゃうよ。

さっき、汎用DBMSはDWH系処理で無駄なI/Oが多いって言ってたけど、実際のところどの程度なのか教えるね。

まず、1ブロックに格納できる行数は、各種ヘッダ部分を除いたら「ブロック・サイズ÷行サイズ」で計算できるんだ。

だから、

  ・ブロック・サイズ = 8KB
  ・行サイズ = 100バイト
  ・データ件数 = 1億件
  ・必要な列の合計サイズ = 20バイト

だとしたら、

  ・1ブロックに格納される行数 = 80行(8KB÷100バイト)
  ・全件アクセス時のI/O数 = 125万ブロック(1億件÷80行)
  ・アクセスしたい列のI/O数 = 25万ブロック(125万ブロック×(20バイト÷100バイト))
  ・無駄なI/O数 = 100万ブロック(125万ブロック - 25万ブロック)

になるけど、言い換えれば、2GB(25万ブロック×8KB)のデータを分析するのに、10GB(125万ブロック×8KB)ものデータを読み込んで、その内8GB(100万ブロック×8KB)のデータを捨てているということなんだ。

こんな処理がほとんどだから、汎用DBMSをDWH系処理で使うのって、かなりもったいないよね。列指向型の僕なら無駄な列にはアクセスしないから、それだけでも数倍は処理が速いし、もっと速く飛べるヒミツがあるんだ。

次回をお楽しみに!


汎用DBMSが抱えるチューニング課題


汎用DBMSをDWH系処理に利用すると、決められた時間内に処理が終わらないといった問題が頻出するようになります。そのため、OLTPでの経験に基づいて、索引によるI/Oの削減を試みる方も多いと思います。しかし、データ分析を目的としたDWH系処理の場合、必ずしも索引が有効に働くとは限らないため、調整に苦慮することもしばしばです。

ここでは、索引をはじめとした汎用DBMSのチューニング課題についてご紹介します。

①索引設計が難しい


・ディメンジョンの分析軸が多様である
何を条件にするか決まっている定型検索には有効な索引でも、分析軸が多数あることで検索条件を予測できないDWH系では、最適な索引を事前に設計することは困難です。

・走査範囲が広い場合、索引が有効に機能しない
索引を用いたデータ・アクセスのイメージは、条件キーの値を基に索引からデータのアドレスを参照し、対象データが格納されたデータ・ブロックにランダム・アクセスします。

しかし、図5のように広範囲のデータがアクセス対象となるDWH系処理の場合、1件ずつ索引とデータにアクセスするアクセス方式は効率が良いとは言えません。

図5:汎用DBMSの索引の広範囲データ・アクセスのイメージ

図5:汎用DBMSの索引の広範囲データ・アクセスのイメージ

・索引のメンテナンスが必要である
表のデータが追加/更新/削除されると、索引に対しても索引キーの値が追加/更新/削除され、索引の構成に偏りが生じるようになります。そのため、データへの均一なアクセスを担保するためには、索引を再構成する必要があります。

また、複数列で構成される複合索引を同じ列にいくつも定義した結果、途中から使われなくなる索引も出てきます。未使用の索引は無駄にメンテナンスされるだけでなく、無駄な領域を増加させたり、他の更新処理を遅延させるような悪影響も及ぼします。そのため、索引を利用する場合には、性能を維持する上で運用中のメンテナンスが必要となります。

②パーティション・キーの設計が難しい


索引を用いずに行を絞り込む機能として、パーティショニング機能があります。

例えば、売上表の「売上年月」に対してパーティション・キーを設定した場合、SQLに指定した「売上年月」のデータに対してのみアクセスされるため、読み込みブロック数を大幅に減らすことができます。しかし、その一方で、パーティション・キーの設計が難しく、データの分布に偏りがあると効果が出ないなどの課題があります。

また、パーティショニング機能はすべての汎用DBMSで提供されているとは限らず、提供していてもオプション機能のために別途購入費用が発生する場合があります。

③データの圧縮率が高くない


汎用DBMSには、データの圧縮機能を提供しているものもあり、これによって読み込みブロック数を減らすことが可能となります。しかし、汎用DBMSのデータは行単位で格納されるため、重複値による圧縮効果はあまり期待できません。また、圧縮データはすべての列が解凍されるため、無駄にCPUの使用率を上昇させてしまう課題があります。

汎用DBMSのチューニング種類には、図6のように索引やパーティショニング以外にも様々なものがあります。チューニング項目によっては、最適化の範囲や対象だけでなく、そのために必要となるコストやスキルなども異なります。そのため、どのようなチューニングを実施するのかは、企業が抱える事情によっても変わってきます。

いずれにしても、性能問題は一朝一夕で解決できるものではなく、今後もコスト増の源になり続けます。

図6:汎用DBMSのチューニング種類

図6:汎用DBMSのチューニング種類

今回は、DWH系処理に汎用DBMSを利用する課題について洗い出し、検討しました。DWHに特化していない汎用DBMSを使い続ける限り、性能を改善/維持するためのチューニングとメンテナンスは、今後も取り組まなければならない重要課題となります。その課題を解決するために登場したDWH専用の製品が、DWHアプライアンスやDWHソフトウェアです。

次回は、これらDWHに特化した製品を取り上げながら、最近リリースされたDWH専用DBMS「InfiniDB」についてご紹介します。


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る