IBM 連合データベース・テクノロジー

コンテンツ はじめに IBM 連合ソリューションの特長 IBM の連合機能の仕組み 連合データベース・システムの使用 結論 参考文献 著者について 執筆者 Laura Haas Eileen Lin 共著 Information Integration Development, San Jose, CA

はじめに
大規模な近代的エンタープライズでは、組識のさまざまな部門が異なるデータベース管理システムを使用して重要なデータを保管し検索することが、ほとんど避けられない状態です。競争、進化するテクノロジー、合併、買収、地理的分散、成長の集中を排除する不可避な傾向は、すべてこの多様性の要因です。一方、これらシステムからの情報を組み合わせることによってのみ、企業は所有するデータの価値を最大限引き出せます。

たとえば、金融業界では、企業合併はめずらしいことではありません。新たに作成される企業体は企業の合併前のデータ・ストアーを継承します。これらのデータ・ストアーの多くはリレーショナル・データベース管理システムですが、往々にして異なるベンダー製であったりします。たとえば、一方が主に Sybase を使用し、もう一方が Informix^® IDS を使用するといった具合です。両社はローンのコピーなどのテキスト文書の保管用に、Documentum や IBM Content Manager などの文書管理システムをそれぞれ 1 つ以上備えているかもしれません。また、重要な情報 (特定の顧客に対するローン・リスクなど) を計算したり、顧客の購買パターンに関する情報をマイニングするアプリケーションを、各社がそれぞれ持っているかもしれません。

合併後、両社の店舗から全顧客情報をアクセスし、既存および新規アプリケーションを用いて新規ポートフォリオを分析し、そして一般的に、共通インターフェースを通して両社の合体したリソースを使用できなければなりません。両社に共通の顧客について、各社はこれまでまったく異なる識別キーを使用して識別していましたが、その共通顧客を識別して口座を統合する必要があります。連合テクノロジーは、統一されたインターフェースを多様なデータに提供することにより、このような状況での痛みを大幅に緩和できます。

IBM は連合テクノロジーに大きな投資をしてきており、それがデータ管理製品ポートフォリオ全体にわたる市場最先端の機能につながりました。現在、連合機能によって、あらゆる情報ストアーに保管された (構造化形式であろうと非構造化形式であろうと) いかなる形式のいかなるデジタル情報に対しても、統一されたアクセスができます。連合機能は、DB2^® UDB （および DB2 リレーショナル・コネクト）、DB2 DataJoiner^®、および IBM Enterprise Information Portal (EIP) を含む多様な IBM 製品を通して提供されています。今後もこの連合テクノロジー一式の機能強化は続き、これら製品へのお客様の投資は本物のビジネス価値を引き続き生み出します。

この文書では、IBM ソフトウェアからの次世代の情報連合拡張を表す「ガーリック」というコード名で呼ばれるテクノロジーを通して実装された、先進的なデータベース連合機能に特に焦点を当てます。この機能拡張により、クライアントは広範囲のリレーショナルおよび非リレーショナル・データ・ソースの専用演算機能とデータにアクセスして統合できます。ガーリック・テクノロジーは、連合テクノロジー提供する IBM ソフトウェア・オファリングのすべてに次第に組み込まれます。お客様には、既存製品に対するこれまでの投資が保護されるばかりか、将来どの製品を選択しようと、本書で解説する先進機能を活用できることが保証されます。

IBM の連合データベース・システムは、複数のデータ・ソースからの情報を組み合わせる強力な仕組みを提供します。以前の製品 DB2 DataJoiner [3] からの最新鋭テクノロジーを基に構築され、ガーリック研究プロジェクト [2] からの拡張性およびパフォーマンスのための最新鋭機能で強化されており、IBM の連合データベース機能は業界でも希有な機能です。DB2 DataJoiner は、複数の異種混合リレーショナル・データ・ソースをまとめて連合させることによって作成した仮想データベースの概念を導入しました。DB2 DataJoiner のユーザーは、データ・ロケーション、データ・ストアーの SQL ダイアレクト、あるいはこれらストアーの機能などを気にせずに、連合システム内の任意の場所に保管されたデータに対して自由な照会ができました。そして、ユーザーは連合内の任意のデータに対して DB2 のフル機能を使用できました。ガーリック・プロジェクトは、このアイデアを拡張し、非リレーショナル・データ・ソースも含めた多様なデータ・ソースの照会機能を効果的に活用する連合データベース・システムを構築することの実現可能性を示しました。現在の DB2 で実施しているのと同様に、これらシステムの両方で、ミドルウェア照会プロセッサーは最適化された実行プランを策定し、データ・ソースに欠けている機能があればそれを補完します。

