XMLDB.jp

XMLDB開発支援
HOME  >  XMLDB開発支援  >  Cyber Luxeonで学ぶXML DB入門 第7回:XML DBのチューニングポイント

Cyber Luxeonで学ぶXML DB入門 第7回:XML DBのチューニングポイント


WINGSプロジェクト 佐藤 治夫 (株式会社ビープラウド) [著], 山田 祥寛 [監修]
出典:開発者のための実装Webマガジン「Codezine」(株式会社翔泳社)


パフォーマンス要件はシステム構築時に考慮すべき最も重要なポイントの1つですが、XMLデータベースのチューニング情報はまだまだ不足している状況かと思います。本稿では、各XML DB製品に共通するであろうパフォーマンスのポイントについて、Cyber Luxeonを使用して実際に実行・測定し、検証を試みました。

 

はじめに

パフォーマンス要件はシステムを構築する際に、考慮すべき最も重要なポイントの1つです。リレーショナルデータベース(以降、RDB)に関しては、そのチューニングのポイントについては、書籍、Webなどで数多くの情報が存在しますが、XML DBに関してはまだまだこれからといったところです。そこで本稿では、Cyber Luxeonに限らず、各XML DB製品に共通するであろうパフォーマンスのポイントについて、実際に実行・測定し検証を試みました。

なお、XMLの更新機能に関してはXQuery Update Facilityの仕様策定が進められていますが、執筆段階では草案段階であり、XML DBごとにXML更新用の機能が提供されているのが現状です。そこで本稿ではXML DBの検索機能に対象を絞って説明を進めます。

対象読者

XMLに触れたことがある方、RDBなどデータベースを操作したことがある方を対象とします。

検証環境

まずは、本稿の検証に使用したハードウェアスペック、ソフトウェアを以下の表に示します。

 

 

 

 

XPath、XQueryの記法によるパフォーマンスの違い

テストデータ

XPath、XQueryの計測では、以下に示したXMLを共通で使用しました。1つのXMLファイルのように書かれていますが、実際は、item要素をルート要素とする10000個のXMLと、1つのバインダドキュメント(複数のXMLにショートカットを設定することによって、あたかも1つのXMLファイルかのように扱えるCyber Luxeonの機能)を使用しています。バインダドキュメントはMultiDoc_Container要素をルート要素とします。item要素は1万件作成されており、item要素内のprice要素にはランダムに整数値が格納されています。

 

 

 

 

 

 

 

測定方法

以下のJavaプログラムを使用して、実行時間を測定しました。検証にあたってはソースコード内のXQueryの文字列の箇所を検証ケースごとに、書き換えて使用しました。

 

 

 

 

 

検証ケース1:XPathで「//ノード名」を使うと遅い

 

 

仮説

XPathの検索では、ノードへのパスをすべて記述しなくても、//ノード名というかたちで検索対象ノードを指定することにより、コンテキストノード配下の該当するノードすべてを指し示すことができます。しかし、これを使用するとノードの連なりを順にたどるという処理(ノードウォーキング)が実行されてしまい、パフォーマンスが悪化することが予想されます。

 

抽出対象データ

item要素のprice要素が「1000」である商品名要素を抽出します。

 

検証用XQuery

以下に測定で使用したXQuery式を示します。2つのXQuery式は同じ結果を返します。

 

 

 

 

測定結果

各XQueryで1万要素を検索した結果を以下の表に示します。

 

 

 

 

予想通り、パスを直接指定した方が、実行時間が少なく済んでいます。

 

 

考察・結論

XPath式で「//ノード名」は、パフォーマンスが劣化するので、必要性がない限り、なるべく使用しない方が良いでしょう。今回のケースでは「//ノード名」に該当するノードは、コンテキストノード配下では1つでしたが、コンテキストノード配下に同一名のノードが複数ある場合にも、パスを直接指定してOr条件(||)で連結するなどした方が、パフォーマンスは向上するでしょう。検索対象のXMLのノードが多くなるほど、たどるノードも多くなるので、パフォーマンスの差も顕著にあらわれます。

 

 

