XML専用ストレージの特質を知り、最適な利用法を学ぶためのネイティブXMLデータベース導入ガイド

        <Awards>
            <Academy>
                <Nominee>Best Art Direction</Nominee>
                <Nominee>Best Film Editing</Nominee>
                <winer>Best Visual Effects</winer>
            </Academy>
        </Awards>
    

        TConnection tcon = TConnectionFactory.getInstance()
        .newConnection ("http://localhost/tamino/mydb") ;
    

Java API

データベースへのアクセス手段として、HTTPを使用しWebサーバを経由するものと、TCP/IPの独自プロトコルを使用しWebサーバを経由しないWebサーバレスアクセスの2種類を提供している。後者のほうがHTTP通信時のオーバーヘッドがなくなるため性能が向上する。リスト6は、Webサーバレス アクセスによる検索の例である。11行目がWebサーバレス アクセスの指定である。HTTPを使用する場合には、

        TConnection tcon = TConnectionFactory.getInstance()
        .newConnection ("http://localhost/tamino/mydb") ;
    

に変更する。

リスト6：JavaAPI

        1: import com.softwareag.tamino.db.api.accessor.*;
        2: import com.softwareag.tamino.db.api.connection.*;
        3: import com.softwareag.tamino.db.api.objectModel.*;
        4: import com.softwareag.tamino.db.api.objectModel.dom.*;
        5: import com.softwareag.tamino.db.api.response.*;
        6:
        7: public class TaminoQuery {
        8:
        9:   public static void main(String[] args) {
        10:     try {
        11:       TConnection tcon = TConnectionFactory.getInstance().newConnection
        ("wsl:///tamino/mydb") ;
        12:       TXMLObjectAccessor tacc = tcon.newXMLObjectAccessor (
        13:       TAccessLocation.newInstance("movie"),
        14:       TDOMObjectModel.getInstance() ) ;
        15:
        16:       TLocalTransaction tloc = tcon.useLocalTransactionMode() ;
        17:       TQuery query = TQuery.newInstance ("/movie[title ='Star Wars']") ;
        18:
        19:       TResponse tresp = tacc.query (query,5);
        20:
        21:       int totalCount = 0 ;
        22:       TXMLObjectIterator ti = tresp.getXMLObjectIterator() ;
        23:       while (ti.hasNext()) {
        24:         totalCount++;
        25:         ti.next().writeTo(System.out,"Shift_JIS");
        26:         System.out.println("");
        27:       }
        28:       tloc.commit();
        29:       tcon.close ();
        30:     } catch(Exception e) {
        31:       e.printStackTrace() ;
        32:     }
        33:   }
        34: }
    

使用感・コメント

試用した範囲では安定して動作し、開発ツールも充実しており使いやすい。XMLスキーマが前提であるため開発の敷居は高いが、開発支援のツールによって軽減されている。アーキテクチャの見直しや最適化によって以前のバージョンに比べて性能が大幅に向上しているとのことである。

ウェルフォームドXMLも扱うことが可能であるが、インデックスを設定することができないので検索時性能は期待できない。試用版では、使用期限以外に容量制限が設定されており、20Mバイトを超えるデータベースを作成することができないのでパフォーマンスについてはコメントできない。

リスト7：JavaAPI

        1: import java.sql.Connection;
        2: import java.sql.DriverManager;
        3: import java.sql.ResultSet;
        4: import java.sql.Statement;
        5: import oracle.jdbc.driver.OracleResultSet;
        6: import oracle.xdb.XMLType;
        7:
        8: public class OracleQuery {
        9:
        10:   public static void main(String[] args) {
        11:     String qry ="select x.movie.extract('/movie') from MOVIE_XML x "
        12:     + "where x.movie.existsNode('/movie/title[text() = "Star Wars"]') = 1";
        13:     try {
        14:       Class.forName ("oracle.jdbc.driver.OracleDriver");
        15:       Connection conn = DriverManager.getConnection ("jdbc:oracle:oci8:@HS","scott", "tiger");
        16:       Statement s = conn.createStatement();
        17:       ResultSet rset = s.executeQuery(qry);
        18:       OracleResultSet orset = (OracleResultSet) rset;
        19:       while(orset.next()){
        20:         XMLType xt = XMLType.createXML(orset.getOPAQUE(1));
        21:         System.out.println(xt.getStringVal());
        22:       }
        23:     } catch (Exception e) {
        24:       e.printStackTrace();
        25:     }
        26:   }
        27: }
    