この記事では、IBM の連合テクノロジーの主要な特性を解説します。特性には、透過性、異種性、高度な関数、基になる連合ソースの自律性、拡張性、オープン性、そして最適化されたパフォーマンスなどがあります。次に、覆いを除いて IBM のデータベース連合機能の仕組みを示します。さまざまなシナリオで連合機能をどのように使用できるかを示し、将来の方向性を導きます。

上に戻る

連合の拡張性とオープン性
あらゆるシステムは、時とともに進化する必要があります。連合システムでは、ユーザー・ビジネスの常に変化するニーズを満たすために、新しいソースが必要になる場合があります。IBM は新規ソースを追加しやすくしています。連合データベース・エンジンは、ラッパーとして知られるソフトウェア・コンポーネント経由でソースをアクセスします。新たな種類のデータ・ソースのアクセスは、そのソース用のラッパーを取得するか作成するかして実施されます。ラッパー・アーキテクチャーでは、新規ラッパーの作成が可能です。ラッパーが存在すれば、進行中の照会やトランザクションを中断しなくても、簡単なデータ定義 (DDL) ステートメントでソースを動的に連合に追加できます。

いかなるデータ・ソースもラップできます。IBM は ANSI SQL/MED 標準 [1] (MED とは Management of External Data の略) をサポートします。この標準は、連合サーバーが外部データ・ソースとの通信に使用するプロトコルを記述しています。ラッパーが SQL/MED インターフェースに従って記述されたものであれば、IBM の連合データベースと共に使用できます。したがって、ラッパーは IBM だけでなくサード・パーティーも作成でき、IBM の連合データベースと一緒に使用できます。

データ・ソースの自律性
通常、データ・ソースには既存のアプリケーションがありユーザーがいます。したがって、連合に組み込まれても、ソースの操作が影響されることがあってはなりません。IBM の連合データベースは、既存データ・ソースのローカル操作を妨げません。既存アプリケーションは無修正で稼動し、データは移動も変更もされず、インターフェースも変わりません。連合システムに対するグローバル照会が多くの異なるデータ・ソースに触れることはあったとしても、データ・ソースがデータ要求を処理する方法がそれらグローバル照会の実行で影響されることはありません。同様に、データ・ソースが連合に加わったり抜けたりする際に、ローカル・システムの一貫性に影響はありません。唯一の例外は、連合に参加するソースに対する連合 2 相コミット処理中です。(DB2 V7 では使えませんが、連合 2 相コミットは、DataJoiner で使用されていました。) 同じ作業単位に含まれるデータ・ソースはコミット処理に加わる必要があり、必要であれば関連する変更をロールバックすることが求められます。

他の製品とは異なり、ラッパー・アーキテクチャーではデータ・ソースをホストするマシン上にソフトウェアをインストールする必要はありません。データ・ソースとは、ソースの通常のクライアントを使用して、クライアント/サーバー・アーキテクチャーを介して通信します。このように、IBM の連合データ・ソースは、ソースにとってもう 1 つのアプリケーションのように見えます。

最適化されたパフォーマンス
オプティマイザーはリレーショナル・データベース管理システムのコンポーネントで、各照会の実行に最良の方法を決定します。リレーショナル照会は非手続き型で、各リレーショナル操作の実装方法が通常は数種類あり、照会実行において操作の順序も多くの中から選べます。オプティマイザーによっては、発見的ルールを使用して実行ストラテジーを選択するものもあれば、IBM の連合データベースはさまざまなストラテジーを考慮して、各ストラテジーのコスト見積りをモデル化し、最小コストのものを選びます (通常、コストは消費されるシステム・リソースに関して計測されます)。

連合システムでは、オプティマイザーは照会に関わるさまざまな操作が連合サーバーで実施されるべきか、あるいはデータが保管されているソースで実施されるべきかを決定する必要があります。また、操作の順序と、照会のローカル部分の実施にどのインプリメンテーションを使用するかを決定する必要があります。これらの意思決定を行うために、オプティマイザーは各データ・ソースが何ができ、どれだけコストがかかるかを知る手段を持っていなければなりません。たとえば、データ・ソースがファイルの場合、それが高機能であると仮定してソートの実施や特定の機能の適用を依頼するのは、理にかないません。一方、ソースがリレーショナル・データベース・システムで述部の適用や結合の実施ができる場合、ソースで実施した方が連合エンジンに戻されるべきデータ量が削減されるのなら、ソースのパワーを活用した方がいいかもしれません。これは通常、個々の照会の詳細に依存します。IBM オプティマイザーは照会に関与するさまざまなソース用のラッパーと共に作用して、可能性を評価します。実行ストラテジーの決定の善し悪しの違いは、パフォーマンスが何桁も違う結果になることがよくあります。ラッパーと共に機能して多様なソースにわたる連合照会のコストをモデル化できる IBM の連合データベースの機能は、業界でも独特なものです。結果的に、ユーザーは可能な限り最高のパフォーマンスを連合システムから期待できます。

