Upload Login /
...

XML - IBM

by user

on
Category: Documents
>> Downloads: 3
19

views

Report

Comments

Description

Transcript

XML - IBM
ビジネス・ユニットの名前
XMLDB物理設計ガイド
IBM DB2 9 pureXML対応
2007年10月発行
日本アイ・ビー・エム株式会社
日本IBMシステムズ・エンジニアリング株式会社
2007/12/208/3/05
この文書のデータの利用または公開には、
最終ページに記載されている制限事項が適用されます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
対象読者・本書の目的・前提事項
ƒ 対象読者
– データベース設計/管理者
– データベースにアクセスするアプリケーションの設計/開発者
– XMLやXMLDBに関わる技術者
ƒ 本書の目的
– 読者がXMLを格納するデータベースの物理設計と実装方法を理解し、実プロジェクトの中で活用、設計
を行えるようにすること
ƒ 本書の前提
– DBMS特化の記述は、IBM DB2 9 for Linux, UNIX, and Windowsを想定しています。
– 前提スキル
• 本書を使用するにあたって以下の知識、またはそれに値する参考文献を保持していることが望ましい
です。
– XMLの基礎知識、DBMSの基礎知識
– 以下の項目は本書に含まれませんのでご了承ください。巻末の参考文献に含まれる項目もあります。
• XMLを採用した論理データ設計、スキーマ設計
• XMLの基礎知識、DB2の基礎知識
• XMLDBの運用設計/障害対策
– メンテナンス/バックアップ/監視運用、XMLスキーマ管理運用
• XMLDBにアクセスするクエリー、アプリケーション開発
• XMLDBのセキュリティ管理
2
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XML物理設計 目次
1 物理設計のためのDB2 pureXML機能概要
2 XML物理設計のステップ
XML物理設計の流れ
1
論理モデルから物理モデルへの展開
1-① 表構造の検討
1-② XML構造の検討
1-③ DB2実装への適用
1-④ XML索引の設計
2
データベース・スキーマの作成
2-① XMLスキーマの生成
3
データベース物理設計
3-① データ容量の見積もり
3-② インスタンスの構成とDBの分割
3-③ 表の分類と表スペースの構成
3-④ 表スペースの配置
3-⑤ 表スペース以外のオブジェクトの配置
3-⑥ 構成パラメータの設定
3-⑦ シェル/コマンドの作成
3
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1 物理設計のためのDB2 pureXML機能概要
4
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLデータの格納
ƒ DB2 9のXMLデータ格納
–
DB2のpureXML機能では、XMLデータを保持するための「XMLデータ型」を提供する
–
XMLデータ型はリレーショナル表の中に定義し、レコードの中の1カラムとして取り扱う
–
XMLカラムにXMLインスタンスをInsertする場合
create table dept (deptID int,…, deptdoc xml)
insert into dept values (1,……, ’<dept><emp>夏目漱石</emp></dept>’)
dept表の論理構造
ƒ リレーショナル・データは従来のフォーマットで格納される
ƒ XMLデータは分解(Parse)されDOMに似た階層型の
フォーマット(XDM)でリレーショナル・データとは別に格納される
–
deptID
…
deptdoc
1
…
<dept> …
<emp>夏目漱石</emp>
照会時にはParseしない
</dept>
…
…
…
リレーショナル XML
XMLデータ
dept表の物理構造
5
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説:
–
XMLデータの保持形態
–
XMLデータはRDBの表の列として定義されますが、表のレコード中にはXML記述子（XML descripter）のみが保
管され、XML部分はRelationalデータとは別に保管されます。
–
XMLデータの実体を保管するエリアをXDA（XML Data Area）と呼びます。
–
記述子とデータの実体が分かれた構造はLOBと類似していますが、XDAはバッファープールを使用します。
–
また、LOBは連続したデータであり、XDAは構造を持ったデータの集まりです。
create table dept (deptID int,…, doc xml)
–
deptID (char)
…
doc (XML)
D0001
…
XML記述子
…
…
…
XDA (XML Data Area)
XMLデータのXDAへの格納
–
XDAでは、XMLデータはDB2のページ構造に格納されます。
–
XMLインスタンスが1ページに収まらない場合、regionと呼ばれる
XMLのサブツリーに分割し、それぞれのregionをページに格納します。
–
regions
index
XDA (XML Data Area)
regionはページをまたがることはありませんが、
1つのページに複数のregionが格納されることはあります。
（それぞれのXMLインスタンスがページサイズに比して小さい場合など）
–
6
XMLインスタンスとregionの関係は、region indexに保持されます。
page
page
page
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XML索引
ƒ XML索引の概要
– XML索引の種類
•
•
XMLデータ型に関連して3種類のIndexが存在する。
– Regions Index
– Paths Index
– XML Index
上記の中でユーザーが明示的に作成するのは最後のXML Indexのみであり、残りの二つ
は自動的に作成され、DB2が内部的に使用する。
Regions Index （XMLインスタンスRegionへの
Paths Index （全文書に対しユニークなパスを保持）
ポインタを保持）
root
name
Company2
Regions 索引
id
company
id
31664
31664
salary
salary
60000
gender
Male
emp
emp
name
name
gender
Male
id
id
M55
dept
Marketing
page
7
page
page
60000
first
Chris
last
Murphy
dept
first
last
Nicole
Murphy
K55
Sales
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML索引の種別
–
Regions Index
–
• XML列を含む表を作成したときに、表に対して1つ自動的に作成される
• DB2が内部的に使用する索引。XMLインスタンスがどのページに格納されているかを管理する。
Paths Index
–
• XML列を含む表を作成したときに、XML列ごとに1つ自動的に作成される
• DB2が内部的に使用する索引。
• 各XML列に属するすべてのXMLインスタンスで、ユニークなパスを保存する。
XML Index
•
•
•
ユーザーがXML列に対して作成する索引
従来の索引と同様、表スペース内にページがとられる
一つのXML列に対して複数の索引を作成可能
CREATE TABLE t1 (docID int, XMLDoc1 xml, XMLDoc2 xml);
XML Regions
Index
8
XML Column
Path Index on
XMLDoc1
XML Column
Path Index on
XMLDoc2
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLスキーマ
ƒ
DB2のXMLスキーマ対応
–
DB2は、XMLスキーマによるXMLインスタンスの妥当性検査をサポートする
• XMLスキーマをXSR (XML Schema Repository)へ登録する必要がある
–
DB2では、妥当性検査はXMLインスタンス単位で行う
• 妥当性検査を行うかどうか、どのXMLスキーマを使用するかは任意
– １つのカラムに妥当性検査済みのXMLインスタンスと、検査されていないXMLインスタンスが混在しても良い
– １つのカラムに異なるXMLスキーマで妥当性検査されたXMLインスタンスが混在しても良い
• INSERT,IMPORT, UPDATEによるXMLインスタンスの投入時に実施可能
XML
文書
XML
Schema
9
登録
XSR
DB2
INSERT
システム・カタログ
XML
Schema
Validate
Validな
(妥当な)
XML
文書
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説:
–
XMLスキーマの登録
–
DB2はXMLスキーマをXSRオブジェクトとして登録します。
–
– DTDや外部スキーマもXSRへの登録は可能ですが、妥当性検査には使用できません。
XMLスキーマは、BLOBとしてシステムカタログ表に保持されます。DB2内に取り込むことで、外部ファイルへの
アクセスを避け、安定したパフォーマンスを確保するためです
–
XMLスキーマの登録には、register xmlschemaコマンドを使用します。
–
–
XMLスキーマを使用した妥当性検査
妥当性検査は「あるレコードの、あるカラムに対して」行います
–
同じカラムに、妥当性検査済みのXMLインスタンスと、検査されていないXMLインスタンスが混在できます。
–
また、同じカラムに、異なるXMLスキーマで妥当性検査されたXMLインスタンスが入ってもかまいません。
–
妥当性検査なしでINSERT
– insert into dept values (1, ?)
妥当性検査を行ってINSERT
– insert into dept values (2, xmlvalidate(? according to xmlschema id “DEPT.SCHEMA1”))
– 上記の例では、対象スキーマをIDで指定。他に、URIで指定することも可能です。
– また、insert, importなどで使用するスキーマを明示的に指定せず、XMLインスタンス内の
xsi:schemaLocation または xsi:noNamespaceSchemaLocation属性の指定により暗黙的に使
用するスキーマを決定させることもできます。
妥当性検査済みの文書をSELECT
–
10
SQL ID (2part名)を指定
–
–
–
register xmlschema dept.xsd from /home/v9inst/dept.xsd as dept.schema1 complete
select deptid, deptdoc from dept where deptdoc is validated
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
2 XML物理設計のステップ
11
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XML物理設計の流れ
1 論理モデルから物理モデルへの展開
リレーショナルDBの物理設計の作業項目
XML DBの物理設計の作業項目
①性能面から検討
・非正規化、表の分割、参照整合や制約の検討
・XML構造の整理
・XML文書の表と列への割り当て
②物理的な属性の検討
・属性(データ型)、長さの決定
・XML DBの実装へ適用
③索引の設計
・主キー（プライマリ索引）の検討
・検索や結合のパターンによって索引作成
・XML索引の検討
・テーブル定義・索引定義の生成
（DDLファイル)
・XMLスキーマの生成
(DDL、XSDファイル)
①データ容量の見積もり
・ページ・サイズの決定
・表、（索引）サイズの見積もり
・XML列を含む表の容量見積もり
・XML特有のページ・サイズ考慮
・XML列更新によるログ量の考慮
②インスタンス・DB設計
・インスタンスの分割も検討
・バックアップ単位であるDBの分割を検討
・文字コードの制約の考慮
③表スペース設計
・表の分類と表スペース構成の決定
・表スペースのタイプ、その他の属性の決定
・XML専用表スペースの配置
・物理ディスク上への表スペースの配置
・XML索引を含む表スペースの配置
④表スペース以外のオブジェクトの配置
・ログ、バックアップ用、ワークスペースの配置
・XML文書の更新を見込んだログ容量を確保
・再編成の考慮
⑤構成パラメーターの設定
・物理設計にあわせた構成パラメーターの変更
・コードページの考慮
・XML処理に特有なヒープサイズの検討
⑥構築・運用の準備
・オブジェクトを作成するコマンド、シェルを作成
・スキーマ管理（XSR登録、Xlinkの削除）
2 データベース・スキーマの生成
データベース・スキーマの生成
3 データベース物理設計
12
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説:
ƒ
上記の表は、RDBでの物理設計の流れに対して、XMLデータが含まれる場合に追加で必要となる作業項目を整理
したものです。
– 中央が「RDBの物理設計」を行う際に必要となる作業項目
– 右側が「XML DBとしての物理設計」を行う際に、追加で必要となる作業項目
を表します。
ƒ
この章では、「XML DBとしての物理設計」を行う際に、追加で考慮が必要なポイントについて記述します。
– 「RDBの物理設計」については、参考資料として下記を参照してください。
•
13
DB2 V9 デザイン・ガイド：データベース物理設計[3-1]
http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/001E5347
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 - リレーショナル列の活用
ƒ
ƒ
DB2のpureXML機能では、レコードにXML列と共にリレーショナル列を持たせることが可能
–
必須ではなく、リレーショナル列のない定義も可能
–
XMLインスタンス内のデータをリレーショナル列に持たせることも可能
リレーショナル列の候補
–
文書管理のための列（サロゲート・キー、 NSEによる全文検索用Primary Key、TIMESTAMPな
ど）
–
XMLを意識せずにSQLのみでアクセスしたい場合
–
リレーショナル列/索引の使用が適している場合
–
• COUNT、DISTINCTなどの列関数を使用する列
リレーショナル列を任意で使用可能
• 複合索引に含める列
• 索引を使用したソートを行う列
XML列の制限
リレーショ リレーショ リレーショ
•
ƒ
参照制約
ナル列
ナル列
ナル列
XML列
XML
リレーショナル列へのデータ格納方法
XML
–
XML分解アノテーション
–
生成列
–
アプリケーションでの対応
XML
XML
14
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XMLインスタンスのデータをリレーショナル列とする場合の候補としては、以下が挙げられます。
– 文書管理のための列を使用する場合
全文検索（NSE）使用時のユニークなID列や、サロゲート・キーとしてのID列、運用に用いるTIMESTAMP列
などが考えられます。
– 必要なデータをリレーショナル列に持たせることで、XMLを意識しないSQLのみによるアクセスも可能となります。
•
– 次のような場合、パフォーマンス上の問題が発生した場合、リレーショナル列/索引を使用すると改善される可能
性があります。
•
•
•
COUNT関数やDISTINCT関数などの列関数を使用する場合、リレーショナル索引を付与した列があると
XML索引のみの場合よりも結果が高速に取得できます。
XML索引では複合索引がサポートされていません。
XML索引を使用してソートすることはできません。
– XML列の制限により、リレーショナル列が必要となる場合があります。
•
ƒ
XML列を参照制約の一部として定義することはできません。
XMLインスタンスのデータをリレーショナル列に格納する場合は、整合性を確保したデータの格納方法を考慮する必
要があります。
– XML分解アノテーション機能を利用し、 DECOMPOSE XML DOCUMENTコマンドまたはxdbDecompXMLスト
アドプロシージャの実行時に、XMLインスタンスの挿入と同時にXML内のデータをリレーショナル列に挿入するこ
とが可能です。
– ID列として、生成列を使用することが可能です。
– 更新までを考慮した場合、アプリケーションでの対応が必要となります。
15
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 - 表と列の定義
ƒ
XMLインスタンスを実際に表へ格納する際の割り当てを考慮する
ƒ
CRUD、メンテナンス要件、索引対象、パフォーマンス要件を考慮し決定する
ƒ
XMLスキーマ数からみた代表的な保持パターン
–
XMLスキーマが一つの場合
XML
XML
XML
–
XML列
XMLスキーマ
XMLスキーマが複数の場合
XML列
XML
XML
XML
–
XMLスキーマ
XMLスキーマ
XMLスキーマ
XML列1
XML列2
XML列3
XMLスキーマを使用しない場合
XML列
XML
XML
XML
ƒ
16
XMLスキーマを変更する際の対応
–
XMLスキーマが一つの場合
–
XMLスキーマが複数の場合
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2では、XMLインスタンスをXML列という単位で格納します。
–
一つのXML列に異なるXMLスキーマのXMLインスタンスを格納することが可能です。
–
一つの表には複数のXML列を定義することが可能です。
–
一つのXML列に対して複数のXMLスキーマを関連付けることが可能です。
ƒ
XML列の定義を決定するには、 CRUD、メンテナンス要件、索引対象、パフォーマンス要件といった要素を考慮すること
が必要です。
ƒ
XMLインスタンスを表に対して格納する場合、選択可能なパターンが複数挙げられます。
–
ƒ
17
採用するパターンによりメリット、デメリット、考慮点が異なるため、重要視する要件に応じてそのパターンを採用
するかを決定します。
代表的ないくつかのパターンについて、解説していきます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 表と列の定義 - XMLスキーマが一つの場合
ƒ
使用するXMLスキーマが一つの場合
–
特徴
•
•
–
メリット
•
–
1つの表に1XML列（及び、関連するリレーショナル列）のみ格納
適用するXMLスキーマは1種類のみ
シンプルで分かりやすい
考慮点
•
XMLスキーマ変更時の取り扱い
XMLインスタンスに関連するリレーショナル列
（使用する場合）
ID1
(INT)
18
ID2
(INT)
ID3
(CHAR)
OrderXML
(XML)
order.xsd
<a>
<a>
<b>bla</b>
<a>
<b>bla</b>
<a>
</a> <b>bla</b>
</a> <b>bla</b>
</a>
</a>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
19
ƒ
1つの表に1つのXML列とし、1つのXML列に1つのXMLスキーマを適用するシンプルなケースです。
ƒ
XMLスキーマを変更する場合は、後述のスキーマを変更する際の対応が必要です。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 表と列の定義 - XMLスキーマが複数の場合（1XML列）
ƒ
使用するXMLスキーマが複数の場合で、「XMLスキーマ:XML列 = n:1」のように1つのXML列に対して
複数のスキーマを使用する場合
–
特徴
•
–
メリット
•
•
–
1つの列に異なる複数のXMLスキーマで定義されるXMLインスタンスを格納
類似したXMLスキーマのXMLインスタンスをグルーピング可能
異なるXMLスキーマをまたがった検索
考慮点
•
•
•
件数が多くなると、索引付けの性能や索引がないタグの検索性能が悪化
異なる複数XMLスキーマで同じ要素名が使用されている場合に、XPath条件以外に行(文書)の特定条件
が必要
新規XML索引追加時の負荷
XMLインスタンスに関連するリレーショナル列
（使用する場合）
ID1
(INT)
ID2
(INT)
ID3
(CHAR)
OrderXML
order1.xsd
<a>
<a>
<b>bla</b>
<b>bla</b>
</a>
</a>
異なるXMLスキーマの
XMLインスタンスをまた
がった検索が可能
(XML)
b要素を検索
order2.xsd
20
<a>
<a>
<b>bla</b>
<b>bla</b>
<c>blub</c>
<c>blub</c>
</a>
</a>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
1つの表に1つのXML列とし、1つのXML列に複数のXMLスキーマを適用するケースです。
–
XMLスキーマが類似していて検索したい内容が同一の場合、複数のXMLスキーマのXMLインスタンスに対して一括
で検索できます。
ƒ
後述のスキーマ・エボリューションのように、複数のXMLスキーマを適用する必要がある場合に適しています。
ƒ
同じXPathでも全く異なる意味を持つ可能性がある場合は、XMLインスタンスを特定する条件が追加で必要となる可能性が
あります。
ƒ
レコード数と共に格納するXMLインスタンスの種類が増えた場合以下のような考慮点があります。
–
XML索引を使用しない場合は、複数のXMLスキーマのXMLインスタンスを検索するため、パフォーマンスが悪化す
る可能性があります。
–
XML索引を使用する場合でも、1列に対するXML索引の数が多くなり、挿入時の負荷が大きくなる可能性があります。
–
新規にXML索引を追加する場合、全てのスキーマのXMLインスタンスを読み込む必要があります。XML索引の作成
時にはALLOW WRITE ACCESS指定が使用できないため、索引追加中の更新が停止されます。
XML索引を使用しない場合
<items>
<items>
<item>cat</item>
<item>cat</item>
</items>
</items>
<parent>
<parent>
<child>bla</child>
<child>bla</child>
<customer>
<name>ac</name>
</customer>
<a1>
<b>bla</b>
</a1>
items/itemに対するXML索引
parent/childに対するXML索引
</parent>
</parent>
21
XML索引を使用する場合
child要素を検索するため
に、child要素のないもの
も含めて全ての種類の
XMLインスタンスを検索す
る必要がある
<customer>
<name>ac</name>
</customer>
customer/name
に対するXML索引
<a1>
<b>bla</b>
a1/bに対するXML索引
XMLインスタンスの種
類ごとにXML索引が
必要なため、索引数
が増加しデータ挿入
時の負荷が増える
</a1>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 - 表と列の定義 XMLスキーマが複数の場合（複数XML列）
ƒ
使用するXMLスキーマが複数の場合で、 「XML列:表 = n:1 (XML列を複数持つ表)」のようにXML列を
複数定義する場合
–
特徴
•
•
–
メリット
•
–
関連を持つ複数のXMLインスタンスを1レコードに格納
同一XMLインスタンスを分割して保持する場合（後述）等に使用
関連した複数のXMLインスタンスが表の1レコードとなるためにわかりやすい
考慮点
•
XML列間の整合性
cont.xsd
meta.xsd
XMLインスタンスに関連するリレーショナル列
（使用する場合）
Meta.xml
Contents.xml
ID1
(INT)
ID2
(INT)
Meta
(XML)
Contents
(XML)
Meta.xml
Contents.xml
1レコード
Meta.xml
Contents.xml
Meta.xml
Contents.xml
22
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
1つの表に複数のXML列を持たせるケースです。
ƒ
複数のXMLインスタンスを1レコードとして保持できます。
ƒ
主な使用例として以下のようなものが考えられます。
–
同一XMLインスタンスを分割して保持するケース
•
ƒ
23
例：コンテンツを管理するXMLでメタデータ部分とコンテンツ部分を別カラムに保持
レコードの挿入時にXML列間の整合性を考慮する必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 表と列の定義 XMLスキーマを使用しない場合
ƒ
XMLスキーマの有無にかかわらず、DB2側で妥当性検査を行わない場合
–
特徴
•
•
–
メリット
•
•
–
1つの表に1XML列（及び、関連するリレーショナル列）のみ格納
XMLスキーマは使用しない
シンプルで分かりやすい
どんなXMLインスタンスでも一つの表に挿入できる
考慮点
•
•
行が増加した際の、検索対象増加によるパフォーマンス劣化
XML索引数の増大による索引メンテナンス負荷の増大
XMLインスタンスに関連するリレーショナル列
（使用する場合）
<a>
<b>bla</b>
ID1
(INT)
ID2
(INT)
ID3
(CHAR)
OrderXML
(XML)
</a>
<parent>
<child>bla</child>
</parent>
<a>
<c>bla</c>
</a>
<a1>
<b>bla</b>
</a1>
24
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2側でXMLスキーマを登録して妥当性検査を行わず、多様なXMLインスタンスを格納したい場合です。
–
ƒ
25
表や列の配置を考慮せずにXMLインスタンスを検索することが可能です。
レコード数と共に格納するXMLインスタンスの種類が増えた場合、1XML列に複数XMLスキーマのXMLインスタンスを格
納するケースと同様以下のような考慮点があります。
–
XML索引を使用しない場合は、複数のXMLスキーマのXMLインスタンスを検索するため、パフォーマンスが悪化
する可能性があります。
–
XML索引を使用する場合でも、 1列に対するXML索引の数が多くなり、挿入時の索引作成負荷が大きくなる可
能性があります。
–
同じXPathでも全く異なる意味を持つ可能性がある場合は、XMLインスタンスを特定する条件が追加で必要とな
る可能性があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-①表構造の検討 - 表と列の定義 XMLスキーマ変更への対応
ƒ
将来的にXMLスキーマの変更がある場合は、パターンにより対応が必要
–
一つのXML列に対して、変更後も一つのXMLスキーマのみを利用する場合
•
•
–
レコードの再Validation
DB2次期リリース使用可能となる予定のUPDATE XMLSCHEMA
一つのXML列に対して複数のXMLスキーマを許す場合
•
新規レコードは新規XMLスキーマでValidation
XML列
XMLスキーマをV1からV2へ変更
XML列
新規レコード→
：XMLスキーマV1で妥当性検査済のXMLインスタンス
：XMLスキーマV2で妥当性検査済のXMLインスタンス
26
旧XMLスキーマと新XMLス
キーマそれぞれで妥当性検
査されたXMLインスタンス
が混在することになるため、
対応が必要
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
–
XMLスキーマのバージョン・アップ（スキーマ・エボリューション）など、将来的にXMLスキーマの変更が想定される場合は、
パターンに応じた対応を行う必要があります。
–
一つのXML列に対して、一つのXMLスキーマを使用する場合、変更後のXMLスキーマで全てのレコードを再妥
当性検査する必要があります。
–
DB2次期リリースでは、スキーマ・エボリューションへの対応が強化され、一つのXMLスキーマで再妥当性検査
なしにXMLスキーマのバージョン・アップを実現できます。
•
–
27
UPDATE XMLSCHEMAコマンドを提供
– 登録済みのXMLスキーマに対して、「互換性がある」変更を行う際にXMLスキーマの更新が可能
となります。
• 「互換性がある」XMLスキーマの変更とは、以下のような変更を指します。
– オプションの要素や属性の追加
– ストリングタイプのサイズの増加(maxLength facet)
– 繰り返し可能要素の増加 (maxOccurs)
– 等
複数のXMLスキーマを許す場合は、新しいXMLスキーマを登録し、それ以降に挿入されるレコードはこのXMLス
キーマで妥当性検査します。以前のXMLスキーマで妥当性検査済みのものは、それを意識して運用します。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-② XML構造の検討(1)
ƒ 論理設計が完了したXMLインスタンスに対して、必要に応じて、DB2に格納することを前提
とした性能面からの見直しを行う
–
空要素の削除によるノード数削減
<a>
<b1>30</b1>
<b2/>
</a>
–
<a>
<b1>30</b1>
</a>
XMLインスタンスの分割による1文書当たりのノード数削減
<a>
<b1>bla</b1>
<b2>bbb</b2>
<c1>cla</c1>
<c2>ccc</c2>
</a>
<a>
<b1>bla</b1>
<b2>bbb</b2>
</a>
<a>
<c1>cla</c1>
<c2>ccc</c2>
</a>
28
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
検証後にパフォーマンスの問題がある場合、XMLインスタンスの構造を変更することで改善する可能性があります。
ƒ
DB2のpureXML機能では、XMLインスタンスあたりのノード数がパフォーマンスに影響を与えることがあります。いくつか
の手段により、ノード数の減少が可能です。
–
–
29
格納時にデータを持たない空要素を省略することにより、ノード数を減らすことができます。
• 特に、業界標準の汎用スキーマをそのまま用いた際など、不要な空要素が多い場合に有効となります。
• 空要素の検索（要素が空であるという検索）を行う場合は、空要素を残すことでXML索引が使用されます。
要素の数が多いXMLインスタンスなど、ノード数が多いためにパフォーマンスに問題がある場合は、分割により
改善する可能性があります。
ƒ
XML構造の整理には、アプリケーション側で調整する、XSLTを使用して変換するといった対応が必要となります。
ƒ
これらの対応には、スキーマ変更が伴う場合もあります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-② XML構造の検討(2)
ƒ 論理設計が完了したXMLインスタンスに対して、必要に応じて、DB2に格納することを前提
とした性能面からの見直しを行う（続き）
–
XML要素の属性への変換によるノード数削減
<a>
<b1>30</b1>
<b2>bbb</b2>
<a b1=“30”>
<b2>bbb</b2>
</a>
</a>
–
外部XMLインスタンスとのJoin数削減のための外部データ取り込み
<Sales_Detail>
<Item_Id>30</Item_Id>
<Quantity>3</Quantity>
</Sales_Detail>
<Sales_Detail>
<Item>
<Item_Id>30</Item_Id>
<Name>water</Name>
<Price>100</Price>
</Item>
<Quantity>3</Quantity>
</Sales_Detail>
30
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2のpureXML機能では、XMLインスタンスあたりのノード数がパフォーマンスに影響を与えることがあります。いくつか
の手段により、ノード数の減少が可能です。（続き）
–
要素を属性へ変更することで、XMLインスタンスのノード数を減らすことができます。
–
外部のマスター・データとのJoinが必要となるようなケースでは、XMLインスタンス内に外部のデータを取り込む
ことで、Joinの負荷を減らすことが可能です。
•
•
31
外部データとXMLインスタンス内に取り込んだデータとの整合性が必要ない場合（例：売上伝票の顧客住
所データなど、最新ではなく発生時点のデータで良いもの）は、論理データ・モデル設計の段階で考慮さ
れ、XMLインスタンスが定義されており、この段階でデータの取り込みは発生しません。
一方、単にJoinの負荷を減らすために外部データとXMLインスタンス内にデータを取り込む場合（例：売上
伝票でも外部の最新データと同期を取りたい場合）は、データの整合性を考慮する必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 数値データ型
– 整数（BIGINT/INT/SMALLINT）
• 対応するデータ型の名称
備考
DB2データ型
Javaデータ型
XMLデータ型
単精度整数
SMALLINT
short
short
2byte整数（32767 以下、および -32768 以上）
長精度整数
INTEGER
int
int
4byte整数（2147483647 以下、2147483648 以上）
64ビット整数
BIGINT
long
long
8byte整数（9223372036854775807 以下、9223372036854775808 以上の整数）
• 制約、考慮点
– 制約は特になし
– 業務要件によっては、下記のようなビルドイン派生型の使用も可能
> positiveInteger（正の整数）、nonNegativeInteger（0以上の整数）
> negativeInteger（負の整数）、nonPositiveInteger（0以下の整数）
32
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
RDBで、チェック制約等を使用してより厳密な制約を実装していた場合、必要な制約を付加した派生型をユーザー定義型
として定義する事も可能です。
–
ƒ
33
詳細は2章「E-⑥. XMLスキーマのブラッシュアップ - 派生型の宣言」を参照してください。
整数型が使用可能なファセット
–
pattern
–
enumeration
–
whiteSpace（collapaeのみ設定可能）
–
maxInclusive
–
maxExclusive
–
minInclusive
–
minExclusive
–
totalDigits
–
fractionDigits（「0」のみ設定可能）
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 実装を考慮したデータ型の検討
ƒ 数値データ型（続き）
– 浮動小数点（単精度/倍精度）
– 対応するデータ型の名称
DB2データ型
Javaデータ型
XMLデータ型
備考
単精度浮動小数点
REAL
float
float
32bit浮動小数点
倍精度浮動小数点
DOUBLE/FLOAT
double
double
64bit浮動小数点
• 制約・考慮点
– DB2/Java/XMLスキーマ共にIEEE754に準拠するが、上限値/下限値に若干の違いが存在する。
> ただし、DB2 9 for LUWの実装ではXMLデータ型の上限/下限もRDBデータ型と同じ。
– IBM形式の浮動小数点を使用している場合、IEEE754形式への移行が必要。ただし、有効桁数が低下
するため、データ精度の要件上問題ないかの考慮が必要
> IBM形式の浮動小数点では実数部のデータ長が長いため、同じ64bit浮動小数点でもIEEE形式より
も有効桁数が長い。
– XML データ型は、RDBデータ型が許容しない特殊値（正負の無限大、正負のゼロ、非数値）を許容する。
34
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
•
DB2とXMLスキーマでの浮動小数点の上限値/下限値の違いについて
– DB2 9に格納する場合、許容する値の範囲がW3C XML Schema 1.1で定義された範囲と若干異なることを考慮する。
– DB2 9内でのSQLデータタイプ/XMLデータタイプ間では許容する範囲は同じ。
– 単精度（32bit）の場合
負の下限値
負の上限値
正の下限値
正の上限値
DB2 LUW RDB
-3.402e+38
-1.175e-38
1.175e-38
3.402e+38
DB2 LUW XML
-3.402e+38
-1.175e-38
1.175e-38
3.402e+38
W3C XML Schema1.1
-3.402e+38
-1.401e-45
1.401e-45
3.402e+38
Java
-3.402e+38
-1.401e-45
1.401e-45
3.402e+38
負の下限値
負の上限値
正の下限値
正の上限値
DB2 LUW RDB
-1.797e308
2.225e-308
2.225e-308
1.797e308
DB2 LUW XML
-1.797e308
2.225e-308
2.225e-308
1.797e308
W3C XML Schema1.1
-8.988e307
-2.470e-324
2.470e-324
8.988e307
Java
-1.797e308
-4.940e-324
4.940e-324
1.797e308
– 倍精度（64bit）の場合
•
35
浮動小数点型が使用可能なファセットは、整数型と同様
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 実装を考慮したデータ型の検討
ƒ 数値データ型（続き）
– 10進数
• 対応するデータ型の名称
DB2データ型
１０進数
DECIMAL
Javaデータ型
java.math.BigDecimal
XMLデータ型
備考
Decimal
• 制約・考慮点
– DB2 for LUW、z/OSのDECIMAL型の最大桁数は31桁であり、取り得る値の範囲は -10^31+1 か
ら 10^31-1 。
– XMLスキーマのdecimalは、デフォルトでは範囲/精度についての制約が存在しない。必要に応じて
制約を付加する。
36
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
使用可能なファセットについて
– 整数型で使用可能なファセットと同様
•
37
fractionDigitsには0以外の値が設定可能
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 実装を考慮したデータ型の検討
ƒ 文字ストリング型
• 対応するデータ型の名称
DB2データ型
Javaデータ型
備考
XMLデータ型
固定長文字ストリング
CHAR
string
string
データ長を固定する場合、lengthで対応
可変長文字ストリング
VARCHAR
string
string
最大長はminLength/maxLengthで対応
固定長GRAPHICスト
リング
GRAPHIC
string
string
データ長を固定する場合、lengthで対応
可変長GRAPHICスト
リング
VARGRAPHIC
string
string
最大長はminLength/maxLengthで対応
• 制約・考慮点
– ホストからの移行を行う場合、SO/SIの取り扱いに考慮が必要
> 通常はコード変換時に除去する。
38
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
39
文字列型で使用可能なファセットは下記の通り
–
length
–
minLength
–
maxLength
–
pattern
–
enumeration
–
whiteSpace
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 実装を考慮したデータ型の検討
ƒ 日付・時刻型
• 対応するデータ型の名称
DB2データ型
Javaデータ型
XMLデータ型
日付
DATE
java.sql.Date
date
時刻
TIME
java.sql.Time
time
タイムスタンプ
TIMESTAMP
java.sql.Timestamp
dateTime
備考
フォーマットが異なるため変換が必要
• 制約・考慮点
– dateTimeデータ型では、オプションとしてマイクロ秒とタイムゾーンを保持できる。
– SQLデータ型のTIMESTAMPはタイムゾーンを保持できないため、移行時に取り扱いの方針を検
討する。
– フォーマットが異なるため、移行時に変換を行う必要がある。
40
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
dateTime型のフォーマットは下記の様に表記されます
–
yyyy-mm-ddThh:mm:ss.sssssszzzzzz
•
•
•
–
タイムゾーンの考え方
•
•
•
–
「T」は固定文字
「.ssssss」はマイクロ秒。 6桁以下で任意の精度で付加可能。
「zzzzzz」はタイムゾーン
dateTime型、Time型ではオプションとしてタイムゾーンを保持することが可能です。
タイムゾーンが記述されない場合、暗黙的にUTCとして取り扱われます。
タイムゾーンは「±HH:MM」で与えます。
– UTCを表す場合は「Z」、「-00:00」、「+00:00」として表現します。
dateTime型の表記の解釈例
内容
41
dateTimeフォーマットでの記述
UTCでの時刻
タイムゾーンなし（UTCとして解釈される）
2007-08-19T12:00:00
2007-08-19T12:00:00
UTCを表す表記法の1つ（ズールー時）
2007-08-19T12:00:00Z
2007-08-19T12:00:00
日本時間（JST）での2007/8/19 12:00
2007-08-19T12:00:00+9:00
2007-08-19T03:00:00
US東海岸時刻（EST)での2007/8/19 12:00
2007-08-19T12:00:00-5:00
2007-08-19T17:00:00
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
42
RDBのタイムスタンプ型を移行する場合
–
前述の通り、XMLスキーマにおけるdateTimeデータ型、Timeデータ型は、タイムゾーンを持たない場合、暗黙的
にUTCとして解釈されます。
–
複数のタイムゾーンを取り扱う業務では、移行時にタイムゾーンを付加してデータ投入することも検討必要があり
ます。
–
また、XQueryで定義された関数であるcurrent-dateTime、current-Time、current-DateはタイムゾーンUTCの現
在時刻を戻すため、タイムゾーンなしで時刻データを投入していた場合、意図と異なる結果が得られる可能性が
あります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説：RDBと同様の制約が必要な場合の考慮
ƒ
固有制約
– 文書単位（もしくはそれ以下のスコープ）でユニーク性を確保する場合
•
UNIQUE要素を使用し、XPathで指定したスコープで値が一意となることを指定
– XML列全体を通してユニーク性を確保する場合
•
ƒ
ユニークXML索引を作成し、XML Patternで一意となるエントリを指定
チェック制約
– 新たな派生型を定義し、制限（restriction）を付加して対応
ƒ
参照制約
– 参照制約はテーブル間のデータの関連を表現するため、複数テーブルを１XMLインスタンスに集約し、XMLの階層として
表現できないかを検討する。
– 独立したXMLインスタンス間で参照制約を保持する場合は、XMLスキーマとしては対応不可
•
•
43
アプリケーションでの対応を考慮する。
リレーショナル列として取り出し、RDBの参照制約を適用することも可能。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 使用文字の制約
ƒ DB2 V9.1でXML名（要素名、属性名、接頭辞名）に使用可能な文字
– 最初の文字は、文字または_(アンダースコア)のいずれか
– 2番目以降の文字は、文字、数字、.(ピリオド)、-(ハイフン)、_(アンダースコア)
– 半角カタカナ、全角英数字、(株)などの特殊文字は使用できない
ƒ DB2 V9.1ではXML名の長さは1000バイト以下の必要がある
44
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2 V9 pureXML機能は、XML1.0規格に準拠しており、XML名の命名規則は規格により定められています。
XML名の命名規則の詳細については、 W3C Extensible Markup Language (XML) 1.0 [2-1]の資料を参照してください。
ƒ
DB2 V9 pureXML機能は、XML名として使用可能な文字には、半角英数、全角ひらがな、全角カタカナ、UCSによりCJK
統合漢字として定義されている漢字は使用できますが、以下の文字は使用できません。
・ .(ピリオド)、-(ハイフン)、_(アンダースコア)以外の半角記号
・ 半角カタカナ
・ 全角の英数字、記号
・ ローマ数字
・ ㈱、①などの特殊文字
これらの文字はXML名には使用できませんが、テキストエレメントの値などで使用することは可能です。
ƒ
DB2 9におけるpureXML機能では、XML名は1000バイト以下であるという制限があります。
XML名として使用できる文字列の例
日本IBM
日本アイビーエム
XML名として使用できない文字列の例
日本ＩＢＭ
日本ｱｲﾋﾞｰｴﾑ
日本IBM㈱
日本アイ・ビー・エム
45
=> ＩＢＭが全角英文字
=>アイビーエムが半角カタカナ
=> ㈱が使用不可
=>中黒の使用不可
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-③DB2実装への適用
- 関数使用時の制約
ƒ 関数の入力として、xs:string型を使用する場合のデータ長
• xs:stringを保持するノードの値を関数の入力として使用する際に、長さの制約がある関数が存在する。
– 関数の入力として使用するデータ長が32000byteを超えた場合、SQL16074Nが返却されエラーと
なる。
– XMLデータとして保持する上では特に制約はない
– 現時点ではDB2のマニュアルに記載されていないが、今後記載予定。
ƒ 桁数の多い数値要素をfloat/doubleにキャストする場合
• 31桁以上の数値要素を浮動小数点（float/double）にキャストする場合、SQLSTATE=10902が返却さ
れエラーとなる。
– XQuery関数上の長さ制限に抵触したとのメッセージが返却され、その時点でXQueryの実行は中
断される。
– SQL上で文字列からfloat/doubleへのキャストを行った場合も、31桁以上の場合エラーとなる。
46
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ƒ
32000byteを超えるxs:stringを入力した場合に、エラーの発生が確認できている関数
–
fn:matches
–
fn:contains()
–
fn:ends-with() / fn:start-with()
–
fn:matches()
–
fn:substring-after() / fn:substring-before()
–
fn:tokenize()
–
fn:translate()
31桁以上の数値要素を浮動小数点にキャストした場合のメッセージ
–
XQueryの場合
SQL16074N An XQuery atomic value with the lexical representation starting
with "1234567890123456789012345678901" of type "xdt:untypedAtomic" cannot be
processed in the XQuery operation or function "xs:double()" because the length
exceeds the operation or function limit of "30" bytes. SQLSTATE=10902
–
SQLの場合
SQL0443N Routine "SYSFUN.DOUBLE" (specific name "CHARTODOUBLE") has returned
an error SQLSTATE with diagnostic text "SYSFUN:11". SQLSTATE=38552
47
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-④XML索引の設計 - XML索引の作成方法
ƒ XML索引の作成方法
–
XML索引は、CREATE INDEXステートメント中にxPetternを記述して指定する。
CREATE INDEX EMPINDEX ON COMPANY(COMPANYDOCS)
GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE
COMPANY表
COMPANYDOC (XMLデータタイプ列）
1row
1row
48
<company name="Company1">
<emp id="31201" salary="60000" gender="Female">
<name><first>Laura </first><last>Brown</last></name>
<dept id="M25">Finance</dept>
</emp>
</company>
<company name="Company2">
<emp id="31664" salary="60000" gender="Male">
<name><first>Chris</first><last>Murphy</last></name>
<dept id="M55">Marketing</dept>
</emp>
<emp id="42366" salary="50000" gender="Female">
<name><first>Nicole</first><last>Murphy</last></name>
<dept id="K55">Sales</dept>
</emp>
</company>
EMPINDEX索引
COMPANYDOC
(DOUBLE)
31201
31664
42366
DOUBLE型の索引が作成される
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
作成されたXML索引の確認
–
作成された索引はSYSCAT.INDEXESビューに登録される
–
XML INDEX1つに対して、Logical Index、Physical Indexが1エントリずつ作成される。
–
Logical Index
–
• ユーザーが作成した索引
• 論理的な索引のため、物理的には存在しない
Physical Index
•
•
•
•
Logical Indexに紐づく索引
物理的に存在する
Logical Indexが作成されると、自動的に作成される
DB2が内部的に使用する索引
select substr(indname,1,20) as indname,IID,substr(TABNAME,1,10) as TABNAME, INDEXTYPE
from syscat.INDEXES where TABNAME='COMPANY‘
INDNAME
IID
TABNAME
INDEXTYPE
-------------------- ------ ---------- ---------
49
SQL060518113414530
1 COMPANY
XRGN
←Region Index
SQL060518113414950
2 COMPANY
XPTH
←Path Index
EMPINDEX
3 COMPANY
XVIL
←XML Logical Index
SQL060518113548400
4 COMPANY
XVIP
←XML Physical Index
Table作成時に、DB2が自動
的に内部的に作成する索引
ユーザーがXML Indexを作成を
すると、それはLogical Indexとな
り、内部的にPhysical Indexが自
動的に作成される
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-④XML索引の設計 - XML索引でのデータ型の選択
– XML索引のデータ型の選択
• XML索引を作成する場合、CREATE INDEXステートメント中の
「AS SQL XXXX」キーワードで、どのSQLデータ型で索引を作成するか選択する。
CREATE INDEX EMPINDEX ON COMPANY(COMPANYDOCS)
GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE
• XML索引としてサポートされるSQLデータ型は下記の5種類
–
–
–
–
–
VARCHAR(n)
VARCHAR HASHED
DOUBLE
DATE
TIMESTAMP
– XML索引に関するデータ型全般の考慮点
•
•
•
50
XMLのデータ型がそのまま索引キーとなるのではなく、SQLデータ型にマップされる。
– 全ての数値型はDOUBLEデータタイプとして索引に保持される。
数値型の索引では前後の半角スペースは無視されて索引キーが生成される。文字型の索引では、半角ス
ペースは無視されない。
索引のデータタイプとXML内のデータタイプは一致させる
– 型が不一致の場合にはINSERT失敗、索引エントリが作成されない等が発生する。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML索引としてサポートされるデータ型の考慮点
–
VARCHAR(n)
•
•
–
nはXML索引の対象となる文書ノードの最大長をbyteで定義する。定義可能な最大長は索引を格納する
表スペースのページサイズによって決まる。（下記表を参照）
32Kページサイズの最大長（7985byte）以上のデータ長になる可能性がある場合VARCHAR型では索引
が作成できない。その場合VARCHAR HASHEDで作成する。
VARCHAR HASHED
•
•
XMLの索引対象となるストリングに対し、8byteのハッシュ・コードを生成する。索引対象となるストリング
の長さに制約はない
– ハッシュコードで索引キーを保持するため、範囲検索はできない。
– 異なるストリングが同じハッシュ・コードに変換される可能性があるため、ユニーク索引を作成す
る際、予期しない重複エラーが発生し得る。
末尾に半角スペースを含む場合、半角スペースを含めたストリングがハッシングされる。
– 検索条件として半角スペースを含まないリテラルを指定した場合、マッチしない。
「VARCHAR」型の索引を作成する際の、文書ノードの最大長
51
ページサイズ
文書ノードの最大長（byte）
4KB
817
8KB
1841
16KB
3889
32KB
7985
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML索引としてサポートされるデータ型の考慮点
–
DOUBLE
•
•
•
•
52
全ての数値型は、索引上ではSQLデータタイプのDOUBLEに変換して保持される。
大きな桁数の64bit整数値や、桁数に制約のないDecimal型では、索引キー値には精度落ちが発生する。
– 精度落ちの結果、異なる整数値が同一のdouble値にマップされる現象が発生する。
> 64bit整数値の場合、16桁程度（上限値の約1/1000）の値でも重複が発生する。
– ユニーク性を保証する必要がある場合、double型としてユニーク索引を作成すると、重複値では
なくても固有制約が発生しうる。
– そのため、ストリングとして取り扱う等の考慮が必要
バリデーションされていないXMLインスタンスでは、double値のまま比較されるため、丸め誤差により意
図する検索結果が得られない可能性がある。
– 条件指定を範囲で行う等、誤差が生じることを意識したアプリケーション・ロジックが必要。
バリデーション済みのXMLインスタンスでは、DB2はXML索引スキャンでXML本体の取得した後に再度
データの比較を行うため、スキーマ上で定義されたデータ型で比較される。
– イコールでの比較等、大きな桁数の数字を正確に取り扱う必要がある場合は、longやDecimal等
の誤差が生じないデータ型をXMLスキーマで定義し、XMLインスタンスのバリデーションを行う。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
索引のデータタイプとXML内のデータタイプが一致しない場合の挙動
–
DOUBLE型として索引作成した後に、CHAR型のデータを挿入
–
• INSERTは成功するが、索引に値は格納されない
VARCHAR(10)で索引を作成した後に、11byteの値をINSERT
–
• INSERT失敗（SQL20305Nが発生）
11byteの値を持つ属性に、VARCHAR(10)の索引を作成
•
53
CREATE INDEX 失敗（SQL20306Nが発生）
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-④XML索引の設計 - XML索引に特徴的な考慮点
•XML索引スキャンが使用される基本ルール
①索引が示す範囲が、クエリーが示す範囲より広い
②索引のデータタイプと、クエリーのデータタイプが一致している
③索引とクエリーで使用される/text()に、一貫性がある
但し、オプティマイザーにより索引が使用されない場合もある
54
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引が示す範囲が、クエリーが示す範囲より広い
CUSTOMER
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
INFO
(XML)
*
– “phone”に対して索引を作成する
– 索引候補
その１
create index idx1 on customer(info) generate key using
xmlpattern '/customerinfo/phone' as sql varchar(40);
その２
create index idx2 on customer(info) generate key using
xmlpattern '//phone' as sql varchar(40);
その３
create index idx3 on customer(info) generate key using
xmlpattern '/customerinfo/*' as sql varchar(40);
55
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引が示す範囲が、クエリーが示す範囲より広い
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引定義→
↓クエリー
索引を使う
索引を使わない
…using xmlpattern
'/customerinfo/phone‘
…using xmlpattern
'//phone‘
…using xmlpattern
'/customerinfo/*‘
as sql varchar(40);
as sql varchar(40);
as sql varchar(40);
where $i//phone
= “905-555-4789”
where $i/customerinfo/phone
= “905-555-4789”
where $i/customerinfo/*
= “905-555-4789”
56
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引のデータタイプと、クエリーのデータタイプが一致している
<customerinfo cid=“1004”>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引定義→
↓クエリー
…using xmlpattern
'/customerinfo/@cid' as sql
varchar(10);
索引を使う
索引を使わない
…using xmlpattern
'/customerinfo/@cid' as sql
double;
for $i in db2-fn:sqlquery(…) where
$i/customerinfo/@cid = “1004”…
for $i in db2-fn:sqlquery(…) where
$i/customerinfo/@cid = 1004 …
57
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引とクエリーで使用される/text()に、一貫性がある
for $i in db2-fn:sqlquery(…)/customerinfo where $i/phone = “905-555-4789”
return $i/name
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
<name>Matt Foreman</name>
customerinfo
結果が異なる
結果が異なる
要素ノード
テキスト・ノード
name
phone
Matt Foreman
Matt Foreman 905-555-4789
for $i in db2-fn:sqlquery(…)/customerinfo where $i/phone = “905-555-4789”…
return $i/name/text()
58
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引とクエリーで使用される/text()に、一貫性がある
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引を使う
索引定義→
↓クエリー
customerinfo
要素ノード
name
phone
テキスト・ノード
Matt Foreman 905-555-4789
索引を使わない
…using xmlpattern
'/customerinfo/name‘
…using xmlpattern
'/customerinfo/name/text()‘
as sql varchar(35);
as sql varchar(35);
where $i/customerinfo/name
= “Matt Foreman”
where
$i/customerinfo/name/text()
= “Matt Foreman”
59
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
1-④XML索引の設計 - XML索引に特徴的な考慮点
– 索引を作成する場合の考慮点
•
•
•
•
アプリケーションからのアクセスを考慮して、適切な型の索引を選定する
– 同じxPatternに対して、異なるSQLデータ型にマップした複数の索引を作成可能。
– たとえばクエリーで「 a/b [ c = 44] 」とする場合、数値型の索引が必要。文字列の
索引は有効ではない
要件を満たす範囲で、索引エントリ数はなるべく少なくなるよう考慮する。
– 「//name」よりも「/customerinfo/name」
非効率的なI/Oや、更新性能の低下を避けるため、該当要素が多すぎる索引は避ける
– 「//text()」、「//*」等
複合索引は作成できない
– 「リレーショナル列＋XMLエントリ」及び、「XMLエントリ＋XMLエントリ」のどちらも
作成できない。
– NSEの考慮
•
•
60
XMLインスタンス内の全文検索が必要な場合、Net Search Extender（NSE）の使用を検
討する。
NSEはDB2に付属する全文検索エンジンであり、属性検索、ファジー検索、Boolean検索、
Stemming、など多様な検索が可能
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
索引エントリ数が増えすぎるxPatternの例
create index idx4 on customer(info)
generate key using
xmlpattern '//text()'
as sql varchar(40);
ƒ
NSEの参考資料
–
XML full-test search in DB2 [3-2]
–
• http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0606seubert/?ca=dnw-724
DB2 Net Search Extender V8の使用 [3-3]
•
61
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state>Ontario</state>
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
<assistant>
<name>Peter Smith</name>
<phone type="home">416-555-3426</phone>
</assistant>
</customerinfo>
http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/0016B3B6
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
2-①XMLスキーマの作成
ƒ XMLスキーマの作成
– 「ステップ6.1 論理モデルから物理モデルへの展開」完了後に、リレーショ
ナル側でのテーブル定義、索引定義作成と同期して、XMLスキーマの作成
を行う。
62
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-①データ容量の見積もり - XML列を含む表の容量見積もり
ƒ XML列（データ）の容量について
– XML列に格納されると、テキスト時より多くの容量が必要
– 日本語を含むデータの場合、元ファイルの文字コードにより膨張率が変化
– 格納後のXMLサイズは、タグ長には無関係
ƒ どのようにして本番データ量を見積もるか
– 少量データを試験的にDB2に投入し、そのデータ量から見積もる
– ページサイズによっても格納効率が変化するため、少量データの試験から
1ページあたりに格納できるXMLインスタンス数を見積もる
– XML列を含む場合のレコード長には、XML descriptorの長さ（84byte）も考
慮に入れて算出
ƒ DB2に格納したXMLデータの容量確認方法
– SYSIBMADM.ADMINTABINFO 管理ビュー
– db2pd -tablespaces コマンド
– db2 inspect コマンド
63
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML列（データ）の容量について
– XMLデータがXML列に挿入されると、DB2がツリー上に展開して格納するために、テキスト時より多くの容量が必要と
なります。
• 膨張率はデータの構造により影響を受けるため、見積もるのが困難です。
– 日本語を含むデータの場合、XMLファイルがUTF-8かSJISかといった文字コードの種別により膨張率が変化します。
•
•
•
•
DB2内部ではXMLデータはUTF-8で保持されます。UTF-8では1文字を1～6バイトで表現するため、同じ長さの文
字列を表すためのデータ量がSJISの場合よりも大きくなります。
XMLファイルがUTF-8の場合、DB2に格納しても文字コードの違いによる膨張は発生しません。（つまり、膨張率
が低くなる）
XMLファイルがSJISであった場合、DB2に格納するためUTF-8に変換するので、元のファイルサイズよりも膨張し
ます。（つまり、膨張率が高くなる）
投入元ファイルの文字コードによらず、DB2に格納された後のサイズは同じです。（必ずUTF-8になるため）
– XMLのタグ部分は、DB2が内部的に数値に置き換えるため、格納後のサイズは、タグ長には無関係となります。
•
XMLファイルのサイズが、長いタグ名を多く持つために大きくなっている場合、XMLファイルの膨張率は低くなる可
能性があります。
– リレーショナル部分のレコード長の算出の際、各XML列にはXML descriptorとして84bytesを含めます。
ƒ
次のページから、容量を確認する方法を見ていきます。
– Sample DBのPRODUCT表と同定義の表について、リレーショナル、索引、XMLの各表スペースを分けて定義した例
です。
– 例で使用したデータの概要は解説の最後に掲載しています。
64
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ
DB2に格納したXMLデータの容量確認方法
–
管理ビュー「SYSIBMADM.ADMINTABINFO」
• 表の各データ・オブジェクト（データ、索引、LOB、LONG、XML）ごとにキロバイト単位での容量が取得可能です。
常に最新の情報が取得可能です。（Runstats不要）
• 各オブジェクトが同一表スペースでも、使用量を別々に取得可能です。
• データはエクステント単位で増加するため、1XMLインスタンスあたりに占める容量を直接取得することは出来ませ
ん。1エクステント分増加するまでINSERTを行い、1エクステントあたりに格納可能な文書数から逆算する必要があ
ります。
SampleDBのPRODUCT表と同定義の表の0件時の出力
SELECT SUBSTR(TABNAME,1,15),DATA_OBJECT_P_SIZE,INDEX_OBJECT_P_SIZE,XML_OBJECT_P_SIZE FROM SYSIBMADM.ADMINTABINFO
WHERE TABNAME ='PRODUCT2'
1
DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE XML_OBJECT_P_SIZE
--------------- -------------------- -------------------- -------------------PRODUCT2
256
256
256
1 レコードが選択されました。
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後
SELECT SUBSTR(TABNAME,1,15),DATA_OBJECT_P_SIZE,INDEX_OBJECT_P_SIZE,XML_OBJECT_P_SIZE FROM SYSIBMADM.ADMINTABINFO
WHERE TABNAME ='PRODUCT2'
1
DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE XML_OBJECT_P_SIZE
--------------- -------------------- -------------------- -------------------PRODUCT2
2048
2176
6144
1 レコードが選択されました。
65
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
–
db2pdコマンド
•
•
db2pd -tablespaces -db <DB名>で表スペースの使用ページ数を取得可能です。
データ、索引、XMLの表スペースを分けている場合は、それぞれの使用量が確認できます。
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後（抜粋）
$ db2pd -tablespaces -db sample
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:53:42
Tablespace Configuration:
Address
Id
Type
0x0780000020A7F940 0
DMS
0x0780000020F01AC0 1
SMS
0x0780000020F06320 2
DMS
0x0780000020F06B80 3
DMS
0x0780000020F073E0 4
DMS
0x078000002100A2A0 5
DMS
0x0780000021049DA0 6
DMS
0x0780000021045BA0 7
DMS
Tablespace Statistics:
Address
Id
0x0780000020A7F940 0
0x0780000020F01AC0 1
0x0780000020F06320 2
0x0780000020F06B80 3
0x0780000020F073E0 4
0x078000002100A2A0 5
0x0780000021049DA0 6
0x0780000021045BA0 7
66
Content
Regular
SysTmp
Large
Large
Large
Large
Large
Large
TotalPgs
16384
1
8192
8192
8192
8192
8192
8192
PageSz
4096
4096
4096
4096
4096
4096
4096
4096
ExtentSz
4
32
32
32
32
32
32
32
UsablePgs
16380
1
8160
8160
8160
8160
8160
8160
Auto
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
UsedPgs
10688
1
1888
608
1504
608
1632
640
Prefetch
24
192
192
192
192
192
192
192
BufID
1
1
1
1
1
2
2
2
PndFreePgs
0
0
0
0
0
0
0
0
BufIDDisk
1
1
1
1
1
2
2
2
FreePgs
5692
0
6272
7552
6656
7552
6528
7872
FSC
On
On
On
On
On
On
On
On
HWM
10688
0
1888
608
1504
608
1632
288
NumCntrs
1
1
1
1
1
1
1
1
MaxStripe
0
0
0
0
0
0
0
0
State
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
LastConsecPg
3
31
31
31
31
31
31
31
MinRecTime
0
0
0
0
0
0
0
0
Name
SYSCATSPACE
TEMPSPACE1
USERSPACE1
IBMDB2SAMPLEREL
IBMDB2SAMPLEXML
TS01
TS01LONG
TS01IND
NQuiescers
0
0
0
0
0
0
0
0
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
– db2 inspectコマンド
• db2 inspectコマンドにより、各オブジェクトの使用量を取得することが可能です。
• 各オブジェクトが同一表スペースでも、使用量を別々に取得可能です。
• 下記コマンドでインスタンス・ホームディレクトリのdb2dumpディレクトリに出力されます。
– db2 inspect check table name <表名> schema <スキーマ名> results keep <出力ファイル名>
• 下記コマンドで上記の出力をテキスト・ファイルにフォーマットします。
– db2inspf <上記の出力ファイル名> <フォーマット後ファイル名>
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後（抜粋）
表フェーズが開始しました。(ID 符号付き: 4、符号なし: 4; 表スペース ID: 5) : DB2INST1.PRODUCT2。
データ・フェーズが開始しました。 オブジェクト: 4、表スペース: 5。
この表の索引タイプは 2 です。
エクステント・マップの全探索 DAT、アンカー 96。
エクステント・マップの全探索が完了しました。
DAT オブジェクト・サマリー: 合計ページ数 477 - 使用済みページ数 477 - フリー・スペース 3 %。
データ・フェーズが終了しました。
索引フェーズが開始しました。 オブジェクト: 4、表スペース: 7。
エクステント・マップの全探索 INX、アンカー 96。
エクステント・マップの全探索が完了しました。
INX オブジェクト・サマリー: 合計ページ数 487 - 使用済みページ数 487。
索引フェーズが終了しました。
XML/XDA フェーズが開始しました。オブジェクト: 4、表スペース: 6。
エクステント・マップの全探索 XDA、アンカー 96。
エクステント・マップの全探索が完了しました。
XDA オブジェクト・サマリー: 合計ページ数 1504 - 使用済みページ数 1504 - フリー・スペース 5 %。
XML/XDA フェーズが終了しました。
表フェーズが終了しました。
67
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ 今回の例で使用したデータの概要です。
- SYSIBMADM.ADMINTABINFO
- db2pd -tablespaces -db sample
- db2 inspect
XMLデータ
XMLデータ
XMLデータ
SAMPLEデータベースのProduct表
のDescription列の文書と同じ構造
（1文書はファイルで約268バイト）
実行環境
AIX5.3
DB2 V9.1 FixPak2
68
Product2表
10000件挿入
--表スペース
create tablespace ts01 bufferpool bp01;
create tablespace ts01long bufferpool bp01;
create tablespace ts01ind bufferpool bp01;
--表
create table product2 like product in ts01 long in ts01long index in ts01ind;
--XML索引
create index product_desc_xind3 on product2(description) generate key using
xmlpattern 'declare default element namespace "http://posample.org";
/product/@pid' as sql double;
create index product_desc_xind1 on product2(description) generate key using
xmlpattern 'declare default element namespace "http://posample.org";
/product/description/name' as sql varchar(128);
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-①データ容量の見積もり - XML列を含む表の容量見積もり
ƒ XML列（索引）の容量
–
XML索引の容量見積もり
–
DB2が内部的に作成するRegions Index、Paths Index
ƒ 再編成時に必要な容量
69
–
一時表スペースを利用する場合
–
通常表スペースを利用する場合
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML列（索引）の容量について
– XML索引
索引を付与する要素の構造や、XML索引のオーバーヘッドのために、リレーショナル索引と比較して多少大きくなりま
す。
• 一文書内に繰り返し出現する要素に対して索引を付与した場合は、1行のデータに対して複数の索引エントリが作成さ
れます。
• XMLデータ容量と同様に、少量データの試験により見積もります。
– XML索引の他に、XMLデータがどのページに格納しているかを管理するRegions Indexと、XMLデータのパスを保持する
Paths Indexが索引表スペースに格納されます。
•
•
ƒ
これらは管理用のデータであり、大きな容量を占めることはありません。
（SampleDBのPRODUCT表のDESCRIPTION列のXMLデータ10000件挿入に対して500KB程度）
再編成時に必要となる容量
– XMLデータを再編成する際に、リレーショナル・データと同様に一時表スペースを使用することが可能です。
– 指定しない場合、表の存在する通常表スペースの領域が使用されます。
– リレーショナルと同様、XMLデータの容量の2から3倍を見積もる必要があります。
70
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-①データ容量の見積もり - XML列を含む表のページ・サイズ選択
ƒ XMLデータもリレーショナル・データと同様にページに格納される
ƒ XMLを格納する表スペースはリレーショナル列と分割が可能
–
最適なページ・サイズが異なるため分割が推奨
–
DB2ではページサイズとして、4KB、8KB、16KB、32KBの4種類が表スペースごとに
選択可能。
ƒ 分割した場合
71
–
リレーショナル列については、従来と同様にレコード長を見積り、ページ・サイズを決定
–
XML列については、充填率を考慮してページ・サイズを決定
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
リレーショナル列とXML列は大きさが異なるため、XMLインスタンスを格納する表スペースはリレーショナル列と分割
することが推奨されます。
– XMLインスタンスは一般的にサイズが大きくなるため、リレーショナル列とXMLインスタンスを同じページサイズ
に格納した場合、どちらかが最適でなくなる可能性があります。
– XMLインスタンスのregion分割をなるべく押さえるため、XMLインスタンス用のページサイズは大きめにします。
•
•
ƒ
ただし、必ず32KBページサイズを採用すべきと言うわけではありません。
たとえば、「平均5KBのXMLインスタンスを32KBページに格納」はお勧めできません。
– 一文書取得のために大きなページを取得しなければならないため、I/O負荷が高くなる可能性があります。
分割した場合、リレーショナル列については、従来と同様にレコード長を見積り、ページ・サイズを決定します。
– リレーショナル列の列長に、XML descriptorの長さも考慮に入れてレコード長を算出します。
•
•
1XML列あたりのdescriptorのサイズは84バイト
特に表の構造として前述の「パターン3（XML列を横持ち）」を取るケースでは、レコード長への影響が大きくな
るため注意
– レコード長を元にページサイズを決定します。
ƒ
XML列は、充填率を考慮してページ・サイズを決定します。
– 格納後のXMLデータ容量を元にページサイズを決定します。
– 小さなページを使用すると、XMLデータが複数リージョンにまたがる可能性があります。
72
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-①データ容量の見積もり - XML列更新によるログ量
ƒ 更新によるログ量について
–
XML列は部分更新でも全入れ替えとなるため、ログ容量の考慮が必要
• ログ容量を明確に見積もる方法はない
• varcharの更新よりも使用ログ量は多くなる傾向
• 更新時でも挿入時と少なくとも同等のログ容量が必要
73
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
74
更新によるログ量について
–
現在のバージョンのDB2では、XMLインスタンスの更新は文書の入れ替えとなるために、多くのログが必要とな
ります。
–
varcharに文字として挿入されたXMLインスタンスを更新するのと比較して、多くのログ容量が必要となる傾向が
あります。
–
XMLインスタンスの構造によりログ量は変化するため、一概にファイルサイズから見積もるのは困難です。
–
更新時に必要なログ量も見積もり、更新の割合を考慮する必要があります。
–
実際にデータを更新し、ログ量を測定して見積もる必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-②インスタンスの構成とDBの分割
ƒ 文字コードの制約（Unicodeにしたくないデータの保持方法）
–
DB2 V9.1ではXMLデータ型を格納するデータベースはUnicodeデータベース
にする必要がある。
–
データ容量や他システムとの連携上、Unicodeで保持したくないデータが存在
する場合、XMLインスタンスを保持するデータベースと、それ以外のデータを保
持するデータベースを分割することを検討する。
•
•
75
二つのデータベース間を透過的にアクセスする場合、DB2の提供するFederation機
能を使用する。
DB2 V9.1以降では、Federation機能を使用するため別フィーチャーであるHFF
（Homogeneous Federation Feature）を別途購入する必要あり。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-③表の分類と表スペースの構成
ƒ リレーショナル・データと同様、XMLインスタンスも表スペースに格納される
ƒ 表スペースの設計方針（XMLデータの割り当てを検討）
– XMLインスタンスを格納する表スペースの選択
• リレーショナル・データと別の表スペースを使用
• リレーショナル・データと同様の表スペースを使用
– XML索引、リレーショナル索引は共通
– 一時表スペース
ƒ バッファープール
– XMLインスタンスのI/Oにはバッファープールが使用される
– バッファープール定義の選択
• XMLインスタンスのためのバッファープールをリレーショナルと分
割
• 同一のバッファープールを使用
76
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
リレーショナル・データと同様、XMLインスタンスも表スペースに格納されます。
–
ツリー構造に変換され、DB2のページに格納されます。
–
複数ページにまたがるXMLインスタンスは、Region Indexにより管理されます。
ƒ
表スペースの設計方針として、XMLデータ（XML Data：XDA）の表スペースへの割り当てを検討します。
–
XMLインスタンスを格納する表スペースの選択
• リレーショナル・データと別の表スペースを使用
– CREATE TABLE時にLONG INオプションで指定することで、XMLインスタンスを別の表スペースに格納
することができます。
– この場合、バッファープール、ページ・サイズをXMLインスタンスとリレーショナル・データで分けることが可
能となります。
• リレーショナル・データと同様の表スペースを使用
– LONG INオプションを使用しない場合、INで指定された表スペースにXMLインスタンスも格納されます。
– この場合、表スペース、バッファープールの数が少なくなり、管理の負担を減少させることが可能となります。
–
XML索引、リレーショナル索引は共通
• 索引については、INDEX INで指定した場合、同じ表スペースが使用されます。
–
一時表スペース
• XML列を含む表の再編成を、一時表スペースを用いて行う場合、必要量に応じたサイズを確保する必要がありま
す。
77
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ
78
バッファープール
–
XMLインスタンスではバッファープールが使用されます。
• XMLインスタンスでも、リレーショナル・データと同様にバッファープールが使用されます。
• XMLインスタンスの読み込みでは、XSCANにより論理読み込みの値が大きくなる傾向があるので、リレーショナル
と比較してバッファープール・ヒット率が大きめになる可能性があります。
• 複数ページに格納されているXMLインスタンスの一部分を出力する場合でも、文書全体がバッファープールに格納
されます
–
バッファープール定義の選択
• XMLインスタンスのためのバッファープールをリレーショナルと分割
– 表スペース定義を分けることにより、バッファープールを分割することが可能となります。
– この場合、バッファープール使用状況のモニタリングが容易になります。
– ページ・サイズによる分割が可能となります。（リレーショナルは4K、XMLインスタンス32Kなど）
• 同一のバッファープールを使用
– XMLインスタンス/リレーショナル・データを格納する表スペースのページ・サイズを共通にする必要があり
ます。
– XMLインスタンス/リレーショナル・データ個別のバッファープール使用量見積が不要となり、管理が容易に
なります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-④表スペースの配置
ƒ XMLインスタンスを格納する表スペースの物理配置
– 物理ディスクへの配置
ƒ 再編成の考慮
– XMLインスタンスを含む表スペースを再編成の対象とするかどうかを
まず決定
• パフォーマンス劣化度合い、フリースペースの調査
– LONGLOBDATAオプションの使用
– 一時表スペースの指定
– オンライン再編成の未サポート
79
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XMLインスタンスを格納する表スペースの物理配置
–
ƒ
リレーショナルと同様、ページ単位でアクセスされるため、DISK I/Oを分散させるために複数の物理ディス
クに配置します。
再編成の考慮
–
XMLインスタンスを含む表スペースを再編成の対象とするかどうかをまず決定します。
•
•
–
再編成を行う場合、以下のような点を考慮します。
•
•
•
80
単一のXMLインスタンスがディスク上の分散したページに格納された場合、パフォーマンスが劣化
する可能性があります。
db2 inspectコマンドを利用して、フリースペースなど実際に使用されているXDA領域を調査可能で
す。
再編制上の取り扱いはLONG/LOBと同様にLONGLOBDATAオプションを使用します。
再編成に使用する領域として、一時表スペースを指定できます。
オンライン再編成はサポートされていません。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-⑤表スペース以外のオブジェクトの配置
ƒ ログの配置
– XMLインスタンスの更新を見込んだログ容量を確保する
ƒ ワーク/バックアップ領域の配置
– XMLインスタンスもバックアップ・イメージに含まれる
– COMPRESSオプションが有効
ƒ 全文検索（NSE : Net Search Extender ）オブジェクトの配置
81
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ログの配置
–
大きなXMLインスタンスの更新が頻繁に発生する場合、ログ領域へのI/O負荷が高くなる可能性があります。
–
使用されるログ量については、XML構造等に依存するため、実際に測定して見積もる必要があります。
•
ƒ
DBスナップショットの「データベースで使用されたログ・スペース（バイト）」やdb2pd -logsコマンドで確
認できます。
ワーク/バックアップ領域の配置
–
XDA（XML Data Area）もバックアップ・イメージに含まれる
•
–
XMLインスタンスが含まれるXDAについても、リレーショナル・データと同様にバックアップ・イメージに
含まれます。
COMPRESSオプションが有効
•
ƒ
82
XDAを含んだバックアップ・イメージについても、COMPRESSオプションを指定することで圧縮すること
が可能となります。
全文検索（NSE : Net Search Extender）オブジェクトの配置
–
XMLインスタンスに対する全文検索使用時はNSEを利用します。
–
DB2の導入とは別に、NSEの導入、設定が必要となります。
–
索引のオブジェクト配置や運用については、通常のNSE使用時と同様に行います。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-⑥構成パラメータの設定
ƒ コードページの考慮
– UNICODE DBの使用
ƒ XML処理に特有のヒープ消費を考慮
– XML処理に使用されるヒープの初期サイズを大きくする
•
•
•
•
STMTHEAP
PCKCACHESZ
APPLHEAPSZ
STAT_HEAP_SZ
ƒ pureXMLに特有のパラメータ
– RUNSTATS時のDB2_XML_RUNSTATS_PATHID_K、
DB2_XML_RUNSTATS_PATHVALUE_Kレジストリー変数
83
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
コードページの考慮
–
ƒ
V9.1ではpureXMLはUNICODE DBでのみサポートされます。
XML処理に特有のヒープ消費を考慮
–
以下に挙げる、XML処理に使用されるヒープについては、初期サイズを大きくすることを検討します。
•
•
•
•
ƒ
pureXMLに特有のパラメータ
–
RUNSTATS時のDB2_XML_RUNSTATS_PATHID_K、DB2_XML_RUNSTATS_PATHVALUE_Kレジ
ストリー変数
•
•
•
84
コンパイル時のSTMTHEAP増加
PCKCACHESZの圧迫(Automatic可能)
Insert時のXMLパースに伴うAPPLHEAPSZ増加
RUNSTATS時（サンプリング）のSTAT_HEAP_SZ増加
これらのレジストリー変数により、RUNSTATSで取得するXMLインスタンスのPath-CountとPathValueの最大値を設定することが可能となります。
階層の多いXMLインスタンスを使用する場合に、より詳細な統計情報の取得が可能となります。
Path-Count、Path-Valueの実際の値については、db2catで確認が可能です。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：XMLに関連する統計情報
ƒ RUNSTATSによる統計情報の収集
–
XML関連の統計情報も、通常と同様RUNSTATSを使用して収集する。
•
•
–
収集される統計情報
•
•
•
–
デフォルトで、XML列の統計情報も収集される
XML列の統計情報収集を除外する場合、「EXCLUDING XML COLUMNS」を指定
Path-Count（doc count及び、node count）
Path-Value
収集するPath、Path-Valueの上限は、レジストリ変数によって指定可能（デフォルト200）
– DB2_XML_RUNSTATS_PATHID_K
– DB2_XML_RUNSTATS_PATHVALUE_K
SYSIBM.SYSTABLESの記述子（PACED DESCRIPTOR）に保存される
ƒ db2catによる統計情報の分析
–
システムカタログ表に格納されている記述子の内容を分析するツール。
–
db2lookの「-m」オプションでは、格納されているXMLインスタンスに関する詳細な情報は取得で
きない。
•
85
そのため、db2catを使用して取得する。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説 db2catの実行例
「-d」でDB名、「-s」でスキーマ名、「-n」でテーブル名を指定
「-t」は標準出力への出力を指定。
$ db2cat -t -d SAMPLE -s TEST -n PRODUCT2
DB2 Universal Database Version 9.1, 5622-044 (c) Copyright IBM Corp.
Licensed Material - Program Property of IBM
IBM DATABASE 2 Catalog Analysis and Repair Tool
Please use single quote for delimited name
*****************************************************************
Table: TEST
.PRODUCT2
(TABLE)
XML列
----------------------------------------------------------------「DESCRIPTION」
TABLE PACKED DESCRIPTOR:
の出力
＜省略＞
COLUMN NAME
: DESCRIPTION
Length of column name
: 11
Column id
: 6
Col type {hex, type}
: 0x0112 , XML
Col dist. type {hex, type}: 0x0090 , XML
Column length
:
80
lengthは記述子
Blob length
: 80
の長さのみ
Statistic offset
: -1
Flags
: 0x00000090
- SQLRG_MIXED
- SQLRG_NULLIND
Codepage
: 0
Length of user
default : 0
Logged
: 0
Compact
: 0
Datalink Features
: 000000
Ref. row type desc. offset: 0
No. unique values in col. : -1
Average column length
: 1
High2key and Low2key len. : 66
Types of Data Model
: 0
Delimiter length
: -1
Number of Subelements
: -1
Number of nulls
: -1
High2key
:
Low2key
:
Statistic Descriptor
: None
Security Label ID
: 0
86＜省略＞
---------------------------------------格納されているXMLインス
Top-k Pathid node counts
タンスの、Path情報に関す
---------------------------------------る統計情報
Max no. of path counts = 11
Cur no. of path counts = 11
Cnt( /root()/product/description ) = 7277
Cnt( /root()/product/description/weight ) = 7115
Cnt( /root()/product ) = 7092
Cnt( /root()/product/description/name/text() ) = 7053
Cnt( /root()/product/description/details/text() ) = 7038
Cnt( /root()/product/description/name ) = 7030
Cnt( /root()/product/description/weight/text() ) = 7015
Cnt( /root()/product/description/price/text() ) = 6922
＜省略＞
---------------------------------------Path-Valueに関する統計
Top-k Pathid-Value node counts
情報
---------------------------------------Max no. of path-value counts = 12
Cur no. of path-value counts = 12
Cnt( /root()/product/description/weight/text(),3:7kg ) = 7112
Cnt( /root()/product/description/details/text(),28:Basic Snow Shovel, 22
inches ) = 6829
Cnt( /root()/product/description/price/text(),3:4.0 ) = 798
Cnt( /root()/product/description/price/text(),3:0.0 ) = 742
Cnt( /root()/product/description/price/text(),3:6.0 ) = 735
Cnt( /root()/product/description/price/text(),3:7.0 ) = 735
Cnt( /root()/product/description/price/text(),3:5.0 ) = 732
Cnt( /root()/product/description/price/text(),3:2.0 ) = 707
Cnt( /root()/product/description/price/text(),3:8.0 ) = 704
Cnt( /root()/product/description/price/text(),3:3.0 ) = 686
Cnt( /root()/product/description/price/text(),3:1.0 ) = 623
Cnt( /root()/product/description/price/text(),3:9.0 ) = 613
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3-⑦シェル／コマンドの作成
ƒ XML Schema Repository
– XSR Objectを格納するためのRepository
– 以下の二つの方法でXSRを使用可能
• CLP
• ストアード・プロシージャー
87
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML Schema Repository
–
XSR Objectを格納するためのRepository
–
• XML SchemaまたはDTDと外部エンティティの登録が可能です。
• XMLインスタンスをValidateするために使用されます。
• XSR Objectは、BLOBとしてシステム・カタログに格納されます。
• XMLインスタンスが挿入される前に登録しておく必要があります。
以下の二つの方法でXSRを使用可能
•
•
88
CLP
–
REGISTRATIONで一つ目の文書を追加し登録開始、ADDで追加、COMPLETEで登録
完了します。
– REGISTER XSROBJECTでDTD、外部エンティティを登録します
– DROPで削除します。
ストアード・プロシージャー
– XSR_REGISTER、XSR_ADDSCHEMADOC、XSR_COMPLETEを使用します。
– XSR_DTDでDTD、外部エンティティを登録します。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XML物理設計 付録 XML特有のチューニングTips
ƒ 文書サイズ/タグ種類
– タグ種類数はInsert性能に影響を与える。少ないほどXMLパース負荷が低
く、Insert性能が良い。
– 文書サイズは照会性能に大きな影響を与える。
– タグ種類数はRunstats性能に影響を与える。
ƒ XML索引
– XML索引の作成時間は、XMLパターンの総数（繰り返し要素の１文書内の
出現回数 x 文書の件数）に影響を受ける。
– データ更新時の索引メンテナンスは、XML索引よりリレーショナル索引の
方が負荷は軽い
– 索引の対象ノード数や索引サイズ、索引数がInsert性能に影響を持つ。
89
© 2007 IBM Corporation
Fly UP