［DB Interview］
第2世代XMLデータベース誕生秘話（後編）

検索パフォーマンスは一日にして成らず

株式会社ピーデー
川俣 晶
2005/9/14

XMLデータベースの世界に第2世代と呼ぶにふさわしい純国産製品が登場した。東芝ソリューションが2005年4月に投入した「TX1」は、ネイティブあるいはRDBを問わずXMLデータベースの検索性能で世界最高水準を目指したという。開発の過程で直面したさまざまな難問をどう乗り越えていったか、開発担当者にインタビューを行った。（編集部）

■OracleのXML機能に目を見張る

　前編では、第2世代XMLデータベース「TX1」がどのようなユーザーのニーズから誕生し、なぜ「世界一の性能」を目指すことになったかを紹介した。後編では、検索性能を向上させるために行った実装作業について、東芝ソリューション プラットフォームソリューション事業部 ソフトウェア開発部 参事 松井浩二氏へのインタビューをお届けする。

―― さて、いよいよ世界一の検索性能を目指した実装作業が始まるわけですが、他社の製品で最も手ごわいと考えていたのは何だったのでしょうか。

松井　TX1で想定していた新聞や金融の文書管理システムで実際に使われる複雑なクエリで試した場合 、データ量が多くなると、ほとんどのXMLネイティブ・データベースでは性能の低下やメモリ使用量の増加のため、システムの要求に届かなかったですね。実は最も性能が良かったのはOracleのXML機能でした。スキーマ定義などデータを格納するのに手間はかかるのですが、検索は非常に速かったです。TX1の開発で最も意識すべき製品はOracleだと認識しました。

―― Oracleに代表されるRDBのXML機能と真っ向勝負するのか、それともすみ分けを狙うのか、どちらの戦略を選択したのでしょうか。

松井　TX1の開発では、RDBにできないXMLデータベースの領域がどれくらいあり、そこでどれだけ優位に立てるかがポイントでした。例えば新聞や金融の業務では、もともと大量の文書があって、そこに後からタグを付けたものをデータとして扱うことになります。こういう非構造化データはRDBではCLOBとして格納するしかないので、ここで差異化できると考えました。おそらく、RDBはCLOBで格納するしかないXMLデータの部分取り出しや部分更新に対する性能を向上させることは難しいだろうという読みもありました。RDBとTX1のターゲットは基本的にぶつからない、つまりすみ分けは可能だと思いました。

―― 構造化できる数値系XMLデータでは、Oracleなどと戦うつもりはなかったということですね。

松井　すべての面でRDBに匹敵する性能は目標ではありますが……。ビジネス向けアプリケーションにおいて、定型検索で済むXMLデータならば、RDBで少し頑張れば間に合ってしまうのです。おそらく他社のXMLネイティブ・データベースが主戦場にしているのはこの分野で、RDBで扱えないことはないけれど、スキーマを切る手間を考えればXMLデータベースの方がいいでしょう、ということだろうと思いますね。TX1は完全にRDBが手出しできないところ、つまり非構造化データに対して複雑であいまいなクエリを必要としている業務分野を狙っているのです。

---

　第1世代XMLデータベースの時代にRDBも含めて他社製品の性能を評価した結果、最も高性能なのはOracleだった点に注目したい。スキーマ定義などの手間をかければ、OracleのXML機能の性能は高く、XMLネイティブ・データベースの競合相手になり得るのである。RDBでカバーできる範囲のXMLデータで性能競争をして、仮にTX1とRDBが互角になったとしても、長い運用実績のあるRDBが選ばれるだろう。そこでTX1は、RDBのXML機能では対応できない領域で勝負に出たわけだ。この選択は、第2世代XMLデータベースを特徴付ける点だろう。

---

■3回の作り直し、そして劇的なパフォーマンス改善

―― RDBが手出しできない領域でのパフォーマンスを追求した成果として、特許文献の検索を行うベンチマークを公表されていますね（＠IT広告記事『テラバイトOK！ 大容量データでも高速検索を可能にしたXMLデータベース「TX1」』を参照）。

