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

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

図１ BLU Acceleration　

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

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

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

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

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

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