Oracle XML DB

Oracle 9iは、米国Oracle社の主力データベース製品である。Oracle 9i Release 2 以降のバージョンでネイティブXMLデータベースとしての機能が登場した。試用したバージョンは9.2.0.3である。

特徴

XML DBと呼ばれるRDBとは異なるメカニズムで動作するXMLデータ用のストレージが提供されている。このストレージは、オブジェクトリレーショナルデータベース機能をベースにネイティブXMLデータベースを実現している。

複数のXMLデータ格納手段

RDBが扱うリレーションは二次元の表(テーブル)に見立てることができるが、Oracleでは、この表の各マス目(セル)の中でオブジェクトを扱うためにユーザ定義型という機能を提供している。この機能を使えば、セルの中に階層構造を持たせたり、セルから他のテーブルを参照してテーブルのネストを作ったりすることで、ユーザは任意のオブジェクトを定義することができる。このメカニズムを利用してXMLデータに特化したXMLTypeというデータ型とそれを利用する関数群を提供したのがXML DBである。

XMLTypeでは非構造化ストレージと構造化ストレージの二種類での扱いが可能だ。非構造化ストレージはセルの中にXMLのテキスト(CLOB)を格納するもので、スキーマの必要のないウェルフォームドXMLを扱うことができる。もうひとつが構造化ストレージで、XMLType型のセルにXML Schemaを指定することで、セルの中に構造を持ったXMLデータを格納することができる。この他に、XMLデータをRDBのテーブルにマッピングするためのOracle XML Developer's Kitも提供しているので、ユーザはデータの特性に応じてXMLデータを扱うための3種類の方法を選択することができる。

SQLに統合化されたXMLストレージ (図※6)

XMLTypeはSQLで扱えるデータ型であるため、PL/SQL、JDBC、各種のビューの機能から、他のデータ型と同様に扱われる。XMLの構造を扱うためのXPath検索、XSLT変換などの関数が用意されている。構造に基づく検索はSQL からXPath式を用いた関数を呼び出すことによって実行される。XPathの問い合わせは、内部的にネストされたオブジェクトに直接アクセスする形式に変換されて実行される。この最適化の手法はクエリ・リライトと呼ばれている。また、通常のリレーションに対するSQLでの検索結果からXMLを生成する関数群も用意されている。

インデックス

XMLTypeのデータには、関数インデックスとテキストインデックス（Oracle Textインデックス）が用意されている。関数インデックスは関数の実行結果をインデックスとして用いるもので、例えばXPathで検索を行う関数に関数インデックスを設定することで、構造インデックスと同等のインデックス指定が行える。なお、関数インデックスは、一度実行しないと有効にならないことに注意が必要である。

ビューの利用

XMLTypeのデータと通常のリレーションを透過的に扱うためにビュー機能が提供されている。XMLTypeビューは、リレーションをXMLTypeのデータとしてアクセスすることを可能にする。逆にリレーショナル・ビューは、XMLType型のデータをリレーションとしてアクセス可能にする。

Java API

JDBCドライバのTypeII(OCI)を使用することになる。リスト7は、JDBCを使用した、XMLType操作の例である。6行目で、XMLTypeのクラスをインポートしている。プログラミングは通常のJDBCを使用した場合と差がないところに注目していただきたい。