検証ケース2:XPATHで1度で絞り込んだ方が、WHERE文で絞り込むよりも速い

 

仮説

ノードを条件で絞り込んで検索する場合に、XPathに検索条件を指定して1度で対象ノードを絞り込むパターンと、上位ノードをXPathで抽出してから、WHERE句を使用して、ノードを絞り込む場合では、1度で絞り込んだほうが、無駄なノードを変数に格納しない分性能が良いことが予想されます。

 

抽出対象データ

item要素のprice要素が「1000」である商品名要素を抽出します。

 

検証用XQuery

以下に測定で使用したXQuery式を示します。2つのXQuery式は同じ結果を返します。

 

 

 

 

 

測定結果

各XQueryで1万要素を検索した結果を以下の表に示します。

 

 

 

 

予想通りXPathで1度で絞り込んだ方が、実行時間は少なくすんでいます。

 

考察・結論

XPathで抽出する時点で絞り込んだ方が性能が良いという結果になりました。それは、XPathで絞り込まないパターンの場合、一旦ノードを変数に格納し、その上で絞り込むので、ノードがメモリに展開される分、オーバーヘッドがあるためと考えられます。余計なオーバーヘッドを生まないためにも、 XPath上で絞り込める場合は、そのようにした方が良いでしょう。

 

 

XML DBへは正規化して格納する

XML DBにデータを格納するときは、XMLを正規化(normalize)し、データサイズをなるべく小さくし保存することが推奨されます。 XMLの正規化とは、論理的にXMLが同一であるということを保証したうえで、人が読みやすいようにXMLに付加された改行、インデント(半角スペース、タブ、改行)を取り除いたり、要素値が空値の場合で開始タグと終了タグがある場合に、終了タグ(<タグ名/>)のかたちに変換する処理のことをいいます。

 

正規化により、データベース全体の物理データサイズが減少し、フラグメンテーションによる性能の劣化などをあらかじめ防止することができます。またデータの転送量が減少するので、ネットワークへの負荷も軽減できます。

 

 

アプリケーション開発時の注意点

 

XMLの解析方式による違い

X

MLアプリケーションを開発する際に最も注意するべき点は、XMLを解析する際のXMLの処理方式でしょう。以下の表にXML操作方式別の特徴と、デメリットをまとめました。

 

 

 

 

アプリケーションの要件にもよるとは思いますが、上記3つの中では、 StAXを採用するのが今後は最もバランスが良いでしょう。DOMを使用する際は、XMLをパースする負荷、メモリ消費量が大きいので、注意が必要です。使用する場合は、DOMの解析実行頻度、処理同時並行性などを考慮する必要があるでしょう。

 

 

DOMツリーとJAXBオブジェクトツリーのメモリー使用量比較

 

第4~6回の「XML DBとJavaAPI、JAXB2.0を活用したWebアプリケーション開発」(設計編、APIチュートリアル編、実装編)で、JAXBを用いたXMLアプリケーションを開発する手法を説明しました。JAXBもDOMと同様、XMLのデータ構造をツリー構造に保持して操作しますので、メモリーの使用量が気になるところです。ここでは同じXMLデータをDOM形式で保持した場合とJAXBのオブジェクトで保持した場合のメモリーサイズを比較してみました。

 

 

使用したXML

 

以下に検証に使用したXMLを示します。第4~6回で使用した商品のXMLと同一です。実際のXMLは、インデントされておらず正規化されたものを使用しました。

 

 

 

検証方法

以下のJavaプログラムを使用して、XMLを格納したオブジェクトの生成前後のヒープメモリサイズを測定し、前後のメモリサイズの差分によってオブジェクトのサイズを計測しました。

 

 

 

 

 

測定結果

測定結果を以下の表に示します。

 

 

 

 

 

 

JAXBのオブジェクトの方が、使用メモリが少ないという結果になりました。

 

 

考察・結論

