Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

BLUアクセラレーションのルーツを探る

2013/09/06 00:00

みなさんこんにちは。第2回を担当します、日本アイ・ビー・エム システムズ・エンジニアリングの白井です。第1回でご紹介の通り、2013年の6月から出荷されたDB2(*1)10.5で最も注目すべき新しい技術が、「BLUアクセラレーション」です。 BLUアクセラレーションは、データ・アナリティクス処理を、難しいチューニングなしに、簡単に高速化させることのできる機能です。今回から3回に分けて、BLUアクセラレーションが高速処理を実現するテクノロジーについて、少しずつ解説します。どうぞよろしくお願いいたします。*1) 本稿では、単にDB2と記載した場合には、メインフレームのDB2ではなく、DB2 for Linux, UNIX, and Windowsのこととします。)

1. BLUアクセラレーション登場の背景

図1 BLU Acceleration 
 図1 BLU Acceleration 

 IBMがBLUアクセラレーションの開発を目指すことになった背景から始めます。データ・アナリティクス処理において、性能の最適化は、常にデータベース管理者を悩ませ続けてきました。過去の経験から、利用者が検索条件として利用する頻度の高い列に索引をつけたり、あるいはマテリアライズ照会表(MQT)(*2)のような技術を使って必要な性能を確保する、というアプローチがなされてきました。

 (*2)マテリアライズ照会表(MQT):巨大な表の結合や大量データの集計のようにコストの高い処理の結果セットを、予め別の表にキャッシュしておくことのできる機能。DB2は、クエリーの処理時間の短縮のために効果があると判断した場合には、マテリアライズ照会表にキャッシュされたデータを自動的に利用することができる。実際に実行されるクエリーにマッチしたMQTを適切に定義できるかどうかが、性能向上の鍵となる。

 このようなアプローチは、定型のサマリーレポートを作成するような分析や、分析の軸があまり変わらないようなシステムでは有効な方法でしたが、分析担当者が自由な分析を行うようなシステムでは、データ取得の条件や集計の軸を予め完全に予測することが不可能なため、想定外の軸で分析が実行されると、急に性能が劣化するケースが発生していました。ですから、分析担当者が、次々に新しい切り口で分析を進めたくても、性能にばらつきがあり、個々のクエリー実行開始の後、応答をしばらく待てば良いのか、それとも明日まで待つべきなのかわからない状況も発生していました。

図2 非定型検索に対する性能最適化はむずかしい
図2 非定型検索に対する性能最適化はむずかしい

 本来、分析担当者は、ある分析の結果を見てまた別の切り口での分析を試みるなど、分析を連続的にインタラクティブに実施したいはずですが、クエリー結果を待つ時間によって思考が分断されてしまい、せっかくデータを蓄えても、そのデータの活用が十分にできていない、という状況も決して珍しくなかったと思います。

 IBMがBLUアクセラレーションで解決したかった課題点はここにあります。 どのような切り口でクエリーが実行されるのか、事前に正確に予測するのが難しいシステムにおいて、特別なチューニングを実施しなくても、常に安定した応答時間を実現できるような技術の開発をIBMは目指しました。 BLUアクセラレーションが提供する価値は、データ・アナリティクス処理の高速化はもちろんのこと、特に重要な点は、それを索引チューニング等の煩雑な作業なく実現できる点です。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 白井 徹哉(シライ テツヤ)

    日本アイ・ビー・エム システムズ・エンジニアリング株式会社 コンサルティングITスペシャリスト   1992年日本IBM入社。 1995年からDB2の技術サポートを担当し、最新技術の紹介や、それらを活用した先進プロジェクトの支援を社内外で幅広く実施。 昨年の東京マラソン完走以...

バックナンバー

連載:徹底解説!IBM DB2 10.5
All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5