リスト8：JavaAPI

        1: import com.exln.dxe.Session;
        2: import com.exln.dxe.XMLStore;
        3: import com.exln.dxe.XPath;
        4: import com.exln.dxe.XlnTransaction;
        5: import com.exln.dxe.engine.XlnLocalSessionFactory;
        6: import com.exln.dxe.filesystem.XlnInputStream;
        7:
        8: public class XISQuery {
        9:
        10:   public static void main(String[] args) {
        11:     try {
        12:       Session s = XlnLocalSessionFactory.getSession();
        13:       XlnTransaction txn = s.getTransaction();
        14:       txn.begin(XlnTransaction.TXN_READ);
        15:       XMLStore theStore = s.getXMLStore("Test");
        16:       XPath x = s.createXPath("/movies/movie[title ='Star Wars']");
        17:       int status = x.execute("Test:/dir1/movies.xml");
        18:       XlnInputStream xis = x.exportResults();
        19:       String result = xis.getStringContents("UTF-8");
        20:       System.out.println(result);
        21:       txn.commit();
        22:
        23:     } catch ( Exception e ) {
        24:       e.printStackTrace();
        25:     }
        26:   }
        27: }
    

使用感・コメント

RDBとネイティブXMLデータベースの一台二役で、XMLデータを格納するために適切な方法を選択できるという点が最大のメリットである。ある程度の規模のシステムの場合には、ネイティブXMLデータベースとRDBを併用するのが効果的なことが多いので、コスト面でも魅力である。ライブラリが統合化され、お互いの機能を透過的に参照するビューの機能を提供されているため二種類のシステムの連携に気を使う必要もない。

試用した印象では、さすがにマッピングのアプローチよりもパフォーマンスは高く、ネイティブアプローチの優位性が証明されたといって良いだろう。ただ、格納方式が選択でき、かつそれぞれが異なる原理で動作しており、内部的にも最適化が行われているため、どのような設計にすれば最適なパフォーマンスを得られるのかの判断は難しい。実際、短い試用期間では、ありきたりのインデックス設定以上のことはできず、十分なパフォーマンスを引き出せるところまでの確認には至らなかった。Oracleという冠はついているが、これまでのRDBの利用ノウハウとは全く異なる特性を持つことをよく理解した上で、選定時のプロトタイピングは十分に行う必要があるだろう。

Sonic XIS

米国プログレスソフト社のビジネスユニットであるソニックソフトウェア社により開発、販売されている老舗のネイティブXMLデータベースである。試用したバージョンは3.1.2である。

特徴

オブジェクト指向データベースであるObjectStore(プログレスソフト社)をデータベースのコアにして、XML処理エンジンやAPI、XML関連標準の統合開発環境を搭載した製品である。

DOMデータベース

Sonic XISは、ウェルフォームドXMLを、XML操作の標準インタフェースであるDOM(Document Object Model) オブジェクトの形式で格納する。XMLの処理は、最初にパースしてDOMオブジェクトの構造を構築するという負荷の大きい前処理が必要になるが、この処理の負担を軽減することができる。

メモリデータベース (図※7)

高速化の原理はメモリーへのキャッシュによる。データベースに格納されたDOMオブジェクトへのアクセスが行われると、クライアントプロセスのアドレス空間にキャッシュされる。この機構はキャッシュフォワードアーキテクチャと呼ばれる米国特許技術である。以降のアクセス時は、メモリー上のキャッシュが使用され、他のクライアントプロセスが更新や削除を行わないかぎり、データベースへのアクセスは行われない。更新や削除が行われた場合は、データベースへのアクセスが発生するがDOM全体ではなく変更部分のデータによりキャッシュの更新を行う。

分散XMLキャッシュ

キャッシュフォワードのメカニズムは、管理プロセスと、DOMオブジェクトをキャッシュするXMLキャッシュと呼ばれるプロセスによって実現される。このXMLキャッシュは、同一マシン上で複数配置することとは勿論のこと、異なるマシン上へも配置が可能だ。これにより大量のアクセスを複数のXMLキャッシュに振り分け、負荷分散が可能となる。同一マシン上で分散XMLキャッシュの設定した場合は、クライアントからのアクセスに対して、自動的に振り分け（ルーティング）が行われる。この振り分けを行うプロセスが管理プロセスである。

Java API

大きく2種類に分かれる。1つはDXEクライアントAPIと呼ばれ、XMLキャッシュとの通信にはCORBAを使用している。このAPIでは、トランザクション制御は行えない。もう1つはサーバサイドAPIで、これはXMLキャッシュ上で動作するDXEサーブレット内から使用される場合とXMLキャッシュを使用せずに直接、自分のプロセスへDOMオブジェクトをキャッシュする場合に使用される。DXEサーブレットとは、いわゆるhttpサーブレットではなく、サーブレットAPIに準拠した処理モジュールで、XMLキャッシュプロセスをコンテナとして実行される。サーバサイドAPIは、トランザクション制御を行いたいような場合に利用するが、独自のTCP/IP通信が使用されるため、CORBA通信時のオーバーヘッドがなくなりDXEクライアントAPIより良い性能が得られるというメリットもある。リスト8にサーバAPIを使用した例を示す。

