データ活用の新しいかたち・前編

だからこのデータは使えない！
〜歴史からひも解く「使えないデータ」のなりたち

「使えないシステム」が抱える運用上の課題　

　ここまで、データを活用するというニーズと、それを支えるシステム基盤についてお話してきました。実際のところ、こうした構成のシステムはいまもさまざまな課題とともに運用されているのが実態です。代表的な課題をいくつか列挙してみましょう。

●情報系システムにおける課題

• 運用対象システムの増加
  データ活用目的ごとにデータマートを構築し続けた結果、運用の対象となるシステムが増えてしまう
  
• ボトルネック対処コストの増加
  個々のデータマートで性能問題が発生し、データベースチューニング、プログラム変更、CPUの増設が頻発してしまう
  
• 個々のシステムでのデータ量増加
  個々のデータマートのデータ量が増え続け、個別にストレージ増設が頻発してしまう
  
• 基幹系システムへの負荷の増加
  データマートに格納するサマリデータを作る処理を担う基幹系システムなどの付加が大きくなり、これに伴う運用工数も増え続ける
  
• 新規ニーズごとの増設
  既存のデータマートは目的に合わせたサマリデータを格納しているため、新規のデータニーズに対応できず、新しいデータマートが増え続ける
  

●基幹系システムにおける課題

• メンテナンスコストの上昇
  帳票作成やサマリデータ作成などの参照系処理が増え続け、性能問題に対処するためデータベースのチューニングやバッチプログラムの変更などが頻発してしまう
  
• 処理の長時間化
  参照系処理が長時間にわたり運用工数が膨れる
  
• サービス提供能力の低下
  決まったスケジュールで帳票が出せない、決まったスケジュールでデータマートにデータを準備できないなどのサービス低下が頻発する
  
• ハード／ソフトウェアコストの上昇
  参照系処理がシステムの限界を超え、ハードウェア、ソフトウェアの増設が必要になる
  
• ストレージコストの上昇
  参照系処理を行うためのデータが増え続け、ハードウェアの増設が必要になる

　このような問題は、なにも特定のユーザーだけが抱えているわけではなく、すべてのユーザーが大なり小なり悩んでいます（あるいは、これが当たり前だと考え、淡々とコストを掛けているというユーザーもおられるとは思いますが……）。

課題を解決する選択肢 参照系に弱い汎用DB

　前項で挙げた問題はどのようにすれば解決できるのでしょうか？

　実は「データベース屋」から見ると、これらの問題の原因は明らか。というのも、前項で挙げた問題はすべてデータベースの構造に起因するものだからです。

　つまり、これらの参照系の処理を行うためのデータは汎用データベースに格納されていますが、汎用データベースは、登録系処理にはめっぽう強いが、参照系処理にはからっきし弱いのです。

　汎用データベースは、データを行（low）単位で管理しています。Excelの横1行をひとかたまりで管理しているイメージです。この構造のうえで参照系処理を行う場合を考えてみましょう。1つの行に1,000カラムあるデータに対して、ある参照処理は、この1,000カラムのうち10項目（カラム）しか必要としないとした場合を例にすると、次のような不都合が発生します。

• 関係のない行まで読み込む必要がある
  汎用データベースは行単位のデータ管理なので、1,000カラムすべてを読み込み、その後必要なデータを取り出す（莫大なディスクI/Oが発生し、時間が掛かる）
  
• 時間短縮のためにインデックスを作成するとデータ量が増える
  必要なデータの取り出しにかかる時間を短縮するため、インデックスを張る。これにより、データ量は膨れ上がる
  
• インデックスがない場合はテーブルのフルスキャンが必要
  インデックスのないデータを探すために、全テーブルスキャンという事態も起こる
  
• サマリテーブルによるデータ量増大
  インデックスを張り過ぎるとデータベースが動かなくなるので、参照目的に合わせサマリテーブルを作る。これでデータ量はさらに膨れ上がる
  
• サマリデータ処理にさらに作業コストが発生する
  サマリデータを作るための処理を行うために長時間のオペレーションが必要になる

　実は、このような問題認識は新しいものではありません。情報系システムにおけるデータウェアハウス構築では、知っている人は知っている内容です。

汎用データベースは登録系プロセスのために作られている

