 |
DB2 Developer Domain > 製品別技術情報 > カンタン！DB2テクテク第1歩 拡張機能編 >
カンタン！DB2テクテク第1歩 拡張機能編
|
| |
|
 |
|
製品説明
IBM Red Brick Warehouse はデータ・ウェアハウス専用に設計されたリレーショナル型データベースです。スタースキーマに最適化されたエンジン、それを支える索引技術によって、データ・ソースからの高速ロード、検索時の高速クエリーを実現します。また、OLTP
処理を得意とする汎用データベースを基幹システムに配置し連携することで、ユーザーにとって使いやすい環境が構築できます。
Red Brickの変遷について
- 1991年Red Brick社からリリース開始をしました。W．H．Inmonの提唱したデータ・ウェアハウスの理論と、R．Kimballの提唱したスタースキーマの理論を着実に実装しました。
- 1998年12月Informix社に、2001年7月IBMへ引き継がれました。
- 2002年7月現在では、 Red Brick Warehouse 6.11xC4を出荷しています。
- 2002年第3Qには、最新Verの6．20を出荷します、SQL99OLAP関数の対応、パフォーマンスモニタ、バッククアップ機能の強化、XML形式のデータ対応等の新機能が追加される予定です。
実績について
- 多数のビッグカスタマーで使用されています。
- 全世界で1100社を超えるカスタマーサイトで稼動しています。
日本ではパートナー様を通じて650社以上の実績があり、各社業界毎のテンプレート（業務モデル）を開発、販売をしています。（パートナー：富士通SSL、CTC、インフォコム、コンパック、シャープシステムプロダクト、スターネット、
テクマトリックス、NEC、日本電子計算、ビーコンIT）
特徴について
- DWHマーケットでは代表的な製品に成長しました。
- 多数のデータウェアハウスに特化した機能を持っています。例えば、独自のOLAP用拡張関数、Vista機能を使用すると
多次元データベースと同等なパフォーマンスを実現します。ただし、OLTPに特化したトランザクション処理、ストアドプロシージャ、トリガー機能は持ちません。
- 最大の特徴は、優れたローディング性能とクエリー性能です。
競合製品について
製品構成
Red Brickは3つの製品から構成されています。
1.Red Brick Warehouse
多数のプラットフォームに対応し、データベースエンジン及びUNIX版のODBC、JDBCドライバーを含んでいます。データベースエンジンでは、SQLのコマンドI／FのRISQLエントリツール（サーバ版）、データロードのTMUや事前集約のVista機能が使用できます。
|
サーバー対応プラットフォーム |
| 32Bit Version |
AIX，Sun Solaris，HP-UX，Linux，Windows NT，Windows2000 |
| 64Bit Version |
AIX，Sun Solaris，HP-UX，Compaq TRU64，IRIX |
2.Client Connector Pack（クライアント コネクタ パック）
Windowsクライアントからデータベース接続するためのドライバーを含んでいます。ODBCドライバー
、JDBCドライバー 、RISQLエントリツール（クライアント版）、及びRISQLレポーターから構成されています。ODBCドライバーはOLAPツール（Business ObjectsやBrio等）やC言語で作成されたアプリケーションと、またJDBCドライバーはアプレットやサーブレットと接続します、製品固有のネイティブな接続はありません。
RISQLレポーターは、RISQLエントリーツールにレポートフォーマット設定機能を付加しています。
| クライアント対応プラットフォーム |
| Windos98，WindowsNT，Windows2000 |
3.Administrator（アドミニストレーター）
WindowsベースのGUI管理ツールで容易にDBAの作業を実行するこ とができます（DDLの作成、ユーザー、ロール及びマクロの管理、データベースの変更、Vistaの管理、システムテーブルの表示、SQLクエリーの実行が主な機能です）。
データベースエンジンとODBCドライバーを通して接続し、対応プラットフォームはClient Connector Packに準じています。
スタースキーマ構成
スタースキーマの構成
スタースキーマは、中央に履歴や意思決定に使用する大きな表（以下、ファクト表）を配置し、その周辺に期間表、商品表、顧客表などの参照用のマスター表（以下、ディメンション表）を配置します。スターの形をしているのでこの名前がつけられました。ファクト表とディメンション表は、ディメンション表にある主キーをファクト表の外部キーで参照することで関係づけしています。（参照整合性）
スタースキーマの問題点
スタースキーマは、DWHにおいて最適なモデリング手法ですが、一般的にロード性能と検索性能に問題が生じるとされています。
- ロード性能では、参照整合性のチェックをロード時に行なう場合、データベースのロード性能を低下させます。
- 検索性能では、多数表のジョイン処理で中間表を多数作成しパフォーマンスを悪化させます。
Red Brickのスタースキーマへの対応
OLTPによるオーバーヘッドの排除、スタースキーマに特化した索引やジョイン技術によって、高速ロードと高速クエリーを実現しています。
OLTPの正規化構造であっても構築は可能ですが、十分な性能は発揮できません。
使用できる索引
Red Brickの索引はデータ検索とデータジョインを目的とし、3種類の索引を提供しています。
STAR index/STAR join
複数の表をジョインをした状態で保持したのがこの索引です。ファクト表と各レコード行が参照するディメンション表のRow IDの組合せを索引としたものです。ジョイン検索の場合、STAR indexを使用して即座に検索対象をみつけます。
STAR indexを使用したジョインアルゴリズムをSTAR Joinと呼びます。STAR Joinでは中間表を作成しないため結合する表数に関係なく高速に処理できます、ジョイン処理中で最も高速です。
TARGET index/TARGET join
制約のゆるいデータを検索する、そしてSTAR joinを補完する目的で使用します。
単なるBitmap Indexではなく、データの内容の種類数に応じてより詳細な指定ができます。SMALLは～75種類、MEDIUMは75～1000種類、LARGEは1000～10000種類が最適とされています。また作成する索引を自動的に判別するハイブリッドでの作成も可能です。Bitmapで保持する事で索引のブロック数が削減され、Btree索引に比べI／O回数は少なくすみます。
TARGET indexは、単項目のみに付加できます。
この索引を使用したジョインアルゴリズムをTARGET joinと呼びます。TARGET joinでは中間表を1つのみ作成し、STAR joinの次に高速です。
Btree index
OLTPデータベース標準の単一テーブル索引で、プライマリキーには自動的に作成されます。この索引を使用したジョインアルゴリズムは、Btree joinと呼びます。
索引を使用したジョイン
| STAR join |
|
|
|
|
説明 |
| 1. |
DB作成時に、STAR indexを作成する。 |
| 2. |
クエリー実行時に、STAR indexを使用しジョインする。 |
| 中間表の数 |
| |
中間表は作成しない。 |
| 処理の 高速性 |
| |
ジョインする表数は性能に関係しない。◎ |
| TARGET join |
|
|
|
|
説明 |
| 1. |
DB作成時に、TARGET indexを作成する。 |
| 2. |
クエリー実行時に、ディメンション表と ファクト表からrowIDを取得、中間表
を作成しジョインする。 |
| 中間表の数 |
| |
中間表は1つ作成する。 |
| 処理の 高速性 |
| |
ジョインする表数は性能に関係しない。○ |
| Btree join |
|
|
|
|
説明 |
| 1. |
DB作成時に、Btree indexを作成する。 |
| 2. |
クエリー実行時に、表1はフルスキャンし表2は索引スキャンする。 |
| 3. |
中間表を作成しジョインする。 |
| 中間表の数 |
| |
中間表は（ジョインする表数～1）つ作成する。 |
| 処理の 高速性 |
| |
ジョインする表数が多くなるに従い性能が低下する。△ |
ローディング
Table Management Utility (TMU)
Table Management Utility (TMU)は、データベースの整合性を保持しながらデータロードを行います。ロードの機能以外にも、以下の機能を提供します。
・ データのアンロード
・ 表／索引の再構築
・ DDLの作成
・ データベースの更新
Parallel TMU
RedBrickではデータベースをロードするには5つの手順に従います。TMUでは全ての処理を1プロセスで実行をしますが、PTMUは各処理を複数のプロセスに割振り実行をします。
・ データの変換
・ データの読み込み
・ 参照性整合性のチェック
・ 索引の生成
・ サマリデータの生成
5つの処理を並列処理技術で高速に処理（1件ずつのデータがパイプの中を流れるように、すべてのパイプを通過した時点で処理が終わることからパイプライン処理と呼ばれています）し、そのスピードは業界トップクラスといわれています。
TMU Auto-Aggregate
Auto～Aggregate機能は、データロードを行いながらVistaで使用する集約表に集約結果を格納をします。
明細表と集約表間の整合性を保証します。
Vista
Vistaは事前計算された集約を使用してクエリーの性能を向上させるための機能です。図中の番号をもとにVistaの動作を説明します。
1.Vistaを使用しない場合
Vista機能を使用しない場合、売上明細表にクエリーを実行します。例えば、毎日のデータから四半期の平均売上を計算する場合、膨大な数の行をグループ化して計算する必要があり数十分又は数時間を要します。
2.Vistaを使用するため準備（Vistaへの登録）
月次売上集計ビュー（事前計算ビュー）と月次売上集計表（集約表）を作成します。事前計算ビューはユーザーからのリクエストクエリーと集約表の関連づけを行い、集約表は集約結果を格納します（初回は手動で結果を格納します）。その後、Vista機能を有効にします。
3.クエリーの実行
Vista機能は、ユーザーからのリクエストクエリーを月次売上集計ビューと照合せて登録対象かを判断します。対象であればクエリーを内部的に月次売上集計表を参照するクエリーにリライトし実行をします。
4.結果の抽出
クエリーがリライトされることを意識する必要はありません、ユーザーからは売上明細表からの集約した結果に見えますが、実際には月次売上集計表に対しクエリーが実行されます。Vista機能を使用すると、レスポンス時間は数秒に短縮できます。
Vistaの機能の実現には一見単純そうに見えますが、データの整合性やクエリーの書き換えなどでVistaの中にもいくつかの明細の
機能を持っています。それら3つの機能について説明をします。
Navigator機能
Navigatorは、集約表を使用してクエ リ時間を大幅に短縮させる機能で、 クエリーのリライトシステムとも呼ばれて
います。リクエストクエリーをもとに次の ことを行ないます。
- 事前計算ビューに登録されているクエリーかどうかを判断します。
- 一致したならば、クエリーを置換し集約表を参照します。
Advisor機能
Advisorはデータベースに対する集約クエリーの動作ログを記録する機能を提供します。ログに記録されたクエリーから、次のものを分析します。
- 集約の利用状況を記録します。
- クエリーパフォーマンスを向上させる新 しい集約を分析結果をもとに、DBAに
提案します。
メタデータ機能
メタデータは、明細表と集約表間のデータ整合性を保証するための機能です。
明細表へのInsert、Update、delete処理やTMUでのAUTO Aggregate の際に実行します。
この機能により常に新しいデータを集約表から取り出すことができます。
|
|
|