この他に、Javaプログラムから、XMLドキュメントをJavaオブジェクトとして操作可能にするデータバインディングをベースとする手段も提供されている。XMLSchame対応のオープンソースのデータバインディングのライブラリであるCastorをベースにした「DXE Java-XML Data Binding framework」が製品に付属している。これを用いることでDOMの操作を知らなくても、プログラミングが可能になる。

使用感・コメント

メモリスピードでの高速アクセスができ、データへのアクセスごとにDOMパースが不要という点は高く評価できる。ただし、十分なパフォーマンスを得るためにはサーバサイドAPIを使用することが必須である。開発を支援するツールも充実しおり、特に、XML関連標準を統一したビューで開発するためのIDE(統合開発環境)であるStylus Studioは、単品でも販売されており完成度が高い。

大規模データを扱う場合は、慎重な設計が必要である。XMLキャッシュを複数配置することを前提とした設計が必要であり、XMLキャッシュを1つで大規模データを扱うような設計にしてはならない。XISのアーキテクチャは、クライアントのアドレス空間にデータをキャッシュする方式であり、32bitプロセスでは、アドレス空間は4Gバイトとなる。このアドレス空間は、OSやプログラムコード、シェアードライブラリ等でも使用されるので、データキャッシュに使用できるサイズは、4Gバイトより小さくなる。従って、大規模データを扱う場合、XMLキャッシュを複数配置する必要が生じる。このアーキテクチャを良く理解して設計する必要がある。

EsTerra XSS

EsTerra XSS (XML Storage Server)は、国内ベンダーである(株)メディアフュージョンによって開発された、日本発のネイティブXMLデータベースである。試用したバージョンは1.1である。

特徴

EsTerraは、同社により2001年に発売されたYggdrasillの後継機種である。Yggdrasillは、フルオートインデックスによる設計の簡便さと、メモリー上にデータを配置することにより実現される高速検索を特徴とするネイティブXMLデータベースであった。EsTerra XSSは、同製品の市場での経験から、スケーラビリティとトランザクション機能を強化するために、アーキテクチャから大きく見直しされた製品で、異なる特性を持つデータベースである。

Yggdrasillとのアーキテクチャの違い

EsTerraでは、Yggdrasillとは異なり、ハードディスク上のデータを検索するアーキテクチャを採っている。これによって、システムのメモリサイズに依存することなく、テラバイト級のデータベースを扱うことが可能になった。また、Yggdrasillでは、メモリーとディスクの2元管理を行っていたため、複雑なトランザクション制御の必要があったが、EsTerraでは、データの管理をディスク上で一元化するようにしてトランザクション機構の見通しを良くし機能の改善を行った。例えば、更新時にYggdrasillでは、ドキュメント単位での排他制御が行われていたが、EsTerraでは、ノード単位でロック、更新、アクセス制御を行うことができる。

格納方式 (図※8)

XMLデータを格納するためには、まずリポジトリと呼ばれるXMLデータ用にアロケートされた領域を作成する。リポジトリ中にさらにディレクトリと呼ばれる論理的な格納域を設け、その中にXMLデータを構造化し格納する。リポジトリは一つのファイルとして作成され、ブロックと呼ばれる最小の単位ごとにアロケーションされる。ユーザがリポジトリを作成する際にブロック数、ハッシュビットの数を指定することができる。リポジトリはキャッシュすることができ、キャッシュについてもページ数やキャッシュの単位となるセグメントのサイズなどを規定することができる。

インデックスカスタマイズ

EsTerraでは、デフォルトではフルオートインデックス、つまりすべての構造インデックスを作成する。ただしすべての構造にインデックスを作成するとサイズが大きくなる上、更新パフォーマンスも低下するので、選択的にインデックスを作成する手段も提供している。より高度なインデックスのカスタマイズによるチューニングも可能な設計がなされているが、この場合はベンダーのエンジニアの協力が必要である。