松井　これはXMLの柔軟性、つまり検索でのあいまい性の検索性能を評価したもので、実際に公開されている特許公報の約8年分を対象にしています。XMLの文書数で約300万件（約100Gbytes）、タグ数は数億の単位になります。これであいまい検索を行うと、数千万件と数千万件をANDして、数万件に絞り込んでいくといった計算量になります。このように、あいまい性を相手にすると計算量が膨大になり、パフォーマンスを落とす原因になるわけです。当初の目標である「あいまい性を損なわず高速に」は非常に難しいことに、開発を始めてから気付きました。現在のTX1であれば、ほぼ1秒で検索が終わっていますが、最初の試作バージョンでは1時間もかかっていました。2番目の試作バージョンでも1分くらいです。製品としてリリースしたのは3回目のインプリメンテーションで、ようやく1秒ほどに縮めることに成功しました。バージョンを上げるごとにパフォーマンスは10〜100倍に上がりました。

―― 劇的なパフォーマンス向上には、TX1の目玉機能であるスキーマアナライザ注1およびクエリオプティマイザ注2が貢献したのですね。

注1　スキーマアナライザ
XMLのツリー構造に着目した「構造索引」と、XMLの要素として格納されている語彙（ごい）に着目した「語彙索引」をデータ格納時に自動で作成する技術。

注2　クエリオプティマイザ
検索にかかるコストを判断し、同一の結果を得る問い合わせの実行計画でも、より少ないコストで済む実行計画を自動的に選択する技術。

松井　はい、「スキーマアナライザ」「クエリオプティマイザ」はTX1のアーキテクチャの中で最も重要な部分ですから。しかし、アーキテクチャの良さは構築技術に支えられて初めて現実のものとなります。これらの主要な機能は初期バージョンから実装していました。XMLデータベースは一般的に構造データベースとよばれる分野で学術的に研究されていて、構造索引や値索引を作るのは当時から常識でしたから。基本的なコンポーネントは初期バージョンから変わっていません。パフォーマンス向上は地道なチューニングを積み重ねた結果です。作っては駄目、作っては駄目、これの繰り返しで、最後の作り込みは非常に泥臭い作業でした。

―― 具体的にどんな作業だったのですか。

松井　どんなに速いRAIDディスクでも1秒間に100Mbytesしか転送できないので、1000万件のソート処理が入れば1秒かかってしまいます。AND処理でマージするにはソートが基本になるので、1億件のデータを相手にAND処理を含む検索を1秒以内で終わらせるには、ソートなどはしていられないのです。クエリのアナライザでやっている最適化というのは、いかに無駄な処理をやらないかに尽きます。例えば、事前にソート済みの状態で登録しておき、ソートの計算せずに済むようにしておく、あるクエリにはこのソートは必要ないから削ってしまおう、など1つずつ問題点をヒューリスティックに解決していきました。

　計算量を減らすのはコンピュータの一般的な理論です。インデックスなどの情報量があれば計算量は減り、逆に情報を持たずにすべて計算でやろうとすると遅くなるのです。インデックスもふんだんに使っていいわけではなく、適当な量だけ持つことが重要でした。チューニングを進めていく中で、ここの1bitはいらないから削ろう、メモリを調べてみたら2bytes空いているので詰めよう、といった作業です。対象とするデータ数が億単位になると、こういった小さい単位の効率化は絶対に必要になります。2bytesであっても億単位のデータなら数Mbytesも損しますから。

　そのほかにも、あらゆるデータベースで共通のことですが、ディスクI/Oをシーケンシャルにすること。読み出し速度はランダムアクセスにすると1Mbytes/秒しか出ませんが（RAIDでも5Mbytes/秒程度）、シーケンシャルアクセスにすると100Mbytes/秒くらい出ます。いかにハードディスクを遊ばせずに性能を出すかを極めました。

―― チューニング以外で、実装時に意識された点はありますか。

松井　設計をやり直したときには、その都度過去のコードは捨てて新たに書き直しています。一度動いたコードは変えたくないのが本音ですが、そうしていると先に進めないので。古いコードに新しいコードを加えていく“増築”を重ねていくと、その部分だけではよくても、全体を見たときに効率が悪くなっていることがよくあります。これは直接性能に関係しないこともありますが、拡張性などで差が出てきます。TX1はカスタマイズ可能な作りのエンジンになっているので、製品リリース後、予想外の使われ方をしてチューニングを加えることになっても大丈夫です。実際に開発中には、あるクエリを10倍高速化するのが翌日にはできているといったこともありました。ユーザーからこういう使い方だと検索が遅いといったフィードバックがあっても、短期間で性能を上げられる自信はありますね。

