DB2 9.7 の新しい pureXML フィーチャーでビジネス・インテリジェンスと XML データのスケーラビリティーを強化する

IBM DB2® for Linux®, UNIX®, and Windows®, Version 9.7 には、pureXML 対応のデータベース設計、管理、開発の新しいフィーチャーが用意されています (2009年4月22日発表)。企業がより効果的に XML データをビジネス・インテリジェンス環境に統合する上で DB2 バージョン 9.7 の技術がどのように役立つのか、そして企業はますます増えていく XML データにどのようにして対処できるのかを学んでください。この記事では pureXML に関する新しい機能の要点をまとめ、その使用方法を説明するとともに、サンプル・アプリケーションのシナリオを検討します。

Cynthia M. Saracco (saracco@us.ibm.com), Senior Software Engineer, IBM

photo: Cynthia SaraccoCynthia M. Saracco は、IBM Silicon Valley Laboratory に勤務するシニア・ソリューション・アーキテクトで、新しい技術とデータベース管理の分野を専門としています。ソフトウェア業界で 23 年の経験を積んでいる彼女は、これまで 3 冊の本と 60 を超える技術記事を執筆し、7 つの特許を持っています。


developerWorks
        プロフェッショナル著者レベル

Matthias Nicola, Senior Software Engineer, IBM Silicon Valley Lab

Author photo: Matthias NicolaMatthias Nicola は IBM Silicon Valley Lab の DB2 pureXML の Senior Software Engineer です。彼は XQuery や SQL/XML、ストレージ、索引付けとパフォーマンスなど、DB2 での XML のあらゆる側面に焦点を当てた業務を行っています。彼は顧客やビジネス・パートナーと密接に協力しながら XML ソリューションの設計や実装、最適化の支援を行っています。IBM に入社する前には Informix Software でデータウェアハウスのパフォーマンスに関する業務を行っていました。彼はドイツの Technical University of Aachen でコンピューター・サイエンスの博士号を取得しています。


developerWorks 貢献著者レベル

2009年 4月 23日

はじめに

多くの組織が、柔軟性と信頼性に優れた IT 環境を作り出し、その環境を利用して重要な事業運営の本質をより深く理解しようと努めています。そんななか、コアとなる情報管理システムは、変化し続けるビジネスのニーズに適応する必要にますます迫られています。IBM ではこうした課題に企業が対応するのを支援するために、DB2 9.7 では pureXML 対応のフィーチャーのなかで、重要な点をいくつか強化しています。

DB2 9.7 の新規フィーチャーでは、XML データ用の新しいデータベース設計オプションとして、管理者がハッシュ・パーティション化 (データベース・パーティション化)、範囲パーティション化 (表パーティション化)、多次元クラスタリングなどを利用できるようになっています。これらのオプションは、企業が膨大な量のデータを収容し、並列処理環境を活用し、時間依存データの追加または除去を簡易化し、そしてさまざまなタイプのクエリーのパフォーマンスを向上できるように支援します。これらの DB2 設計オプションを単独で、あるいは組み合わせて使用することで、企業は XML データをリレーショナル・データウェアハウスに取り込めるようになります。つまり、XML メッセージ、XML 文書、および XML データ・フィードのためのオペレーショナル・データ・ストア (ODS: Operational Data Store) を作成し、XML トランザクションを処理する際のワークロードのスケーラビリティーを改善できるというわけです。

新しいデータベース設計オプションは、DB2 9.7 で提供されている pureXML の機能強化のほんの一部に過ぎません。この記事では、データベース設計オプションだけでなく、その他の新しい pureXML 機能も紹介し、どんな場合にこれらの機能が最も効果を発揮するのかを説明するとともに、新機能を使い始める上でのヒントを提供します。記事の内容は以下のとおりです。

DB2 pureXML について

2006年に登場して以来、DB2 9 は、表の中でモデル化されたデータと XML 階層のデータに共通のアプリケーション・プログラミング・インターフェースおよびデータベース管理プラットフォームを企業に提供してきました。このハイブリッド・データベース管理アーキテクチャー (図 1 を参照) により、企業は従来のリレーショナル・データベース環境を拡張し、XML メッセージおよび XML 文書を直接管理することが可能になります。つまり、従来の SQL データ型に変換するために XML データをさまざまな表の個々の列にシュレッドしたり、マッピングしたりする必要はありません。代わりに XML データを階層型フォーマットのまま、リレーショナル・データと一緒に保管できるので、アプリケーションで XML データの該当する部分を簡単かつ効率的に取得できるだけでなく、XML データとリレーショナル・データの統合も簡単に行うことができます。

図 1. リレーショナル・データと XML データ両方のサポートが組み込まれた DB2 9 アーキテクチャー
リレーショナル・データと XML データ両方のサポートが組み込まれた DB2 9 アーキテクチャー

DB2 の pureXML 機能を利用するには、管理者が 1 つ以上の XML 型の列が含まれる表を作成します。効率性と強力なランタイム・パフォーマンスは、XML 索引付け、クエリー最適化、そしてストレージ管理やその他の DB2 サービスによって確実になります。

リスト 1 を見ると、DB2 ではいかに簡単に XML データを操作できるのかがわかります。リスト 1 のコードが実行する内容は以下のとおりです。

  1. リレーショナル列と XML 列からなる表を作成する
  2. XML 列の特定の部分に索引を付ける
  3. 表にデータを挿入する
  4. クエリーを実行する (それぞれ単純な SQL、SQL/XML、および XQuery で実行)
  5. XML 文書に保管された XML 要素の値を更新する