RELAX NG

XMLドキュメントを格納する際のバリデーションに、RELAX NGを用いることもできる。RELAX NGは、XML Schemaと同様にXML向けに設計されたスキーマ言語の一つであり、OASISの標準として勧告されている。RELAX NGは、複雑で仕様の見通し悪いと批判されているXML Schemaの欠点を克服するために、機能は絞り込んだシンプルな言語として設計されたスキーマである。

Java API

リスト9に使用例を示す。APIを多言語に対応させたためか、Javaの言語仕様を生かせてはいない。例外クラスは一つも定義されておらず、各メソッド実行の結果はbooleanで戻ってくる。このため、各メソッドの戻り値でエラーの判定をする必要があり、例外処理が不自然になる。なお、リスト中のサンプルでは、コードの可視性が悪くなるので、エラー判定は行っていない。

リスト9：JavaAPI

        1: import jp.co.mediafusion.ClientModule.EsTerraRepository;
        2:
        3: public class EsTerraQuery {
        4:
        5:  public static void main(String[] args) {
        6:    try {
        7:       boolean ret;
        8:       EsTerraRepository Server = new EsTerraRepository("localhost",8290);
        9:       ret = Server.Login("admin","admin","C:EsTerraDBrepository");
        10:       ret = Server.OpenTransaction("");
        11:       ret = Server.OpenDirectory("dir1");
        12:       ret = Server.SelectDocument("movies.xml");
        13:       ret = Server.QueryDocument("/movies/movie[title ='Star Wars']");
        14:       long count = Server.Count();
        15:       for ( int ii = 0;ii< count; ii++ ){
        16:         System.out.println(Server.GetXml(false));
        17:         ret = Server.Next();
        18:       }
        19:       ret = Server.CloseTransaction();
        20:       ret = Server.Logout();
        21:     } catch (Exception e){
        22:       e.printStackTrace();
        23:     }
        24:   }
        25: }
    

使用感・コメント

日本で設計から開発まで行われている製品であるという点は大きなメリットである。最初からマルチバイト文字への対応が最初から考えられている点は安心できる。グローバル企業の場合、日本語への対応がどうしても遅れがちな傾向がある。

試用版では、使用期限以外に容量制限が設定されており、10Mバイトを超えるデータベースを作成することができなかった。そのため、性能についてはコメントできない。いずれにしても登場して間がないため、市場での事例がまだ多くないことを勘案して開発を進めるのが良い。ベンダーと密に連携し、基本機能についてもプロトタイピングの段階で十分な検証をしておきたい。

NeoCore XMS

NeoCore XMSは、米国NCホールディングスによって開発された、新興のネイティブXMLデータベースである。国内では三井物産(株)が販売している。試用したバージョンは2.9である。

特徴

USP(米国特許)取得技術である、DPP (Digital Pattern Processing)と呼ばれる独自のインデックス検索技術を用いたネイティブXMLデータベースである

フルオートインデックス (図※9)

NeoCore XMSではXMLデータを読み込むと、インデックスファイルを中心とする複数のファイルに分解されて格納される。データベースは、構造と値インデックスを格納するインデックスファイル、XML構造を復元するためのマップファイル、値を管理する辞書ファイル、重複情報を扱う重複ファイルといった、ファイルから構成される。インデックスはすべての要素について定義され、インデックスの作成を制御するための手段はない。

各ファイルはデータベースの作成時に、領域のサイズを決めるパラメーターを設定して用意される。データの登録によって、用意された領域が消費されてゆくが、全体の大きさは変わらない。データの登録によって格納する領域が一杯になると、領域を拡大するためのコマンドを実行する必要がある。

DPP

インデックスの検索のために、DPPと呼ばれる技術が用いられる。DPPはそれ自体はXMLと関係のない、連想メモリーを用いたパターン認識技術のひとつである。与えられたパターンと一致するパターンを高速に取り出すことができる。ベンダーによれば、指定されたパターンを取り出すために要する時間は、平均で1.5メモリーサイクルであり、この値はデータのサイズに依存しないとのことである。つまり、どんなに沢山のパターンがあったとしてもほぼ同じ(極めて短い)時間で取り出すことができるのだ。