パフォーマンスをさらに改善するために、各ラッパー・インプリメンテーションは、ソースのネイティブ API を使用して各データ・ソースが提供する操作ノブを活用します。たとえば、複数の結果行を 1 つのメッセージにブロッキングすること (ブロック・フェッチとして知られています) は、一般的なパフォーマンス・ノブです。照会コンパイラーはラッパーとやりとりして、どの照会フラグメントがブロック・フェッチを利用でき、照会セマンティクスに無駄がなく実行時に最高のパフォーマンスを実現できるかを示唆します。

上に戻る

CREATE WRAPPER web_wrapper
LIBRARY "/u/haas/wrappers/libweb.a"

CREATE SERVER weather_server
WRAPPER web_wrapper OPTIONS (URL 'http://www.weatherforecast.com')

CREATE NICKNAME weather
      (zone integer, climate varchar(10),  yearly_rainfall float)
      SERVER weather_server  OPTIONS (QUERY_METHOD 'GET')

SELECT c.Name, c.Address
FROM customers c, stores s, weather w
WHERE temp_forecast(w.zone, :DATE) >= 85 AND
		c.ShopsAt = s.id and s.location = w.zone

CREATE FUNCTION temp_forecast (integer, date) RETURNS float AS TEMPLATE
 DETERMINISTIC NO EXTERNAL ACTION

CREATE FUNCTION MAPPING tf1 for temp_forecast SERVER weather_server

1. 照会フラグメントを単一ソースに適用する場合、IBM 連合データベースは「requests (要求)」と呼ばれる候補の照会フラグメントをラッパーにサブミットします。
2. 非リレーショナル・ラッパーが要求を受け取ると、(もしあれば) 対応する照会フラグメントのどの部分をデータ・ソースで実行できるかを見極めます。
3. ラッパーは、受け入れたフラグメント部分を記述した応答を返します。応答には、生成される行数予測、合計実行時間予測、およびラッパー・プランを含みます。ラッパー・プランとは、受け入れたフラグメント部分を実行するためにラッパーが知るべき情報をすべてカプセル化して表現したものです。
4. 連合データベース・オプティマイザーは応答をグローバル・プランに組み込み、ラッパーで受け入れられなかったフラグメント部分を補うために必要に応じて追加演算子を導入します。応答からのコストとカーディナリティー情報は、プランの総コスト見積りに使用され、数多くの候補の中から総コストが最小のプランが選択されます。プランが選択されても、即時実行は必要ありません。データベース・カタログに保管しておいて、後で何度でも照会実行に使用できます。プランが即座に使用される場合でも、作成されたのと同じプロセスで実行される必要はありません (図 3 参照)。

SELECT TickerSymbol, StockName
FROM Stocks
WHERE Exchange='NYSE' AND Closing - Opening > 5 

1. ISO/IEC 9075-9:2000. Information technology -- Database languages -- SQL -- Part 9: Management of External Data (SQL/MED). 国際標準化機構 (ISO) 2000。
2. M. Carey 他著 『Towards heterogeneous multimedia information systems』(1995 年 3 月の Intl. Workshop on Research Issues in Data Engineering における議事録より)
3. P. Gupta & E. T. Lin 著 『Datajoiner: A practical approach to multi-database access』(1994 年 9 月に米国テキサス州オースチンで開催された、並列および分散情報システムに関する International IEEE Conference における議事録より)
4. V. Josifovski、P. Schwarz、L. Haas、E. Lin 共著 『Garlic: A New Flavor of Federated Query Processing for DB2』(2002 年 6 月、米国ワイオミング州マディソンで開催された SIGMOD 2002 における議事録より)

	Laura Haas Laura Haas 氏は、IBM ソフトウェア・グループのシニア・マネージャー。連合データベースおよび XML 照会など、情報統合と生命科学に関する主要テクノロジーを含め、DB2 UDB 照会コンパイラーの開発の責任を担う。以前は、IBM アルマデン研究所における研究員兼マネージャー。
	Eileen Lin Eileen Lin 氏は、カリフォルニア州サンノゼにあるシリコンバレー研究所のシニア・ソフトウェア・エンジニア。V7 の DB2 連合システの前身である連合データベース製品、DataJoiner の成功に貢献したオリジナル・メンバーの一人である。現在は DB2 および DiscoverylinkTM 連合機能の技術面を率いる。

原文はこちら

上に戻る