---

　よくある誤解として、一度書いたソースコードは再利用し、同じものを書き直すなという主張がある。あるいは、CPUが速くなったのだから、ソースコードが難解になる高速化テクニックなど使うな、という主張も同様の誤解のうちだろう。これらの主張は、システムに対して要求されるデータ量と複雑さの拡大を見落とすことによってのみ成立する。現実問題として、まだまだ多くのプログラムが高速化のための工夫、何度も作り直す試行錯誤を要求されている。プログラムは地道な改善によって、2倍や3倍ではなく、10倍、100倍という単位で高速化できるのである。

---

■これからXMLデータベースはどうなる

―― 製品リリース後、ユーザーからの反応はどうですか。

松井　XMLのメリットを理解して、XMLデータベースを使ったビジネス・アプリケーションを考えているユーザーは予想以上に多いですね。システム統合やデータ活用といった総合的なシステムにXMLを取り込もうという流れがあるようです。XMLデータベースが普及していく突破口はコンテンツ管理だと思いますが、それは従来のテキストやイメージファイルのコンテンツ管理とは違って、データウェアハウス的に中身を活用できるものです。実際にTX1をユーザーに説明したところ、「これはテキスト版のデータウェアハウスですね」といわれました。RDBのデータからデータウェアハウスを作るように、構造化されていないデータをデータウェアハウス的に使うにはXMLデータベースが適しているでしょう。コンテンツの中身を分析して、必要なデータだけ抽出できますから。

―― データベース・エンジニアには、XMLに抵抗を覚える人も少なくないようです。XMLデータベースに興味はあっても、使ってみるまでには至らない。そんなエンジニアの教育も今後は必要ではないでしょうか。

松井　XMLデータベースを覚えるに当たって、クエリはそれほど障害にならないと感じています。RDBでシステムを組める人を前提に、プログラマ向けに1日のXMLデータベース教育プログラムを実施すると、それだけでクエリに関する問い合わせはなくなります。XQueryはSQLと対比させながら説明すると、すんなり理解してもらえますね。XQueryはJOINなどSQLと同じ機能を持っているので、SQLを知っている技術者がXQueryを覚えるのは難しくありません。文法はかなり違うので最初は取っつきにくいですが、コツさえ覚えれば後は早いものです。それよりXMLデータベースに合った構造、例えばマスターを持った方がいいのか、あるいは同じ項目が複数の個所に散らばっているとまずいなど、データ設計に関することは難易度が高いです。これは経験を積んでいかないと身に付かない部分ですね。

---

　TX1と並んで第2世代XMLデータベースといわれる「NeoCore XMS」は、「XPriori」という無償版を公開している。TX1にも無料で使用できる評価版が提供されることを望みたい。無料の評価版の存在が重要であると考えるのは、第2世代のXMLデータベースの価格にある。ちょっと買って試してみよう……とはいかないほどに高価なのだ。製品は多く売れれば値下げできるのが1つの常識である。また、潜在ニーズがあれば値下げをしてより多く売ろうとする、というのも1つのやり方である。ぜひとも無料の評価版を公開して、それを多くの技術者が試用し、これなら使えると発注したり、この値段まで下がれば採用できるとアピールすることは、おそらく利用者とメーカー側の双方にとって好ましい方向へと状況を推し進めるに違いない。

---

◇

　データベースの世界は、長らくRDBさえあればよしとする状況が続いてきた。しかし、企業のシステム化は従来の定型データにとどまらず、構造化されにくい多様なデータまでも業務に活用する方向に動きだしている。今回取り上げたTX1の目指す文書管理システム、あるいはスキーマ変更の頻発するワークフロー管理、異機種間データ統合など、XMLデータベースの活用が期待される分野は広がってきた。このような時流の中で、純国産の新しいXMLデータベースという新たな選択肢が1つ増えたことは歓迎すべきことだろう。（完）

＠IT関連記事
・	テラバイト級のデータを高速検索、東芝のXMLDB（News記事）
・	テラバイトOK！ 大容量データでも高速検索を可能にしたXMLデータベース「TX1」 （PR記事）

Index
［DB Interview］ 第2世代XMLデータベース誕生秘話
	前編 「世界一の性能」を獲得する、それがミッションだった
	後編 検索パフォーマンスは一日にして成らず

［DB Interview］

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）