DPPの連想メモリーで探索の対象とするパターンは、64ビットの固定長のパターンで、アイコンと呼ばれる。どんな長さのデータもこのアイコンに変換することができる。異なるデータが同一のアイコンに変換される可能性は、18×1018分の1(64ビット)になる。このDPP技術を用いることによって高速検索可能でかつコンパクトなインデックスメカニズムが実現されている。

具体的には、XMLデータの階層構造は、その末端に位置する各データと、そのデータまでの絶対パス（要素の階層構造）を組み合わせることで、「パス＋データ」の列として各データを表現するパス形式に変換することができる。このうちのパスの文字列と、パス＋データの文字列のそれぞれがDPPのアイコンに変換される。検索式から同様にして生成されるアイコンと、インデックスのアイコンのマッチングによって、インデックス検索が行われる。

Java API

通信にはHTTPを使用してDBへアクセスする。リスト10に、使用例を示す。8行目から10行目の各メソッドのリターン値にはサーバからの応答メッセージが返され、検索時（9行目）には検索結果が返される。データベースには異なる構造を持ったXMLデータを格納することができ、これらは共通のルート要素としてを持つひとつの大きな階層構造として扱われる。このため、9行目の検索式のXPathはからはじまっている。

リスト10：JavaAPI

        1: import com.neocore.httpclient.SessionManagedNeoConnection;
        2: public class NeoCoreQuery {
        3:
        4:   public static void main(String[] args) {
        5:     try {
        6:       SessionManagedNeoConnection con = new  SessionManagedNeoConnection("localhost", 7700);
        7:       String sid = con.login("Administrator", "admin");
        8:       System.out.println(con.startTransaction());
        9:       System.out.println(con.queryXML("/ND/movies/movie[title ='Star Wars']"));
        10:       System.out.println(con.commitTransaction());
        11:     } catch (Exception e ) {
        12:       e.printStackTrace();
        13:     }
        14:   }
        15: }
    

使用感・コメント

インデックスの設計が不要で、ウェルフォームドXMLを高速に検索できるという特性は魅力である。データ投入には苦労したが、一旦投入できてしまえば安定した検索性能を示す。本誌7月号にて検索性能が1GB規模までリニアであることを紹介したが、さらにこの特性は少なくとも50GBまで変わらないことがわかっている。運用中に格納されているXMLの構造と異なる構造をもつXMLが登録されても自動的にインデックスが作成されるので、利用者は、どの項目にインデックスを設定すれがよいかは考える必要はなく、インデックスが使用されるような検索を考えるだけで済む。

強力なエンジン単体の提供という印象であり、開発ツールなどの整備がまだ十分ではない。データ投入についても、100MBを超えたころから設定が難しくなった。データ投入の際に、ストレージを構成する複数のファイルのどれかが一杯になるため、試行錯誤をしながらファイルサイズを決めてゆく必要がある。データの構造によってどのファイルがあふれるのかが予測できないため、適切な設定を行うのが難しくなるのだ。次のバージョンでは自動拡張機能によってこの問題は解消されるとのことなので期待したい。

eXist

eXistはPure Javaで作られたオープンソースのネイティブXMLデータベースである。試用したバージョンは0.92である

特徴

フルオートインデックス機能を持つウェルフォームドXML対応のオープンソースのデータベースである。

フルオートインデックス

eXistでは階層構造のコレクションを作成して、コレクション内に複数の異なる構造を持つウェルフォームドXMLデータを格納する。データを投入するとデフォルトで自動的に値インデックスと構造インデックスを作成する。インデックスはコレクションごとに行なわれるため、１つのコレクションが大きくなりすぎたり、XMLの構造が異なるものを同じコレクションに含めたりすると性能が劣化する性質をもつ。

大量のデータを投入するにはコレクションを分けたり、VMの起動パラメーターやデータベースのプロパティを調整したりする必要がある。チューニングするにはフルオートインデックスから除外する要素を指定する。管理コンソールでインデックスのバッファの使用状況やヒット率を参照して、値の調整の参考にすることができる。