同一のXMLをDOMオブジェクトとJAXBのオブジェクトに格納した場合は、DOMオブジェクトに格納した場合の方がメモリを多く使用しました。これは、DOMオブジェクトの方がXMLの階層構造など、XMLに関する情報をオブジェクト内に格納しているためと考えられます。このようにDOMと JAXBは、同じようにXMLデータをオブジェクトのツリー構造で格納するにしても、JAXBの方が、メモリ消費量が少なく、かつデータ操作のプログラミングもしやすいというメリットがあるので、DOMとJAXBであれば、JAXBの採用をお勧めします。

 

 

XMLデータの構造について

XML DBの検索時に十分な性能を引き出すために最も重要なことを1つ挙げるとしたら、インデックスを適切に使用することでしょう。いくら XML DBがスキーマレスという特徴を持つといっても、ただ単にwell-formed(整形式)でさえあればどのような構造のXMLでも格納してよいというわけではありません。十分な性能を得るためには、XMLのデータ構造も適切に設計する必要があります。

 

ただしXMLのデータ構造で、どのようなものが良いとは一概には言えません。それは、インデックスの種類や性質、検索処理別の性能の良し悪しについては各XML DB製品ごとに異なるからです。開発の中で使用する製品のインデックスの特徴を把握し、検証を繰り返すことによって、性能を引き出していくという作業が必要になるでしょう。

 

 

まとめ

本稿では、XML DB使用時のパフォーマンスに関する注意点として、XQuery、XPathを記述する際の注意点、そしてアプリケーションを開発する際の注意点について、実際に測定し検証しました。今後、XML DBが世の中に普及していくにつれ、パフォーマンスチューニングに関する情報も蓄積されていくと思われます。

 

本稿までで7回にわたって、XML DBについて、Cyber Luxeonを使用して説明してきました。一般的に、何か新しいシステムを開発するといった話がある場合に、RDBをバックエンドDBとして採用されることが暗黙的に前提となっています。

 

しかし今後システムへの要求は一層複雑化していきます。複雑なデータ構造を持つシステムをRDBで開発するという前提で見積ると、多くの時間がかかってしまうというような場合にも、XML DBでの開発を検討すると、RDBよりも少ない時間で開発ができるという場面が考えられます。

 

本連載が、XML DBの採用をこれから検討する方々、そしてXML DBをシステムのバックエンドソリューションの1つとして考えている方々の一助となれば幸いです。

 

 

参考資料

  • 『Cyber Luxeon ハンドブック』 サイバーテック社
  • 『XMLデータベース入門』 山田祥寛 著、翔泳社、2006年4月

 

 

著者紹介

WINGSプロジェクト 佐藤 治夫 (株式会社ビープラウド) (サトウ ハルオ)

WINGSプロジェクトについて

有限会社 WINGSプロジェクトが運営する、テクニカルライティング・プロジェクト。海外記事の翻訳から、主にサーバサイド分野の書籍・雑誌/Web記事の執筆、講演、アプリケーション開発等を幅広く手がける。2005年9月時点での登録メンバは20名で、現在も一緒に執筆をできる有志を募集中。執筆に興味のある方は、どしどし応募頂きたい。CodeZine記事は、WINGSプロジェクト執筆/山田祥寛監修で今後も続々公開予定。



山田 祥寛 (ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「入門シリーズ(サーバサイドAjax/XML DB/PEAR/Smarty)」「独習シリーズ(ASP.NET/PHP)」「10日でおぼえる入門教室シリーズ(ASP.NET/PHP/Jakarta/JSP&サーブレット/XML)」「Pocket詳解辞典シリーズ(ASP.NET/PHP/Perl&CGI)」「今日からつかえるシリーズ(PHP/JSP&サーブレット/XML/ASP)」「書き込み式 SQLのドリル」他、著書多数。


 

▲このページのTOPへ

  • 無償で使える!XMLDB「NeoCore」
  • サイバーテック求人情報
  • メールマガジン申し込み
  • TEchScore

  • ▲NeoCoreについて記載されています!

  • ▲XMLマスター教則本です。試験対策はこれでばっちり!
Copyright (c) CyberTech corporation ltd. All ights Reserved. | サイバーテックについて | ご利用ガイド