リスト 1. DB2 pureXML の操作
-- Create a table with an integer and an XML column
CREATE TABLE customer (cid INTEGER, info XML);

-- Create an XML index for customer zip code data 
CREATE INDEX idx1 ON customer(info) GENERATE KEYS USING 
XMLPATTERN '/customerinfo/addr/zip' AS SQL VARCHAR(5);

-- Populate the table with data using a simple INSERT statement 
INSERT INTO customer (cid, info) VALUES (?,?);

-- Retrieve relational data and full XML documents 
-- for customers using simple SQL  
SELECT cid, info
FROM customer 
WHERE cid > 1234;

-- Retrieve names of customers in a specific zip code 
-- who have an ID of > 1234 using SQL/XML
SELECT XMLQUERY('$INFO/customer/name')
FROM customer 
WHERE cid > 1234 and 
XMLEXISTS('$INFO/customer/addr[zip = 95123]');

-- Retrieve an XML element that lists the names of customers
-- in a given zip code using XQuery
xquery for $i in db2-fn:xmlcolumn("CUSTOMER.INFO")/customer
where $i/addr/zip = 95123
return <myresult>{$i/name}</myresult> ;

-- Update XML element value related to zip code 
UPDATE customer
SET INFO = XMLQUERY('copy $new := $INFO
            modify do replace value of $new/customer/addr/zip 
                       with 95141
            return  $new') 
WHERE ...;

DB2 pureXML の使用ケース

サービス指向アーキテクチャー (SOA)、Web 中心のアプリケーション、そして業界固有の標準をベースとした統合プロジェクトでは多くの場合、XML に依存して重要なビジネス・データの表現および交換方法を定義しています。さらに、監査およびコンプライアンス・イニシアティブでは大抵、さまざまなビジネス・トランザクションの完全なレコードをある一定の期間、アクセス可能な状態にしておくことを要件としています。XML の使用が増えているなか、ますます多くの企業がそのデータベースを、XML メッセージおよび XML 文書の多くにつきものの複雑で極めて多様な構造に対処するよう適応させる方法を模索しています。XML データの管理は、トランザクション指向の環境と分析アプリケーションの両方に影響を与えています。

運用データの統合

XML は柔軟で自己記述的な性質を持つことから、多種多様なビジネス成果物を表現するには最適です。ビジネス成果物は多くの場合、既存のリレーショナル・データベース管理システムまたはファイル・システムに保管されます。そうでなければ、Web サービスやリアルタイムのデータ・フィード、あるいはその他のソフトウェアによって、成果物が動的に生成されることもあります。これらの多様なソースからの情報を処理、分析するには、明らかに困難が伴います。そこで企業の助けとなるのが、XML ベースの共有リポジトリーを保持することです。XML 構造の多様性は、広範なビジネス・ニーズに対処します。XML をベースとした ODS であれば、アプリケーション開発のコストを削減するとともに、進化するデータ管理の要求に対処するためのアジャイル・インフラストラクチャーを実現することができます。

図 2 に示すサンプル・アーキテクチャーでは、さまざまなビジネス・アプリケーションに代わって複数のソースからのデータを統合する ODS として、DB2 の pureXML 技術を使用しています。最近のデータ・ソースやアプリケーションでは XML をネイティブ・データ交換フォーマットとして使用するようになっていますが、その場合には XML アダプターさえも必要ありません。

図 2. 統合 ODS としての DB2 pureXML
統合 ODS としての DB2 pureXML

データウェアハウスの拡張

1990年代にデータウェアハウスが導入された当初から、企業が傾向分析によってビジネス・ストラテジーを改善していく上でデータウェアハウスが果たす役割は、次第にその重要性を増してきました。データウェアハウスにとって、最適な技術がリレーショナル・データベースであることに変わりはありませんが、XML データの管理機能を加えることで大幅な柔軟性がもたらされることは確かです。それによって、企業がデータベース・スキーマを大々的に変更したり、既存のアプリケーション・コードを作成し直すことなく、ビジネスのレポート作成要件や分析要件の進化に対応することが可能になります。

例えば、データウェアハウスで売上情報を追跡するとします。データベース設計には標準的な STAR スキーマを使用し、ファクト表に製品、地域、期間ごとの売上データを含めます。このファクト表のデータは通常、さまざまな製品や地域などについての具体的な詳細を入手するために複数のディメンション表にあるデータと結合します。残念ながら、このようなウェアハウスに対応する詳細なデータベース設計を開発するのは簡単なことではありません。

多種多様な製品を表現する必要がある場合に、適切な製品ディメンション表を設計する上で問題になる点について考えてみてください。製品のタイプが異なれば、製品の属性も異なってくるため、ビジネス・アナリストや経営幹部に対してどの製品のどの属性を公開するかを事前に決めるのが難しくなります。アナリストはおそらく、女性用セーターの売上をサイズ別、色別、素材別、ネックライン別、袖丈別、等々で調べるなど、思いもしない方法で製品の売上に関するデータをドリルダウンしたり、細分化したりするはずです。リレーショナルのみの設計では、製品ごとに考えられる対象属性のそれぞれを固有の列に取り込まなければならないため、大きくて手に負えないディメンション表になってしまいます。しかも属性は製品のタイプによって大きく異なることから、このような表は、列にデータがまばらにしか入力されていない多数の行で構成されることになりますが、それではかなり非効率的です。さらに、新製品と新しい製品属性が次々と導入されるにつれ、データベース・スキーマを (そして、そのデータベース・スキーマに依存しているアプリケーションも) 変更しなければならなくなります。このような変更にはかなりのコストがかかるだけでなく、企業ウェアハウスの表に列を追加するとなると、多くの IT 組織での長期間にわたる検討と承認プロセスが必要になってきます。

それよりも影響の少ない方法で変化するビジネス・ニーズに対処するには、データウェアハウス・スキーマで 1 つ以上の XML 列を使用するという手段を採ります。よく使用する属性は引き続きリレーショナル列に取り込む一方、追加の詳細は XML 列で保持することができます。XML 列は可変の構造にすぐに対応するだけでなく、クエリーやレポート作成にも容易に使用することができます。前の例で言うと、XML 列を使用することになる表は、製品データが含まれるディメンション表です。こうすれば、追跡する必要がある新製品の属性は、対象の製品に関連付けられた XML 文書に新規要素として含めるだけで済みます。データベース・スキーマを変更する必要はありません。

図 3 は、XML でデータウェアハウスを拡張する 1 つの例です。

図 3. XML データ管理機能によって拡張したリレーショナル・データウェアハウス (XML 列はファクト表とすべてのディメンション表に含めることができますが、この例では 1 つのディメンション表にだけ 1 列の XML 列を含めています。)
XML データ管理機能によって拡張したリレーショナル・データウェアハウス (XML 列はファクト表とすべてのディメンション表に含めることができますが、この例では 1 つのディメンション表にだけ 1 列の XML 列を含めています。)

図 3 では、ODS がデータウェアハウスに新しい情報を定期的にフィードします。この情報の一部は XML で、その他はリレーショナルとなるはずです。XML 列は必要に応じてディメンション表にも、ファクト表にも追加できますが、図 3 で XML データが示されているのは 1 つのディメンション表 (各種製品に関する詳細を追跡するための表) のみです。

XML 中心のアプリケーションのサポート

DB2 pureXML 技術は、多くの意思決定支援用および分析用データベースを増補するだけでなく、企業が (多くのサービス指向アーキテクチャーから生成される) トランザクション処理アプリケーション用の大量の XML メッセージや XML 文書を管理するのにも適しています。

XML データが増大している原因はさまざまにありますが、電子フォームと Web サービスの使用が増えていることだけでも十分な要因です。

増大する XML データに企業が対処する上で DB2 が役立つ理由は、DB2 を使用することで XML をさまざまな表の列にシュレッドする必要がなくなるためです。XML をそのままの階層型フォーマットで保管し、業界標準の XPath、XQuery、および SQL/XML 式で XML に即時アクセスできるようにすると、管理コストは削減され、アプリケーション開発も容易になります。


ハッシュ (データベース) パーティション化による最大限のスケーラビリティー

データ量が増大するのに合わせて、データベースのコンテンツを複数のプロセッサーやストレージ・デバイスに分散することで、企業はリニアに伸びるスケーラビリティーを実現することができます。DB2 9.7 では DB2 データベース・パーティション化機能 (DPF) が拡張され、XML データとリレーショナル・データの両方がサポートされるようになりました。以前の DPF でサポートされていたのは、リレーショナル・データのみです。

図 4. クエリーやその他のデータベース操作の並列処理を可能にする、ハッシュ・ベースのパーティション化を使用したサンプル DB2 アーキテクチャー
クエリーやその他のデータベース操作の並列処理を可能にする、ハッシュ・ベースのパーティション化を使用したサンプル DB2 アーキテクチャー

図 4 に示されているように、DPF は物理的なデータベース設計オプションで、マルチプロセッシング環境のなかで複数の個別データベース・パーティションを使用します。複数のデータベース・パーティションは、1 台の対称型マルチプロセッシング (SMP) マシンの内部に作成することも、何も共有しない環境 (Shared Nothing 環境) 内の個々のマシンに分散させることもできます。

DPF が役立つのは、データウェアハウス環境に一般的な、読み取り操作が集中するワークロードです。DPF では、表の作成時に定義された分散キーのハッシュ値に基づいて、特定の表の各行が特定のデータベース・パーティションに配置されます。データベースに対してデータの読み取り/書き込みが行われる際には、DB2 が自動的にその操作を該当するパーティションに配分します。そのため、1 つのユーザー・リクエストを満たすために、複数のパーティションに関連付けられた複数の計算リソースが同時に動作できるというわけです。リニア・スケーラビリティーは、データ量の増加に伴い、新しいパーティションを追加することで実現されます。管理者は、組み込み管理ツールである DB2 Design Advisor からパーティション化設計に関するアドバイスを入手することもできます。

XML データの管理を簡易化し、最大限のスケーラビリティーを実現するために、DB2 9.7 では XML データを複数のデータベース・パーティションに分散できるようになっています。データを分散することにより、XML データに関するロード、挿入、クエリー、更新、削除、妥当性検査、パブリッシュなどの多数の操作を自動的に並列処理することができます。特に、複雑で長時間実行される可能性のある分析クエリーを分割して並列処理すれば、応答時間が著しく改善されるはずです。

以前の DB2 リリースと同じく重要な点は、パーティションに均等に行を分散する分散キーを選択することです。分散キーはリレーショナル列で構成する必要があり、XML 列を参照することはできません。理想的には、パーティションのサイズが不均一にならないように、このキーには多数の異なる値が含まれていなければなりません。

DB2 9.7 で XML データに DPF を利用する方法は、リレーショナル・データに DPF を利用する方法と非常によく似ています。具体的には、管理者がパーティション・グループ、表スペース、バッファー・プールなどの適切なデータベース・オブジェクトを定義します。表は、CREATE TABLE 文の DISTRIBUTE BY HASH 節を使って作成する必要があります。

リスト 2 で作成する SALES 表には、ORDERID、PERSONID、SALESDATE に対応するリレーショナル列、そして注文に関する DETAILS を取り込むための XML 列があります。ORDERID 列の値が、この表の列をどのようにパーティション化するかを指示していることに注意してください。

リスト 2. XML 列が含まれるハッシュ・パーティション表の作成
CREATE TABLE sales (
      orderid     INT NOT NULL,
      personid    INT, 
      salesdate   DATE,
      details     XML)  
DISTRIBUTE BY HASH (orderid)

ハッシュ・パーティション表では現在、NSE (Net Search Extender (NSE) を使用して全文検索を行えるようになっています。

範囲パーティション化によるデータの長期的なロールインおよびロールアウト

データウェアハウスやビジネス・インテリジェンス環境の要件により、特定の期間にわたって選択データの履歴を保持しなければならないことがよくあります。例えば、ビジネス・アナリストが購入パターンを評価して、そこから浮かび上がる傾向を判断できるようにするために、企業が 5 年間にわたる売上の履歴を保持しなければならないとします。このようなシナリオでは、毎月、あるいは四半期ごとに古いデータをパージするか、アーカイブに保存するとともに (ロールアウト)、同様の期間ごとに新しいデータをロードする必要があります (ロールイン)。

この管理要件に対処するのが、範囲パーティション化です。DB2 9.7 ではこの技術に対するこれまでのサポートを拡張し、XML データもサポートするようになりました。範囲パーティション化 (表パーティション化とも呼ばれます) は、1 つ以上の列に含まれる値の範囲に基づいて表を区分化します。通常、パーティション化キーは時間に基づくため、この設計では特定の週、月、あるいは四半期のデータが特定のパーティションに保管されます。パーティションのそれぞれが個々のデータベース・オブジェクトとして扱われることから、管理者は容易に新しいデータをロールイン (アタッチ) したり、古いデータをロールアウト (デタッチ) したりすることができます。さらに、DB2 が自動的に、ユーザー・リクエストとは関係のないパーティションに含まれるデータへのアクセスを回避するため、クエリーの多くに優れたランタイム・パフォーマンスがもたらされます。

図 5 に、SALES 表のデータを四半期ごとにパーティション化するサンプル DB2 環境を示します。

図 5. ユーザーのリクエストを満たすために必要なパーティションだけを対象にする、DB2 の範囲パーティション環境
ユーザーのリクエストを満たすために必要なパーティションだけを対象にする、DB2 の範囲パーティション環境

1 つ以上の XML 列が含まれる範囲パーティション表を管理する方法は、リレーショナル列だけが含まれる範囲パーティション表の管理とそれほど変わりません。具体的に言うと、範囲パーティション化のための表の作成や変更、およびパーティションのアタッチやデタッチに以前サポートされていた SQL 文が引き続き適用されます。それに加え、パーティション化キーもこれまでと同様、リレーショナル・データに基づきます。

リスト 3 では、リレーショナル・データと XML データが含まれる範囲パーティション表を作成し、古いデータが含まれるパーティションをロールアウト (デタッチ) するとともに、最新のデータが含まれるパーティションをロールイン (アタッチ) しています。

リスト 3. DB2 pureXML での範囲パーティション化の使用
-- Create a range-partitioned table
CREATE TABLE salespart (
    orderid     INT, 
    orderdate   DATE, 
    ordermonth  INT NOT NULL GENERATED ALWAYS AS (month(orderdate)),
    orderyear   INT NOT NULL GENERATED ALWAYS AS (year(orderdate)),
    customerid  INT, 
    salesrepid  INT, 
    details     XML) 
PARTITION BY RANGE (orderyear, ordermonth)
  (PART q109  STARTING(2009, 1) ENDING (2009, 3) INCLUSIVE,
   PART q209  ENDING (2009, 6) INCLUSIVE,
   PART q309  ENDING (2009, 9) INCLUSIVE, 
   PART q409  ENDING (2009, 12) INCLUSIVE);

-- Insert or load data for 1Q – 4Q 2009 sales into the table  
. . . 

-- Create another table to contain new sales data to be attached
CREATE TABLE currentsales (
    orderid     INT, 
    orderdate   DATE, 
    ordermonth  INT NOT NULL GENERATED ALWAYS AS (month(orderdate)),
    orderyear   INT NOT NULL GENERATED ALWAYS AS (year(orderdate)),
    customerid  INT, 
    salesrepid  INT, 
    details     XML) ;

-- Insert or load new sales data for 1Q 2010 into the "currentsales" table 
. . . 

-- Attach a new partition for the 1Q 2010 sales data.
-- Perform an integrity check for index maintenance, range checking, etc.
ALTER TABLE salespart ATTACH PARTITION q110 
  STARTING (2010, 1) ENDING (2010, 3) INCLUSIVE 
  FROM TABLE currentsales ;

SET INTEGRITY FOR salespart IMMEDIATE CHECKED;

-- Detach the partition containing old sales data from 1Q 2009
ALTER TABLE salespart DETACH PARTITION q109 INTO OLDSALES;

範囲パーティション表でも現在、NSE (Net Search Extender (NSE) を使用して全文検索を行えるようになっています。


多次元クラスタリングによるクエリー・パフォーマンスの改善

XML データが含まれる表の多次元クラスタリングも、新しいデータベース設計オプションの 1 つです。以前のリリースでこの機能がサポートされていたのは、XML 列が含まれない表だけでした。多次元クラスタリングが特に効果を発揮するのは分析アプリケーションです。分析アプリケーションでは一般に、複数の列に含まれるデータを範囲としたクエリーを実行します。

例えば分析アプリケーションで、大規模なファクト表に含まれる売上情報を、製品別、地域別、および日付別という 3 つの次元で取得しなければならないとします。管理者はこのようなクエリーをサポートするために、多次元クラスタリングを使用することができます。多次元クラスタリングを使用して、DB2 に SALES 表の行を物理的にこの 3 つの次元で編成するように指示するというわけです。この設計では同じ製品、同じ地域、そして同じ期間の売上に関連する行は、1 つ以上のデータ・ブロックに一緒に配置されることになるため、I/O が減り、多次元クエリーのランタイム・パフォーマンスが向上します。さらに、多次元クラスタリングによってデータの再編成、挿入、削除のパフォーマンスを向上させることもできます。

DB2 9.7 では、クラスタリングの次元がリレーショナル列によって定義されている場合、XML 列が含まれる表を多次元クラスタリングに参加させることができます。以前のリリースと同じく、管理者は CREATE TABLE 文の ORGANIZE BY DIMENSION (…) 節を使用して多次元クラスタリングを指定します。リスト 4 では、製品別、地域別、期間別による多次元クラスタリングで売上データ表を作成しています。

リスト 4. 多次元クラスタリングを使用したリレーショナル・データおよび XML データ用の表の作成
CREATE TABLE salesMDC (
     id        	INT, 
     product   	VARCHAR(25), 
     region    	VARCHAR(25), 
     time      	DATE, 
     details   	XML)
ORGANIZE BY (product, region, time)

ストレージの効率性とパフォーマンスを向上させるための XML データと XML 索引の圧縮

XML データと XML 索引を圧縮すると、ストレージの効率性と、I/O バウンドのクエリーのランタイム・パフォーマンスを向上させることができます。DB2 9.7 では、この 2 つの点に関して新しいオプションを用意しています。

XML データを圧縮するには、以下の 2 つの方法があります。

  • サイズの小さな XML 文書 (必要なストレージ・スペースが 32KB 未満) は、同じ行にあるリレーショナル・データと一緒にインライン化した上で、行全体を圧縮することができます。DB2 9.5 で導入されたこのインライン機能は、引き続き便利なオプションとして使用することができます。
  • リレーショナル・データとは別のデータ領域に置かれたサイズの大きな XML 文書も同じく圧縮することができます。デフォルトでは、DB2 はサイズが 2GB までの文書を操作する場合、XML データを XDA (XML Data Area) という名前の別個のロケーションに配置します。XDA に保管された XML データの圧縮は、DB2 の新規リリースに含まれています。

DB2 9.7 で XML データの圧縮機能を有効にするには、単に CREATE TABLE 文に COMPRESS YES 節を指定するだけです。すると、表のリレーショナル列と XML 列の両方が圧縮されることになります。最適な圧縮結果を得るために、DB2 では 2 つの異なる圧縮ディクショナリーを使用します。1 つはリレーショナル列用、もう 1 つは表の XDA 用です。表に何メガバイトかのデータを入力すると、この 2 つのディクショナリーが自動的に生成されます。もう 1 つの方法として、圧縮を有効にするように表を変更してから、表を再編成してデータを圧縮することもできます。

IBM が行った初期テストでは、XDA に保管された XML データを圧縮すると、大抵は 60 ~ 80 パーセントのディスク・スペースを節約できるという結果が示されています (図 6 を参照)。

図 6. XDA に保管された XML データの圧縮による、60 ~ 80 パーセントのディスク・スペースの節約
XDA に保管された XML データの圧縮による、60 ~ 80 パーセントのディスク・スペースの節約

図 6 には、顧客から提供されたデータ・セットと公開ドメインで入手できるデータ・セットの計 6 つを IBM がテストした結果が示されています。これらのデータ・セットには、2KB から 100MB までのさまざまなサイズの文書が含まれています。

XML データをどの程度圧縮できるかは、その特定の文書が持つ構造と複雑さなど、さまざまな要因に依存するため、実際の結果は上記のテスト結果とは異なる可能性があります。表がどの程度まで圧縮されたかを判断するには、管理ビュー SYSIBMADM.ADMINTABCOMPRESSINFO に対してクエリーを実行します。リスト 5 に、このビューへのクエリーで生成された、リレーショナル・データおよび XML データそれぞれの圧縮によって節約されたスペースのパーセンテージ情報を示します。

リスト 5. リレーショナル・データと XML データの圧縮結果
SELECT tabname, object_type, pages_saved_percent
FROM sysibmadm.admintabcompressinfo
WHERE tabname = 'SALES';

TABNAME  OBJECT_TYPE PAGES_SAVED_PERCENT 
-------- ----------- ------------------- 
SALES    DATA                         69 
SALES    XML                          73 

  2 record(s) selected.

圧縮による必要なディスク・スペースの節約は、ディスク I/O の減少、およびバッファー・プールのヒット率の上昇という結果につながることも珍しくありません (圧縮されたページによって、より多くのデータをキャッシュできるためです)。多くの場合、I/O の減少とメモリー使用量の改善によるパフォーマンスの向上は、データの圧縮と圧縮解除の際に必要となる追加の CPU サイクルを上回る価値があります。

DB2 9.7 の新技術は、リレーショナル索引と XML 索引の圧縮も可能にしています。しかも、圧縮された表で作成された索引は、デフォルトで自動的に自己圧縮されます。あるいは、CREATE INDEX 文の COMPRESS [YES|NO] 節を使用して、表の索引とは別に索引の圧縮を行うかどうかを指定することもできます。データ圧縮と同様、索引を圧縮すると物理的な I/O が減り、バッファー・プールのヒット率が上がることから、正味のパフォーマンスが向上する傾向があります。新しい表関数 (SYSPROC.ADMIN_GET_INDEX_COMPRESS_INFO) により、管理者が索引の圧縮によってページがどれだけ節約されたかを判断し、圧縮されていない索引を圧縮対象に変更した場合にはどれだけの節約が可能なのかを見積もることができます。


アプリケーションに柔軟性をもたらすユーザー定義関数について

これまで、DB2 ではアプリケーション開発者がクエリーやその他の SQL 文から呼び出すことのできるユーザー定義関数を作成できるようにしてきました。このようなユーザー定義関数を作成して、よく必要とされる (そして場合によっては複雑な) 操作のコードを多数の開発者たちがアクセスできるモジュールに統合すれば、コードの再利用が促され、クエリーの開発が容易になります。開発者はよく使用される操作をいちいち各種のクエリーにハンドコーディングする代わりに、その操作が必要な各クエリーから該当する関数を呼び出すだけで済むからです。

DB2 9.7 では、ユーザー定義関数の中で XML データ型を使用することができます。入力パラメーターと出力パラメーターは XML 型にすることが可能で、SQL で作成するユーザー定義関数に XML 変数と SQL/XML 文を組み込むことができます。

XML を操作するユーザー定義関数を作成する場合、その方法はリレーショナル・データ型を扱うユーザー定義関数を作成する場合とそれほど変わりません。関数は、単一の値 (スカラー関数の場合) を返すようにコーディングすることも、複数の値 (表関数の場合) を返すようにコーディングすることもできます。後者は特に、XML 文書から繰り返しの要素 (例えば、特定の顧客の複数の電話番号や E メール・アドレスなど) を抽出して返す必要がある場合に役立ちます。

2 つの短い例で、XML データを操作するユーザー定義関数の作成と、その呼び出しがいかに簡単に行えるかを説明します。リスト 6 で作成しているのは、入力文書から特定の XML 要素を抽出するスカラー関数です。このコードから、特定の顧客の名前を返すユーザー定義関数を単純な SQL クエリーで呼び出す方法がわかります (ここで使用している「#」記号は、文の終わりを示します)。

リスト 6. XML データを操作するユーザー定義のスカラー関数の作成および呼び出し
--- Create the user-defined scalar function called "getname" 
CREATE FUNCTION getname(doc XML) 
RETURNS VARCHAR(25)
BEGIN ATOMIC
  RETURN XMLCAST(XMLQUERY('$d/customerinfo/name' 
                           PASSING doc AS "d") 
             AS VARCHAR(25)); 
END #

-- Invoke the "getname" scalar function and inspect the result
SELECT getname(info) AS name
FROM customer 
WHERE cid = 1002 #

NAME
------------------------- 
Jim Noodle

 1 record(s) selected.

複数の値を返す表関数を作成するのも、それほど難しいことではありません。リスト 7 では、指定された XML 文書に含まれる顧客ごとに電話番号の情報を返す表関数を作成しています。この関数は、単純な SQL クエリーから簡単に呼び出すことができます。

リスト 7. XML データを操作するユーザー定義の表関数の作成および呼び出し
-- Create the user-defined table function called "getname" 
CREATE FUNCTION getphone(doc XML)
RETURNS TABLE(type VARCHAR(10), number VARCHAR(20))
BEGIN ATOMIC
  RETURN
    SELECT type, number
    FROM XMLTABLE('$d/customerinfo/phone' PASSING doc AS "d"
           COLUMNS
              type   VARCHAR(10)  PATH '@type',
              number VARCHAR(20)  PATH '.') ;
END #

--- Invoke the "getphone" table function and inspect the result
SELECT cid, p.type, p.number 
FROM customer, TABLE(getphone(info)) p 
WHERE cid = 1004 #

CID                TYPE       NUMBER
----------------   ---------- --------------------
            1004   work       905-555-4789
            1004   home       416-555-3376

 2 record(s) selected.

当然のことながら、DB2 ではこれからもストアード・プロシージャーでの XML データ型の使用をサポートしていきます。これは、前のリリースで初めて提供された機能です。


管理、アプリケーション開発、パフォーマンスのためのその他の機能強化

DB2 9.7 のその他の pureXML 技術は、データベースの管理、アプリケーション開発の簡易化、そしてランタイム・パフォーマンスの向上を一層強力にサポートします。このセクションでは、これらの追加フィーチャーを紹介します。

XML インライン化についての分析

システムが提供する新しい 2 つの関数によって、管理者はサイズの小さい XML 文書のインライン化に関する分析を行えるようになりました。2 つの関数のうちの 1 つ、SYSPROC.ADMIN_IS_INLINED では、管理者が表の作成時 (または変更時) に指定された最大インライン長に基づいて、DB2 が入力 XML 文書をインライン化できたかどうかを判断することができます。もう 1 つの SYSPROC.ADMIN_EST_INLINE_LENGTH 関数では、管理者は、DB2 内で行内のリレーショナル・データと同じページに特定の XML 文書が保管されるようにするために、指定しなければならない最小インライン長を見積もることができます。このようなフィーチャーは、管理者が物理データベースの設計を微調整する際に役立ちます。

リスト 8 に、この 2 つの DB2 関数を使用する方法を示します。

リスト 8. 新規 DB2 関数による XML データ・インライン化の分析
-- Create the customer table with a maximum inline 
-- length of 1000 bytes for XML data 
CREATE TABLE customer(id int, xmlcol XML INLINE LENGTH 1000);

--- Insert or LOAD some data into the table
INSERT INTO customer VALUES (…); 
. . . 

-- Query the table using two new DB2 functions 
-- for analyzing XML inlining
SELECT id, ADMIN_IS_INLINED(info) AS inlined,
           ADMIN_EST_INLINE_LENGTH(info) AS inline_length
FROM customer;

-- Inspect the result set.
-- "1" in the second column indicates that the XML was inlined.
-- "0" in the second column indicates that the XML was not inlined.
-- "-1" in the third column indicates that the XML is too big 
--      to be inlined with the current page size.

ID      INLINED  INLINE_LENGTH  
------- -------- -------------
   1000        1           770      -- Inlined. Uses approx 770 bytes
   1001        0          2345
   1002        1           796
   1003        0          1489      -- Not inlined. Inline size of at least 1489 needed 
   1004        0          1910
   1005        0            -1      -- Too large to be inlined for the given page size

リスト 8 には、XML 列をインライン化した表を作成する方法が示されており、XML 文書の占有サイズが 1000 バイト以下であれば、その XML 文書はリレーショナル行内に保管され、XML 文書の占有サイズが 1000 バイトを超える場合は、XDA に「アウトライン化」されて保管されることを示しています。

データを表に挿入した後、この 2 つの新しい関数を呼び出して、(a) 行内の XML 文書がインライン化されているかどうか、(b) 現行の行にある XML 文書をインライン化する場合に必要となる長さを判断してください。

XML 索引のオンラインでの作成および再編成

DB2 の以前のバージョンでは、XML データに対して索引を作成または再編成すると、索引の作成中には、挿入、更新あるいは削除などのトランザクションによる表内のデータの変更ができませんでした。DB2 の新たな機能強化によってこの制限が取り除かれたため、柔軟性が一層向上し、XML 索引を作成または再編成する際にアプリケーションの遅延や停止が生じないようになっています。その結果、新しいバージョンの DB2 ではアプリケーションに対するデータ可用性が向上しています。

DB2 9.7 で XML 索引を作成する際には、リレーショナル索引を作成する場合とまったく同じように、デフォルトで同時書き込み操作が許可されます。XML 索引を再編成する場合は、データベース管理者が REORG INDEXES コマンドで ALLOW WRITE ACCESS 節を使用することによって、表での同時書き込みが許可されます。

複数の XML 文書の分解

DB2 の新しいバージョンは組み込み分解 (シュレッド) 機能を拡張し、複数の XML 文書を処理できるようにしています。以前の DB2 リリースでは、1 回の分解操作で 1 つの XML 入力文書しか処理できませんでした。新しい DB2 リリースでは、システム提供の新規ストアード・プロシージャー (XDB_DECOMP_XML_FROM_QUERY) が既存の DB2 表を入力として取り、事実上、管理者が特定の列に含まれるデータを分解できるようにしています。XML データの一部、あるいはすべてをシュレッドする必要があるデータベース設計の場合、このストアード・プロシージャーの呼び出しが特に役立つのは、XML または BLOB データを大量にロードした後です。以前のリリースと同じく、DB2 の分解機能はアノテーション付き XML スキーマを利用して、XML の属性と要素をリレーショナル表の特定の列にマッピングします。

XML スキーマの妥当性検査診断結果の取得

システム提供のストアード・プロシージャー、XSR_GET_PARSING_DIAGNOSTICS は、DB2 が XML 文書を構文解析、あるいは XML スキーマに照らして妥当性検査をする際に検出されたエラーに関する詳細な診断情報をプログラマーに提供します。DB2 9.5 の fix pack 3 で導入されたこの機能は、プログラマーが問題のある領域を正確に突き止め、必要に応じて XML を修正する上で役立ちます。

XML 文書が整形式でないか、特定の XML スキーマに対する妥当性がない場合、その文書を指定して XSR_GET_PARSING_DIAGNOSTICS プロシージャーを呼び出し、さらにオプションで XML スキーマを入力として使用してください。すると、このプロシージャーが以下の内容を含む詳細なエラー情報を生成します。

  • テキスト形式の XML 文書でのエラー箇所を示す行番号と列番号
  • 文書のエラー箇所を指す XPath
  • 元のエラー・メッセージ、理由コード、および適用されるすべてのエラー・トークン

グローバル一時表の使用

宣言済みグローバル一時表に XML 列を組み込むための新しいサポートについても簡単に説明しておく価値があります。なぜなら、この新しいサポートによって、プログラマーがアプリケーションのランタイム・パフォーマンスを向上させることができるためです。宣言済みグローバル一時表を利用することで、プログラマーはアプリケーションのなかで頻繁に使用するデータを取得して一時表にキャッシュし、アプリケーションのセッション中に繰り返しそのデータを操作することができます。ロックとロギングは最小限に抑えられ、グローバル一時表の中身はセッションの終了時に削除されます。

XML データに対する SQL アクセスの改善

DB2 9.7 でのクエリー最適化は、XML データのリレーショナル・ビューに対するクエリーの処理効率を向上させる技術です。DB2 は必要に応じて自動的にこの技術を使用するため、プログラマーは何もしなくても、ランタイム・パフォーマンスの向上というメリットがもたらされます。

DB2 9.7 は、XML データのリレーショナル・ビューに対するクエリーを処理するために、XML 索引の使用を促進します。これがどのように機能するのかを理解するため、簡単な例を辿ってみます。リスト 9 ではまず、XML 列が含まれる従業員データの表を作成します。次に、従業員レコード内に XML 要素として現れると考えられる従業員のオフィス番号に関して XML 索引を作成します。そして最後に、従業員の ID、苗字、名前、オフィス番号をリレーショナル列として抽出して公開するビューを作成します。

リスト 9. 表、XML 索引、リレーショナル・ビューの作成
-- Create a table with an XML column.
CREATE TABLE emp(doc XML);

-- Create an XML index on the table. 
CREATE INDEX officeIdx ON emp(doc) GENERATE KEYS USING 
XMLPATTERN '/dept/employee/office' AS SQL VARCHAR(20);

-- Create a relational view of the XML data managed by the table.
CREATE VIEW emp_rel_view(id, first_name ,last_name ,office) AS
SELECT X.* FROM emp,
  XMLTABLE ('$d/dept/employee' passing doc as "d" 
   COLUMNS 
      empID      INTEGER     PATH '@id',
      firstname  VARCHAR(5)  PATH 'name/first',
      lastname   VARCHAR(5)  PATH 'name/last',
      office     INTEGER     PATH 'office') AS X;

ここで、リスト 10 の SQL 文を見てください。この文はビューに対してクエリーを実行し、オフィス R344 に所属するすべての従業員の ID と名前を選択します。

リスト 10. フィルタリング基準 (クエリー述部) を使用した、ビューに対するクエリー
SELECT id, first_name 
FROM emp_rel_view 
WHERE office = 'R344';

WHERE 節の述部がリレーショナル列のオフィスを指定し、ビューは指定されたこのオフィスを XML 列の /dept/employee/office パスにマッピングします。DB2 9.7 での新しい最適化技術により、DB2 は自動的に、DB2 に含まれる XML 列に定義された XML 索引、officeIdx をクエリーの処理に使用します。このように必要に応じて有効な XML 索引を使用することで、ランタイム・パフォーマンスが改善されます。

多くのビジネス・レポート作成ツールのように、XML データを直接扱うことができないアプリケーションは、このようなビューと DB2 9.7 技術 (述部のプッシュダウンと呼ばれることもあります) を利用するメリットがあります。この最適化機能を利用することで、アプリケーションは、従来のリレーショナル・インターフェースを使った SQL クエリーによって、効率的に XML データへのクエリーを実行することが可能になります。


まとめ

IBM は、DB2 9.7 では引き続き DB2 pureXML 技術の重要な点を強化しています。これらの機能強化には、分析アプリケーションおよびトランザクション指向のアプリケーションの両方に、スケーラビリティーとパフォーマンスの向上をもたらす新しいデータベース設計オプションが含まれています。XML データと XML 索引に対する新しい圧縮サポートは、必要なディスク・スペースを減らすだけでなく、I/O バウンドの操作のランタイム・パフォーマンスを改善することも可能です。ユーザー定義関数と宣言済みグローバル一時表における XML サポートは、アプリケーションを開発する際に重宝します。さらに、システムで提供されている新たな関数およびストアード・プロシージャーによって、データベース設計と保守作業が簡易化されます。

謝辞

この記事に貢献してくださった Henrik Loeser 氏と Susan Malaika 氏に感謝いたします。

参考文献

学ぶために

  • IBM Redbook®「DB2 9 pureXML: Overview and Fast Start」(Cynthia M. Saracco、Don Chamberlin、Rav Ahuja 共著) を参照してください。DB2 pureXML の基礎を紹介しています。
  • IBM のホワイト・ペーパー「Best Practices – Managing XML Data」(Matthias Nicola、Susanne Englert 共著) を読むと、効率的な pureXML データベースおよびアプリケーションを実装する上で参考になります。
  • DB2 pureXML Cookbook』(Matthias Nicola、Pav Kumar Chatterjee 共著、IBM Press) は、サポートされるすべてのプラットフォームでの DB2 pureXML 技術について解説している包括的なガイドです。
  • DB2 partitioning features: An overview for data warehouses」(Paul McInerney 著) は、DB2 のハッシュ・パーティション化、範囲パーティション化、および多次元クラスタリングの優れた入門書です。
  • デモへのリンク、無料のダウンロード、技術記事などを豊富に揃えた DB2 pureXML ウィキにアクセスしてください。
  • developerWorks Information Management ゾーンで、情報管理について詳しく学んでください。このゾーンには、技術文書やハウツー記事、教育資料、ダウンロード、製品情報その他が豊富に用意されています。
  • developerWorks の Technical events and webcasts で最新情報を入手してください。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management, XML
ArticleID=393974
ArticleTitle=DB2 9.7 の新しい pureXML フィーチャーでビジネス・インテリジェンスと XML データのスケーラビリティーを強化する
publish-date=04232009