3種類の実行時アーキテクチャ

eXistはクライアント/サーバ、APデプロイ、スタンドアローンの3種類の実行時アーキテクチャで動作させることができる。デフォルトの動作であるクライアント/サーバモデルは、サーバを起動して、クライアントからAPIを通してアクセスする方法である。サーバは同梱されているJettyというサーブレットエンジンの上で動作する。APデプロイモデルは、warファイルをデプロイすることでアプリケーションサーバ上の１つのアプリケーションとして動作させる方法である。アプリケーションサーバとしてApache Cocoon上で動作させることもできる。スタンドアローンモデルは、クライアントアプリケーションの中に埋め込んで同じVM上で動作させる方法である。

XPathの拡張

検索方式としてXPathに対応しているが、インデックスを有効に利用できる操作や関数を追加して高速に検索ができるようにしている。拡張された操作ではコレクションをまたがる検索や正規表現にも対応しており、XPath準拠とはいうものの、拡張されたものを使った場合にのみ高い性能が出るので使い方には注意が必要である。

Java API

eXistにはXML:DB APIとXML-RPCおよびSOAP APIの3種類のAPIが用意されており、このうちJava APIはXML:DB APIをベースにしたものである。XML:DB APIに認証認可機能、ネストしたクエリー、結果のソートなどの機能が追加されている。リスト11に検索する例を示す。

リスト11：JavaAPI

        1:import org.xmldb.api.base.*;
        2:import org.xmldb.api.modules.*;
        3:import org.xmldb.api.*;
        4:
        5: public class eXistQuery {
        6:
        7:   public static void main(String[] args) {
        8:     try {
        9:       String driver = "exist.xmldb.DatabaseImpl";
        10:       Class cl = Class.forName(driver);
        11:       Database database = (Database)cl.newInstance();
        12:       DatabaseManager.registerDatabase(database);
        13:
        14:       Collection col =
        15:         DatabaseManager.getCollection("xmldb:exist://localhost:8080/exist/xmlrpc/db/data");
        16:       XPathQueryService service =
        17:         (XPathQueryService) col.getService("XPathQueryService", "1.0");
        18:       service.setProperty("pretty", "true");
        19:       service.setProperty( "encoding", "UTF-8" );
        20:
        21:       ResourceSet rs = service.query("/movies/movie[title='Star Wars']");
        22:       ResourceIterator i = rs.getIterator();
        23:       while(i.hasMoreResources()) {
        24:         Resource r = i.nextResource();
        25:         System.out.println((String)r.getContent());
        26:       }
        27:       rs.close();
        28:       col.close();
        29:     } catch(Exception e) {
        30:       e.printStackTrace() ;
        31:     }
        32:   }
        33: }
    

使用感・コメント

インストールは簡単で、構成もシンプルで分かりやすい。WindowsのメニューやGUIツール、Webブラウザでの管理コンソールなどが用意され、操作性も悪くないので初心者にも使いやすい。XMLデータベースがどんなものか、触ってみたいという場合にはお勧めできる。Apacheなど他のオープンソースのプロジェクトのライブラリやサーバとの相性がよい。また、XML-RPC、XML:DB API、WebDAVなどの標準も積極的に取り入れている点も評価できる。

オープンソースということで日本語の対応が気になるところだが、Shift_JISのXMLの登録には問題がなかった。XPathにおいては、値に日本語が含まれる場合は問題ないが、ノード名に日本語が含まれる場合は例外が発生する。現在のバージョンではノード名は英語名で定義したほうがよい。現在、まだベータバージョンであり、オープンソースのため十分なサポートが期待できないという点には注意が必要である。また、大規模なデータベースを構築する際には様々なチューニングが必要になりそうだ。普通の企業や機関が実際に利用する信頼性の高いシステムの構築には、商用のデータベースの利用をお勧めしたい。

チューニングのヒント

ネイティブXMLデータベースの検索性能を向上させる際に基本となる手法をいくつか紹介する

（1）適切なXMLドキュメント単位

