堤 保晴, ソフトウェアサポート&サービス IMテクニカルセールス,
IBM
2004年 11月 26日 IBM Red Brick Warehouseの連載「赤レンガ倉庫6丁目2番地 」第1回です。
記念すべき第1回は、IBM Red Brick Warehouse 6.20最新メジャーリリースバージョンのTechnical Brief
をお送りいたします。
IBM Red Brick Warehouseは過去10年間以上、12〜18ヶ月の間隔でメジャーバージョンアップの製品をリリースしてきました。今回ご提供するTechnical
Brief 6.20は、そのメジャーバージョンアップごとに発行され、IBM Red Brick
Warehouseの製品概要と新たに追加された機能を、技術的な面から紹介しています。本連載では、IBM
Red Brick Warehouse製品が持つData Warehouseに特化した技術情報や、バージョン6.20で追加された新機能の詳細情報をご紹介します。
IBM Red Brick Warehouseを従来からお使いいただいている方には、Technical
BriefのUpdate版として、また、今回初めて連載を訪れて興味を持っていただいた方には、この製品の特徴的な機能を知っていただき、今後の掲載に興味を持っていただければと思い、第１回目の今回は、IBM
Red Brick Warehouse 6.20のTechnical Briefを掲載することにしました。今後、定期的に更新、追加する予定です。ぜひ一読いただき、次回以降に予定している、より詳細な技術情報のご理解の助けになればと思います。
技術情報 − IBM Red Brick Warehouse バージョン6.20（UNIX、Linux、およびWindowsプラットフォーム版）
この技術情報では、以下の項目について概説しています。
- ビジネス・インテリジェンス・フォーカス
- 強力な照会パフォーマンス
- 強力なロード・パフォーマンス
- 本格的なユーザビリティとスケーラビリティー
- まとめ
- プラットフォーム・サポート
- バージョン6.20の新機能
あらゆる企業において、経営分析や意思決定のために、信頼性が高く、柔軟性のある方法による迅速な情報へのアクセスが求められています。IBM
Red Brick Warehouseは、高速なロード・パフォーマンス、高性能の照会処理、きわめて大規模なデータベースの効率的管理など、クリティカルで要求の厳しいデータ分析に特化した要件に対応します。実用性、費用効果、スケーラビリティに優れたIBM
Red Brick Warehouseは、幅広いユーザーに対して、より多くのデータの分析を可能とし、さまざまな情報に基づいた迅速な意思決定を可能にします。
ビジネス・インテリジェンス・フォーカス
Red Brickエンジンは、意思決定支援アプリケーション向けのデータベース・サーバーとしての基盤をもとに設計されたものであり、このような目的で開発されたデータベース・システムは、他に存在しません。この製品は、当初、Ralph
Kimball氏の擁するRed Brick Systemsによって開発され、後にInformixおよびIBMに買収されましたが、現在に至るまで、データウェアハウジングおよびビジネス・インテリジェンス市場において常に中心的役割を担っています。最新版であるIBM
Red Brick Warehouse 6.20でも、この製品の目的は、次のように変わらず受け継がれています。
- 業務上、照会に対する迅速な応答が求められる環境において、強力な照会パフォーマンスを提供する。
- 特定の時間枠でのロードが要求される大量のデータに対して、強力なロード・パフォーマンスを提供する。
- きわめて大規模な意思決定支援データベースに対して、ユーザビリティとスケーラビリティを提供する。
IBM Red Brick Warehouseは、データベースのサイズ、業務上の照会の種類、対象となる業務の種類を問わず、これらの機能を提供します。Red
Brickのユーザーは、電気通信から、金融サービス、ヘルスケア、e-commerceに至る幅広い業界に及び、また、数ギガバイトから数テラバイトに及ぶさまざまなサイズのRed
Brickデータベースが実際に運用されています。業務上の照会には、日常的なブラウズ照会から、複雑な結合や計算を必要とする詳細な分析レポートまで、さまざまな種類があります。単一のデータベースでサポートすることのできる同時ユーザーの数は、ハードウェア構成とライセンス契約以外には制約を受けず、処理される複雑な照会の数は、1日当たり数千件以上に及びます。また実際には、生データのサイズにかかわらず、同一のアーキテクチャを利用する同一のシステムによって、さまざまなソリューションをサポートすることができます。
IBM Red Brick Warehouseは、32ビットおよび64ビットの各種UNIXプラットフォーム上で稼働するほか、Linux、Windows
NT、およびWindows 2000上でも稼働します。また、Red Brickクライアント・ソフトウェアは、Windows
XP上でも稼働します。Red Brick製品には、サーバーのすべてのインストール・システムに対応した組み込みのODBC
3.5のサポートと、Windowsプラットフォーム用のClient Connector Packが含まれています。このClient
Connector Packには、Windows 版のODBCドライバーが含まれているほか、JavaSoft
API Version 2.0に基づいた純粋なJava Type 4ドライバーであるRed Brick JDBCドライバーも含まれています。
サーバー・ソフトウェアには、GUIベースのIBM Red Brick Warehouse Administratorツールが付属しているため、DBAによって、Windowsが実行されているPCからサーバー・マシン上のデータベースを管理することができます。Red
Brickサーバーは、標準に準拠したオープンなプロトコル（ODBC、JDBC、ANSI標準SQL）を採用しており、Red
Brickデータベースでは、さまざまなデータウェアハウジング・ツールを効果的に利用することができます。利用できるツールには、Cognos、Brio
Technology、MicroStrategy、Business Objectsなどが提供している分析ツールやレポート生成ツール、SPSSやSASが提供するデータ・マイニング・ツール、BMC
Patrolなどのシステム管理ツール、DataStageなどのETL（抽出、変換、ロード）ツールがあります。これらのツールの中には、Red
Brick特有の機能に対応した組み込みサポートを備えているものもあります。
Red Brick製品は、品質と信頼性の高さで定評があります。定期的なメンテナンス・リリースによって、ユーザーは、最新のリリースを確実に入手することができます。優れたテクニカル・サポート・サービス、コンサルティング・サービス、トレーニング・サービスを世界各地で利用でき、また、昨年導入された新たな認定プログラム（共通テスト）によって、Red
Brickデータベースの管理者は自らの技能を実証することもできます。
強力な照会パフォーマンス
照会の応答時間は、データウェアハウスの成功を左右する鍵であり、Red Brickデータベースの最も重要な特徴の1つです。業務分析担当者の使命は、情報に基づいた意思決定であり、その意思決定を左右するのは、さまざまな照会に対する迅速で正確な応答です。データウェアハウスの履歴データを分析担当者がドリルダウンし、比較する間に、このような多くの照会に対する回答が得られることが必要です。
分析担当者が求めるのは、データベースが長時間にわたって安定したオンライン状態を維持すること、照会が他の処理によって妨げられないこと、複数の分析担当者による照会が、互いに競合しないこと、同じデータベースに対する照会の平均応答時間が短いことです。つまり、多数のユーザー、照会の複雑さのさまざまなレベル、システムに対する作業負荷の変動、といった要求への対応が、データベースには求められます。
どのようにして、Red Brickの照会テクノロジーは、これらの要求に対応し、さらにそれ以上の機能を提供しているのでしょうか？
-
画期的な独自の照会テクノロジー
IBM Red Brick Warehouseは、データウェアハウジングのディメンショナル・モデリング手法をサポートしています。単純なスター・スキーマ、マルチファクト・スター・スキーマ、スノーフレーク・モデルなどの効率的なデータウェアハウス設計を利用することにより、DBAは、基本的な索引と集約表を指定するだけで、優れた照会パフォーマンスを得ることができます。照会プランは、照会の書き換え、述部を解決する特殊なロジック、その他のインテリジェント・ショートカット、変換などの最適化処理に大きく左右されます。これらの最適化処理はすべて自動で透過的に実行されるため、設定やチューニングは必要ありません。
Red Brickの照会エンジンは、それぞれの照会を評価し、最善の実行プランを実行時に選択します。この選択は、中間結果（事前に実行された予備プラン）から取得した情報に基づいて行われます。それぞれの照会プランは、ソート、結合、スキャン、集計などの個別の操作に分割されます。この動的なプラン選択により、実際の中間結果に基づいて、最適な操作が選択されます。
場合に応じて、特定の操作（特に、結合や表のスキャンなどデータ主体の操作）の並行処理も可能です。並列処理は必要に応じて行われますが、システムと作業負荷による制限を受けます。1つの照会によって他の照会のリソースがすべて犠牲になることはありません。時間のかかる操作にある程度の並列処理を用いることは全体としてよい結果をもたらすでしょう。これと同じことがメモリーにも言えます。つまり、事前定義の設定値を上限として、サーバー・プロセスごとに段階的にメモリーを割り当てることが可能です。
-
高度な索引機能と集計管理
意思決定支援の照会は、本来、データと結合を主体とする操作であるため、ほとんどの照会においては、各種の結合アルゴリズム（あるいは、結合する各種テーブル）を選択することが、最も重要となります。それが可能であるかどうかは、索引と集計を利用できるかどうかによって決まります。Red
Brickの照会エンジンは、「処理量が最も少ない照会プラン」あるいは「処理を最も効果的な方法で分割する照会プラン」のいずれかを選択します。大きなファクト表への照会に対応できる集約表がある場合には、集約を利用するようにSQLが書き換えられます。同様に、ハッシュ結合のために、索引を利用した結合の選択が行われ、他の結合プランが最適でない場合のみに、表のスキャンが行われます。
Red Brickの索引は、次の4つの目的で使用されます。
- 2つ以上の表を結合する
- 索引付きの列をスキャンして、制約を解決する
- COUNT(*) 照会などの単純な集計計算を最適化する
- 参照の整合性と一意性をチェックする
これらの機能は、STAR、TARGET、B-TREEという3つの索引によって行われます。ファクト表と、それに対応する任意の数のディメンションとの結合処理は、そのファクト表の外部キーに対するSTARindexTMによって高速化されます。コンパクトで完全にソートされたSTAR索引項目によって、ファクト表に対応する、索引付きディメンションの情報の事前計算があらゆる角度から行われます。これにより、STARjoinTMでは、それぞれのディメンションについて1対1の結合を繰り返し実行する場合よりも、ファクト表内の必要な行をはるかに迅速に見つけ出すことができます。
＜クリックして拡大＞
スター・スキーマによるディメンショナル・モデル
照会によって、後続のディメンションやSTAR索引でカバーされるディメンションの小さなサブセットが制約される場合は、TARGETindexTM（Red Brickデータベース内で2つの異なる用途がある）をファクト表の外部キーに対して使用し、STARjoinTMの代替となる高速処理であるTARGETjoinTMを実行することもできます。TARGETjoinTMとSTARjoinTMの処理は、互いに補完的な関係にあります。これらのテクノロジーを組み合わせて利用することにより、複数の表に関するさまざまな結合照会において優れたパフォーマンスを実現することができます。
TARGETindexTMの第2の用途は、列に対する制約の候補値の数が少ない（ドメインが小さい）場合に高速な索引スキャンを実現します。TARGETindexTMによるスキャンは、同じ照会の中に2つ以上の緩い制約がある場合には特に効果的です。ドメインが小さいTARGETindexTM項目（「地区」「性別」「州」などの列の値など）は、ビットマップとして格納するのに適していますが、ドメインが大きい索引では、圧縮形式および非圧縮形式のリスト表現を使用します。サーバーでは、TARGETindexTMで制約されたそれぞれの項目が最も効率的な形式で保存され、さまざまな列値ごとに、使用頻度に応じて動的に表現が選択されます。このハイブリッド型の格納方法は、非対称のデータや予測できないデータに対して効果を発揮します。
Red BrickのB-TREE Indexは、それぞれの表の主キーに対して作成され、一意性と外部キーの参照整合性を確保します。通常、制約の対象になる頻度の高い（そして、ドメインの大きい）他の列にも、管理者が追加のB-TREE
Indexを作成します。TARGETindexTMと同様に、B-TREE Indexも、制約を評価する際に照会のパフォーマンスを向上させますが、STARjoinTMやTARGETjoinTMが実行できない場合や最適でない場合（ディメンション表から外部表に対する結合を行う場合など）には、索引を利用した別の結合方法を提供する働きもあります。この場合、いずれか一方の表がスキャンされ、もう一方の表がB-TREE Indexを通じて結合されます。
Red Brickの集約表も、索引と同様に動作します。ファクト表から生成された集約表は、そのファクト表に対して、もう1つのSTAR索引のように機能します。これは、照会の中間結果を事前に計算するもう1つの手段です。Red
Brick製品において最も特徴的で画期的なコンポーネントがVistaTMテクノロジーであると言えます。これには、スキーマ内で最小であり、結合の負荷が最も少ない集約表を使用するように、集計の照会を自動的に書き換える働きがあります。この集計ナビゲーションは、Red
Brickに統合されており、透過的に動作します。照会やアプリケーションを再設計しなくても、エンド・ユーザー、照会ツール、アプリケーション・プログラマーに対して、集計パフォーマンスの向上が可能となります。インストールや構成に関するオーバーヘッドは、一切存在しません。
Vistaでは、インテリジェント型のディメンション階層という概念が実装されています。このため、一定レベルの単一の集計を使用して、より粒度の粗いレベルに照会を書き換えることができます。さらに、Vista
Advisorでは、集計照会の履歴を記録し分析して、既存の集約の利用状況に関するレポートと、新たな集約の作成を推奨するレポートの2種類のレポートを生成します。推奨された集約は、レポート内に記述されたSQLをもとに簡単に作成できます。DBAは、それぞれの集約をどの程度有効に利用できるか、どの程度の保守が必要になるかを正確に理解した上で、作成する集約を選択することができます。
＜クリックして拡大＞
Vista Advisorによる分析
Vistaのリライト・システムが透過的に機能するだけでなく、集約表の保守も明細表へのロード操作の一部として自動的に行われます。明細表が何らかの方法で更新されると、Table
Management Utility （TMU）のロード操作やDML操作によって、その変更内容が関連する集約に自動的に反映されます。この保守操作は、既存の集約行を完全に再構築する際に生じるオーバーヘッドを避けるために、段階的に実行されます。ユーザーが指定すれば、集約の保守を表ごとに延期することもできます。保守作業は、多くの場合、TMUプロセスから始まりますが、常にサーバー・プロセスによって処理されるため、（照会プランと同様に）実行時に保守プランを生成し、選択することができます。
優れた照会パフォーマンスを保証するIBM Red Brick Warehouseの数多くの特性を集約するために、3種類の索引と、それらの索引に関連する結合アルゴリズムおよびスキャン・アルゴリズムには、さまざまなスキーマや照会プロファイルに対応する数々の手段が用意されています。Vista
テクノロジーは、実行時の作業負荷を低減する別の手段を提供することで、索引処理の柔軟性を高めます。管理者は、これらの豊富な機能を十分に活用できますが、索引や集約の作成を控えて、保守やストレージに伴うコストを低く抑えることもできます。エンド・ユーザーは、DBAの選択に関与することも、DBAの選択によって作業を妨げられることもありません。エンド・ユーザーが目にするのは、優れたパフォーマンスのみです。
-
専門的な分析関数と記述能力
IBM Red Brick Warehouseは、照会の実行をさまざまな方法で最適化するだけでなく、専門的なSQL関数も備えています。アプリケーション開発者やエンド・ユーザーは、これらの関数を利用して、柔軟性のある照会を設計することができます。パフォーマンスの向上につながる機能も、使いやすさを考慮した機能も用意されています。Red
Brick独自のRISQL拡張関数と、サポートされているANSI SQL/OLAP関数のどちらを使用しても、上位10件の値を取得し、合計や平均、その他のシーケンシャル分析を実施できます。これらの関数は、サードパーティのいくつかの照会ツールによるドロップダウン・リストとして実装されているため、アプリケーション開発担当者の助けを借りなくても、エンド・ユーザーが専門的なSQLをサーバーに送ることができます。
ANSI標準の複雑な照会式や結合がサポートされているため、同一の照会をさまざまな方法で記述することによって、照会の実行やパフォーマンスを制御することができます。また、ユーザーは、任意の表または副照会に対して、結果全体ではなく行のサンプルを要求できます。これは、他の用途（データ・マイニングなど）に利用するテスト・データを作成する場合や、ランダムな行の集合による代表値に基づいて概算結果を得る場合に便利な機能です。（ランダム・サンプリング機能）
Administratorツール内のEXPLAIN関数では、照会のすべての内部操作についてグラフィカルなウィンドウが提供されます。Query
Performance Monitorで収集された照会の統計メッセージやオペレーター・レベルの統計と組み合わせて使用すると、照会を調整しながら、スキーマと照会の設計をともに改善する方法を見つけ出すことができます。
強固なデータウェアハウス設計を基盤としているため、Red Brickの照会パフォーマンスは、洗練されたデータ・アクセス方式をどのように実装し、選択するかによって大きく左右されます。システムのハードウェアや資源を常に監視する必要はなく、また、タスクの監視やチューニングも最小限で済みます。同時ユーザーの数が増加すると、データベースは、資源を共有することによって応答を返します。また、データ全体には直接アクセスせず、定型的な照会が数多く実行されるため、照会の平均応答時間に大きな影響を与えずに、データベースの表を拡大することができます。
 |