　以前よりテラデータやレッドブリックといったデータウェアハウス専用製品は、一部の、大量データを細かく分析するような業務では使われていました。しかし、全体を見渡すと、データウェアハウス／データマートの90％以上は、汎用データベースで構築されているのが実情です。

　加えて、データウェアハウス専用製品も、特定の分析目的に特化して使われているケースがほとんどで、高性能のデータマートという位置付けで存在しているといっても間違いではない思います。

　近年の情報系システム（BI）では、より細かなデータ、より多くのユーザー、より自由な分析を求めるニーズが急速に高まっており、データウェアハウス専用製品がこれまでになく注目されています。

　まず米国におけるデータウェアハウス事情を見てみると、データウェアハウス専用製品として、カラムストアデータベース　vs. アプライアンスの構図が明確になりつつあります。それぞれの特徴を確認しておきましょう。

カラムストアデータベース

　カラムストアデータベースというのは、汎用データベースの参照系における弱点を改善するために生まれたデータベースソフトウェアです。名前が示す通り、データを行単位ではなくカラム単位で管理します。

　これにより、参照処理における不要データの読み込みをなくし、ディスクI/Oの回数を圧倒的に削減することで性能を劇的に改善しています。さらに、データ量を肥大化するインデックス構造をとらないこととデータの圧縮機能で、汎用データベースに比べ、極めてコンパクトな高性能データウェアハウスの構築が可能となります。

　このカラムストアデータベースの分野の「老舗」として、数多くの実績を持つのが「Sybase IQ」です。米国では、このほかにもVerticaなどの新興ベンダーが近年10社近く生まれていますが、日本における純粋なカラムストアデータベースはSybase IQだけです。このため、読者の皆さんにはあまり聞きなれないカテゴリかと思いますが、実際の稼働システムの中では着実に根付いてきています。

データウェアハウスアプライアンス

　一方のアプライアンスというのは、サーバとストレージとデータベースが一体化したデータウェアハウス専用製品です。アプライアンスという言葉は本来、家庭用電化製品という意味で、到着するとすぐに使えるというイメージです。

　構造的には、ハードウェアとデータベースを参照系処理高速化のために最適化し、基本的にはハードウェアの能力で性能を確保します。データベースは、ベンダー独自のものか、データベースとしても流通しているソフトウェアが組み込まれていますが、ハードウェアの構造に合わせるために改造が施されています。

　代表的な製品として、テラデータの「Teradata Database」で、近年、ネティーザの「Netezza」、サン・マイクロシステムズの「Greenplum」、ヒューレッドパッカードの「NeoVeiw」などが挙げられます。加えて、オラクルとヒューレッドパッカードが最近発表した「Oracle Exadata」といった製品も登場しました。

参照系の負荷を軽減してTCO削減を実現する

　現在、情報系システムの高速化には前項で挙げたような製品が使われています。

　後編では、カラムストアデータベースとアプライアンスの比較をもう少ししてみます。さらに、先に述べた通り、参照系処理の高速化は情報系システムの分野だけで行われている現状から一歩抜け出し、全社のシステムに混在している参照系処理の軽量化による運用コストの大幅削減の可能性に触れます。

　このコストダウンの方法は、SOAのようなチャレンジングな取り組みではなく、従来さまざまな場面で行われてきた方法を組み合わせて、確実に実現が可能です。次回を是非お楽しみに！

3/3

後編へ→

Index
だからこのデータは使えない！ 〜歴史からひも解く「使えないデータ」のなりたち
	Page 1 ・不自然なシステム構造〜データウェアハウスの課題と変化 ・データ活用の変遷と「使えないデータ」の出現 　20年前の帳票出力
	Page 2 ・システム構造の変化 　基幹システム内でのバッチ処理出力 　参照用データベースが耐えられない！ 　サマリ化してデータを保有するデータマート 　データウェアハウスとデータマート、「産地直送型」構成 　登録系と参照系が同居し続けるエンドユーザーコンピューティング
	Page 3 ・「使えないシステム」が抱える運用上の課題　 　課題を解決する選択肢 参照系に弱い汎用DB ・汎用データベースは登録系プロセスのために作られている 　カラムストアデータベース 　データウェアハウスアプライアンス 　参照系の負荷を軽減してTCO削減を実現する

Databaseフォーラム全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）