製品毎に適切なXMLドキュメントの単位は異なる。これまで例として用いてきたの構造は、ルート要素はで、その子要素が複数表れるような構造になっている。全ての製品で、このドキュメント構造をそのまま格納することは可能である。しかし、TaminoやOracle XML DBの場合は、ルート要素の子要素単位に分割した、2つのデータとして扱うほうがよい。検索や更新の単位としてよりきめ細かく操作できるからである。NeoCore XMSの場合にはどちらの構造でも内部的にはほとんど変わらない。

（2）インデックスの使用

インデックスを使用するにあたって注意が必要なことは、インデックスが効く検索式を記述しなければ意味がないという点である。例えば以下のような階層構造の位置を特定しないXPath式の場合、構造インデックスは効かない。指定位置以下のノードを走査することになり構造インデックスが使用されないのだ。

また、必ずしも、検索項目に対し全てインデックスを設定すれば速くなるとは限らない。各製品の検索式を解釈実行するクエリプロセッサの最適化ルールに依存する。したがって、導入にあたっては、実際に行われそうな検索パターン（and条件やor条件、大小比較検索）を複数用意し、インデックスの設定を変えてみて、評価をしておくことが望ましい。検索にインデックスが使用されるかどうかを確認できる製品もあるので、それを利用しながらインデックスの設計を行うとよいだろう。

（3）結果セットのサイズを制御する

検索結果がDOMオブジェクトになるようなAPIを使用した場合、検索結果のサイズを小さくすることは効果が大きい。サーバはクライアントへ検索結果を、DOMオブジェクト（バイナリデータ）として送るわけではなく、テキストデータで送信し、クライアントで受信したテキストデータをDOMオブジェクトへパースするからだ。

例えば、特定の俳優の出演映画を検索したい場合、/movies/movie[cast/actor/name="Harrison Ford"]というXPath式を使うと映画タイトルだけでなく、映画情報のすべてを返す。代わりに/movies/movie[cast/actor/name="Harrison Ford"]/titleとすればtitle要素だけを返すのでパース対象がずっと小さくなる。また、結果セットを小さくできるようなXMLのドキュメント構造にするという検討も必要だ。例えば、一覧表示に使用する構造と詳細情報表示に使用する構造を持つようにするなどである。

パフォーマンスの目安

チューニングの目標となるパフォーマンスはどのように考えればよいのだろうか。パフォーマンスはデータの構造や検索方法に大きく依存するので客観的な目標を与えることは難しい。本誌8月号で、NeoCoreのパフォーマンス測定に、XMarkというベンチマークサイトのデータを利用したが、あくまでそこで想定したデータ構造での結果に過ぎない。XQueryもXPathも書き方次第でパフォーマンスは大きく変わる。

精密な議論はともかくおよその感覚が知りたいという方のために、以下におおまかな目安を示しておく。検索によってXMLデータを取得する単位としては、小さいものでも本稿で使った程度のXMLデータになり、500バイト程度のテキストデータとなる。ごく普通のPC環境で、この程度のデータ1件の検索を、数10ミリ秒で行えるというあたりが、現在のネイティブXMLデータベースの目標性能と考えればよいだろう。もちろんマシンスペック次第ではさらに性能を高めることも可能である。

おわりに

本稿では、ネイティブXMLデータベースの普及を妨げる最大の要因として、利用ノウハウの流通がなされていないことを指摘し、その解決の一助となる情報の提供を目指した。

すべてのベンダーが該当するわけではもちろんないが、一部のベンダーの情報提供の仕方は、こうしたノウハウの流通を妨げていることを指摘しておきたい。一見して日本人のエンジニアがチェックしていないとわかる、直訳で意味不明のマニュアルは、現場に多大な迷惑をかけていることを認識されたい。デモは記述通りに操作すれば動く状態にしてから提供して欲しいものだ。試用版に容量制限を加えるのもやめて頂きたい。小さなサイズのXMLデータしか投入することができなければベンチマークをしても意味がない。

今、再びネイティブXMLデータベースに注目が集まり、XMLを用いた新しいソリューションが生まれる気運が高まっている。前回の轍を踏まないよう、ベンダーとユーザが共に協力し、利用のためのノウハウを囲い込むことなく積極的に流通させることで、この分野全体の発展・拡大を進めてゆけることを期待したい。