強力なロード・パフォーマンス
データ・ローディングの優れたパフォーマンスは、照会の応答時間に次いで、データウェアハウスの成功にとって欠かせない要素です。データウェアハウスには、往々にして、メインフレーム、OLTPデータベース、購入したデータ、Webなどの多様なソースからデータが入力されます。そして、実際に稼働すると、それぞれのデータベースのサイズがかなり拡大し、投資効果が現れ始めます。
ユーザーは、迅速かつ正確な応答だけでなく、（通常は、前日の夜間にロードされたデータからの）最新の応答を期待しています。ロードの時間枠、つまり、データベースが保守のためにオフラインになる厳密な時間帯は、ユーザーをオンライン状態に保ち、データベースを最新の状態に維持する上でDBAが直面しなければならない最大の制約事項です。一部の業界では、さまざまな時間帯のユーザーや、更新頻度の高いスケジュールだけでなく、年中無休のアクセスにさえ対応するために、ロードの時間枠を短縮している場合もあります。どのようなビジネス環境でも、分析担当者による照会の実行は、他のいかなるデータベース操作よりも優先させる必要があります。
どのようにして、Red Brickの表管理テクノロジーは、これらの要求に対応し、さらにそれ以上の機能を提供しているのでしょうか?
-
TMUによる高性能なデータ・ローディング
Red Brickの大容量データ・ローダーであるTable Management Utility（TMU）は、独立したプログラムとして動作しますが、データ行の挿入や更新、参照整合性のチェック、索引の構築、集約の保守など、データベースを即座に照会可能な状態に保つ上で必要なあらゆるタスクを実行します。TMUは、これらのタスクを非常に高速に実行することで、ハードウェアやシステム管理に要するコストを削減すると共に、データを予定通りに分析できることを保証します。数百万件のデータ行を約数分間で表にロード可能であり、1時間に10ギガバイトのロード速度を持続することも珍しくありません。TMUは、IBM Red Brick Warehouseのサーバー・マシンまたはリモート・クライアント・マシンから実行できるため、DBAは、入力ファイルや出力ファイルをローカルで保守することができます。
TMUは、入力ファイルを一度だけ読み込み、1回のパスで表にデータをロードし、その索引と集約をすべて構築します。データウェアハウスは、ロード操作が完了すると同時に分析可能な状態になります。TMUによるロードは、データの読み込み、Red
Brick内部形式への行の変換、表と表の索引に対する行の書き込みといった複数のフェーズに分割されます。並列型のTMUは、各段階ごとに別のプロセスを使用し、ある段階から別の段階へ行の集合を引き渡し、複数の集合が同時に処理されるようにすることで、ロードのパフォーマンスを向上させています。使用可能なCPUの数によっては、DBAが追加の変換プロセスや索引構築プロセスを割り当てることもできます。
参照整合性のチェックは、ディメンション表の主キー索引を共有メモリーにマッピングできるようにし、オペレーティング・システムに対するメモリー・マッピング・コールをより広範に利用することで、さらに最適化されています。この方法により、索引の探索が高速化し、ファクト表内の行のチェックを行います。一部のロード操作では、最適化をオンにすることもできます。その場合、単一のデータ行ではなく、データ行の集合に基づいて索引が更新されます。これにより、システム上の入出力が削減され、ロード全体のパフォーマンスが向上します。
TMUのスクリプトには、ロード・モード（追加、挿入、置換、変更、更新）の選択のほか、リジェクト条件を指定する機能、破棄する行に対する制限を設定する機能、参照整合性違反を避けるために行から参照表を自動的に生成する機能（AUTOROWGEN）など、さまざまなデータ処理要件に対処するロジックが組み込まれています。自動集計機能は、入力されたデータに集計関数を適用し、たとえば、他の列内の一致するキー値に基づいて、指定された列の合計を求めるといった操作を実行します。データは、標準入力、ディスク・ファイル、またはテープから、固定長レコードまたは可変長レコードとして区切り付き形式と定位置形式のどちらでもロードすることができます。サポートされているロケールによる入力データは、ロードした上で、データベースのロケールに変換が可能です。
TMUは、更新、REORG操作、アンロードなどのその他のデータベース操作も実行します。REORGコマンドを実行すると、保守が延期されている索引または集約が再構築されるほか、無効な索引や、データとの同期がとれていない索引が再構築されます。これらの操作は、並行して実行できます。アンロード機能を使用すると、表データを短時間でファイルに保存し、そのファイル内のデータを再ロードしたり、他の場所で再利用することができます。再構築処理や再ロード処理の効率を上げるために、アンロード時にはDDLファイルやTMUファイルも出力されます。
アンロード機能に替わる方法として、サーバー・ベースの高速なEXPORTコマンドを使用することにより、任意のSELECT文に基づいて表データをファイルに保存することができます。EXPORTコマンドは、ODBC層をバイパスして、照会結果をサーバー・マシン上のディスクに直接送ります。作成されたファイルは、内部形式（Red
Brickの表に最も高速にデータ行をロードできる形式）でエクスポートし、再ロードすることができます。
-
バージョン管理による並行性と回復可能性
ロードの時間枠をごく短くする必要がある業務や、年中無休でデータベースへのアクセスが要求される業務の場合は、照会を優先するRed
Brickの並行処理機能によって、照会のパフォーマンスを損なわずに、任意の表のデータを変更しながら、同時に照会を行うことができます。ロードや更新操作のために生じた変更は、バージョン・ログと呼ばれる特殊なセグメントに一時的に保存されます。バージョン・ログは、変更の影響を受ける実際のデータベース・ファイルに合わせて定期的に書き換えられます。このようなバージョン管理を有効にする一方で、照会結果の一貫性を確保したい場合、管理者は、データベースの改訂を凍結し、後で、あるいはデータベースが次回に「オフライン」になった時点で、データベースに対するユーザーのビューを更新することができます。
TMUでは、定期的なコミット、つまり「trickle-feed」機能がサポートされており、バージョン管理されたロードを一度に指定したレコード数単位で、あるいは指定した分単位で実行することができます。この方法でデータをロードすると、単一のロード・トランザクションが長時間実行されることを避け、データベースに対する変更を一定の間隔でコミットすることで、データの回復可能性を大幅に高めることができます。並行ロードを必要としないユーザーは、単に回復可能性を高めるために、バージョン管理されたデータベースを利用することもできます。
要約すると、TMUは、大量のデータをロードすることに特化した完全に実用的なプログラムです。Red
Brickの表管理テクノロジーは、Red Brickの照会テクノロジーと同様、データベースのサイズやロードの時間枠の長さに関係なく、ロードのパフォーマンスを保証できるという点で、DBAに柔軟性を提供します。圧倒的な速さのロード処理により、データベースをテラバイトの範囲まで拡張することができます（ロードの速度は、照会の速度を示す目安となります）。きわめて高速なデータの取得が可能になれば、通常、より高速なデータのロードが可能になります。
本格的なユーザビリティとスケーラビリティ
その場その場の照会もバッチ方式のロードも効率よく行われるデータベースであるとすれば、もう1つの大きな要件は、「使いやすさ」です。ユーザーは、アプリケーション開発用のプラットフォームとして、インストール、構成、管理、操作が容易なデータベースを必要としています。管理の容易さが重要である理由には、3つあります。それは、「日常の管理作業にそれほど多くの時間を割けない場合がある」「DBAやアプリケーション開発者のトレーニングや再教育には多額の費用が必要になる」「データウェアハウスは、厳密な設計が求められる一方で、変更が容易でなければならない」という理由です。使いやすさという要件は、多くの場合、スケーラビリティにも関連します。データウェアハウスに投資する際には、データウェアハウスの初期のユーザーが期待する照会やロードのパフォーマンスを犠牲にせずに、業務に応じた用途の拡大が可能であることを確認することが必要です。
具体的には、DBAには次のことが求められます。
- 管理タスクを可能な限り迅速に実施する。できれば、データベースがオフライン中のロード時間内に実施する。
- データベースのアクティビティを効果的に監視する。
- あらゆるユーザーの要求に対応できるようデータベースを構成する。
- システム資源について社内のIS部門の助けを借りず、単独で作業を行う。
どのようにして、Red Brickデータベースは、これらの要求に対応し、さらにそれ以上の機能を提供しているのでしょうか?
第一に挙げられるのは、IBM Red Brick Warehouseは、特定の目的に的を絞ったシンプルな製品である点です。Red
Brickのクライアント/サーバー・アーキテクチャにより、管理しやすいインストール・プロセスや構成プロセスが実現しました。細かなインストール作業は、カーネルの構成（UNIXユーザーの場合）のみです。このインストール作業を正しく行えば、DBAは、単一の構成ファイルの制御により、テスト・データベースや実働データベースの設計および構築を行うことができます。
一般に、Red Brick製品では、データウェアハウスの優れたプロジェクト計画と効果的な設計方法論を前提とした場合、構成作業の負担が軽減されます。資源の配分はほとんど動的に行われ、並列処理やメモリーの使用などに関するデフォルトのチューニング・オプションやオプション・パラメーターにより、多くの場合、最初から効果的に利用できます。パフォーマンス・チューニングによっては、構成パラメーターに対して、変更を加える方法で行われ、たとえばスクリプト化されたセッション単位の変更を加えることで、個別の照会やロードのレベルでの変更も実施可能です。また、単一の複雑な照会でメモリーを多量に使用する必要がある場合でも、他のユーザーの照会に関する汎用パラメーターを調整せずに対応することができます。
急速に拡大するデータベースの管理は、DBAが直面する最も困難な管理作業の1つです。データや索引の格納に関するRed
Brickのアプローチ（データのセグメント化）は、時間順のデータ管理を容易にしています。データウェアハウスは、一定期間のデータを時間順で格納するように設計することができます。新しいデータ・セグメントがロールオンすると、古いデータ・セグメントはロールオフするため、ディスク・スペースが再利用され、古くなったデータは削除されます。またRed
Brickではデータと同じように、索引をローカルでセグメント化できるので、データと同様のメンテナンスがIndexでも実施できるので、保守作業が大幅に簡略化されます。一般に、セグメント化は、照会のパフォーマンス（特に並列処理）やロードのパフォーマンスに影響を与えるだけでなく、製品の全般的なユーザビリティにも影響を与えるデータ管理手段です。優れたセグメンテーション計画によって、パフォーマンスが最適化され、管理コストが削減されます。
DBAは、システムテーブルやDST（Dynamic Statistics Tables）に格納される詳細なメタデータへのアクセスが可能です。これらのメタデータには、標準SQLを使用して照会および結合を実行することができます。Query
Performance Monitorには、特殊な一連のDSTが組み込まれており、これらのDSTには、照会の実行統計が、初回プラン内の個別のオペレーターのレベルまで詳細に記録されます。DBAは、さまざまな動作条件の下で同一の統計についてピーク時の統計と累積統計を比較するプロファイルを設定することによって、照会のパフォーマンスを監視し、長時間実行されている照会を診断することができます。
＜クリックして拡大＞
Query Performance Monitor:オペレーター統計表に対する照会結果
Administratorツールには、詳細な照会を記述しなくてもデータベースの状態を確認できるように、グラフィカル・インターフェイスが用意されています。このツールのメイン・ウィンドウは、データベース・ツリーとして構造化されています。DBAは、このツリー内を移動することで、オブジェクト間の関係を検討することができます。このツールには、オブジェクトの作成と管理のためのウィザードも用意されています。このウィザードを利用すると、各種のDDLサーバー・コマンドや、オブジェクト（またはデータベース全体）を作成する際に使用するSQLを生成するShow
DDLコマンド、グラフィカルなEXPLAINツールが含まれている照会インターフェイスをエミュレートすることができます。Advisorログ・ファイルに対する照会の作成、また、表形式やグラフィカルな形式による分析結果の表示などは、このツールのVista
Advisor インターフェイスによって、きわめて簡単に行えるようになります。
サーバー・ソフトウェアには、Administratorツールのほかにも、ログ・ビューアー、データの整合性の問題を調べて修正するサーバー・ベースのユーティリティ、データベースのサイズ設定ツール（Administratorにも実装）、RISQL
Entry Toolなど、さまざまなツールやユーティリティがあります。RISQL Entry
Toolと、その関連製品であるRISQL Reporterは、シンプルで効果的なツールであり、SQL文の発行や、SQLスクリプトの実行および編集をコマンド行から直接行うことができます。RISQL
Reporterには、基本的なレポート作成機能が用意されており、システム表やDSTに対する照会に特に便利です。
＜クリックして拡大＞
システム表の情報
Red Brickデータベースは、類似した機能を持つ他の製品と比較して、少人数の管理者による管理が可能であるという報告が顧客から寄せられています。Red
Brick製品が、従来のRDBMSソリューションの何分の1かのコストで数千にも及ぶビジネス・ユーザーに対してテラバイト級のデータウェアハウス機能を提供している理由の1つは、こうしたユーザビリティにあります。
まとめ
情報への迅速なアクセスを可能とし、信頼性/柔軟性の高い方法は現代の業務分析に不可欠な要素です。このような高いレベルの要件を満たすためには、高度に特化されたテクノロジーをベースとした製品が必要です。IBM
Red Brick Warehouse 6.20は、照会の実行、データのローディング、管理において画期的な技術を採用し、ビジネスクリティカルな意思決定支援用アプリケーションの開発のための強固で拡張性の高いプラットフォームを提供します。どんなに複雑なアプリケーションであっても、IBM
Red Brick Warehouseは、強力なパフォーマンスと確かな投資効果を実現します。
バージョン6.20の新機能
IBM Red Brick Warehouseバージョン6.20では、数多くの新機能、拡張機能が追加されました。主な機能は次のとおりです。
-
照会のプロファイリングと監視 − 管理者、パフォーマンス分析担当者、およびキャパシティ計画担当者は、Query
Performance Monitorを使用して、実行時に照会のプロファイルを作成してその進展を監視し、また、プロファイルを保存しプロファイルの変化を検討することができます。プロファイルは、それぞれのユーザーが使用しているプロセッサー時間、物理I/O操作の回数、ディスクへの書き込み回数など、オペレーター・レベルで収集された詳細な統計によって構成されます。
-
SQL OLAP関数 − サーバーでは、RANK、DENSE_RANK、NTILE、ROW_NUMBER、RATIO_TO_REPORTのほか、OLAP集計関数など、SQL標準の「基本OLAP」パッケージで定義されている関数がすべてサポートされます。業務に関する広範な分析的照会に対応するために、ウィンドウ・パーティションとウィンドウ・フレームを定義することができます。同等のRISQL表示関数も引き続きサポートされています。
-
VistaによるリライトおよびAdvisor拡張機能 − 事前計算されたビューの照会リライト・システムでリライトされる照会が2種類追加されています。つまり、複雑な式によってグループ化を行う照会と、COUNT（DISTINCT）、SUM（DISTINCT）、MIN、またはMAX関数が含まれている照会のうち、入力列が事前計算されたビューのGROUP
BY節や選択リストで定義されているものが、リライトされます。Advisorは、これらのリライト機能を認識し、それに従って候補ビューを生成します。候補ビューの分析を最適化するために、このリリースには、一度の分析で生成される候補ビューの数を制限する構成パラメーターとSETコマンドが用意されています。
-
TARGETjoinTMの並行処理とセグメントの除外 −TARGETjoinTM索引がローカルでセグメント化されている場合、TARGETjoinTM照会では、照会の結合フェーズで並行処理が利用され、不要なセグメントは結合処理から除外されます。
-
SQL EXPORTでのXML形式 − 照会結果をXML形式のファイルにエクスポートできます。
-
バックアップおよびリストア操作 − TMUでは、ディスク、テープ、およびXBSA準拠のストレージ管理システムへの完全バックアップと増分バックアップが可能です。バックアップ操作は、データベースの読み取りおよび書き込みアクセスが可能な状態で実行することができます。すべてのバックアップについてメタデータの詳細な履歴が維持され、信頼性の高い効率的なリストア操作がサポートされます。
-
リモートTMU − DBAは、ローカル制御ファイルと入力ファイルを使用して、LOAD DATA、UNLOAD、およびGENERATE操作をクライアント・マシンから開始できます。PTMUは、リモート・サーバー上で実行され、その出力ファイルと廃棄ファイルがクライアントに返されます。
-
XMLによるロード − XMLファイルを表の各列に対応付けるTMU制御ファイル内のパスに基づいて、XML形式のファイルから表にデータをロードできます。
-
索引のローカルなセグメント化 − DBAは、時系列データベースの保守を容易にするために、セグメント化する列が索引に存在しなくても、TARGETindexTMやB-TREE Indexをデータと同様にセグメント化できます。ローカル索引を作成するには、CREATE
INDEX...SEGMENT LOCALオプションを使用し、ローカル索引をアタッチするには、ALTER
SEGMENT...RANGE LIKE SEGMENTオプションを使用します。
-
セグメントに関するDDLの拡張
- STAR索引をCREATE STAR INDEX...SEGMENT LIKE DATAおよびALTER SEGMENT ATTACH...RANGE
LIKE SEGMENTオプションによって容易にセグメント化できます。
- ALTER SEGMENT...RELEASE STORAGEオプションを使用すると、行を削除した後の領域を解放できます。
- ALTER SEGMENT...DROP LAST STORAGEオプションを使用すると、未使用のPSUをセグメントの最後から削除できます。
- ALTER SEGMENT...RANGE MOVEオプションを使用すると、セグメントを切り離さなくても、1つの表の中でセグメントの位置を変更できます。
- 索引が意図せず無効になることを避けられます。これには、ALTER SEGMENT...DETACHおよびRANGE
MOVEオプションでINVALIDATEキーワードを指定する必要があります。
-
システムカタログの拡張 − カタログのアクセス時間、メモリーの使用、データベース・ロックの使用が改善されました。新しいシステム表であるRBW_VIEW_REFERENCESには、ビューで参照されている表を識別する働きがあります。
-
32ビットから64ビットへの移行ユーティリティ − 32ビット版のIBM Red Brick Warehouseで作成したデータベースは、ベンダーのプラットフォームが同じであれば、64ビット版との完全な互換性があります。TMU
UPGRADE文を使用すると、データベースを32ビットから64ビットのアドレッシングにアプグレードすることもできます。
-
OLE DBアプリケーションとの接続性 − Red BrickのODBCドライバーは、MicrosoftのOLE DB - ODBCブリッジを利用してWindowsのOLE
DBアプリケーションをサポートします。以下のMicrosoft製品によって作成したアプリケーションを含めて、OLE
DBベースのアプリケーションは、Red Brickデータベースに接続できます。
- ActiveX Data Objects（ADO）およびActive Server Pages（ASP）
- Microsoft SQL Server Data Transformation Services（DTS）およびAnalysis
Services
-
Red Brick JDBCによるIBM HTTP Serverの認定 − 3階層のJDBC構成における中間層としてIBM HTTP Serverがサポートされます。
-
『Query Performance Guide』− この新しい資料には、Query Performance Monitor、EXPLAIN、その他のチューニング・ツールおよび推奨事項に関する解説が収録されています。
|
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| PDF形式 | redbrick01.pdf | 296KB | HTTP |
|---|
参考文献
著者について | 
| | 堤 保晴
ソフトウェアサポート&サービス IMテクニカルセールス |
記事の評価
| 
