目次


DB2の全文検索製品

Comments

謝辞

貴重な検討に何度も協力してくれたエクステンダー開発チームに感謝いたします。特に、Annette OpalkaとMichael Haideの両氏には、この白書の草稿をレビューし、多くの重要な加筆修正点を指摘して頂きました。

1.はじめに

今日、特にe-businessやコンテンツ・マネージメントの分野において、多くのアプリケーションが全文検索機能を必要としています。本格的にビジネスを行っているWebサイトで、利用者が関心の対象をすばやく見つけられるようにするテキスト検索機能を用意していないところはほとんどありません。一般に、テキスト・データ自体(たとえば商品説明)、あるいは少なくとも、書籍の著者や要約などのテキスト文書に関するメタデータはRDBMSに格納されています。たとえば、WebSphere Commerce SuiteアプリケーションのPRODUCT表に格納された数千件の商品説明やBOOK表に格納された数百万件の書籍の要約を対象に全文検索を行うことができます。あるいは、ある価格以下の製品のみを検索したり、近くの書店で購入できる書籍を検索したりする場合のように、データベースに格納された他のデータに関する条件と組み合わせて全文検索を行うこともできます。この白書では、DB2の全文検索製品であるテキスト・エクステンダー、ネット・サーチ・エクステンダー、およびテキスト情報エクステンダーがこうした用途にどのように役に立つのか、またどのような場合にどのエクステンダーを使用すべきかについて説明します。

第2章では、エクステンダーのアーキテクチャーについて解説し、DB2をベースに構築されたテキスト検索ソリューションと比較した場合、およびSQLの「like」関数を使用する場合と比較した場合の各アーキテクチャー上の利点を説明します。また、アーキテクチャーに起因する各ソリューションの長所と短所についても解説します。第3章では、アプリケーションに最適なエクステンダーを選ぶ際に役立つ情報として、製品の歴史と戦略について説明し、どのような場合にどのエクステンダーを使用すべきかについて解説します。

以下に要約を示します。「標準的な」アプリケーションにはすべてテキスト情報エクステンダーを使用します。このエクステンダーは、DB2との統合という点で最も優れており、設計の柔軟性の点でも申し分ありません。ただし、最初のリリースのテキスト情報エクステンダーにはいくつかの制限があります。具体的には、一部のプラットフォームに対応していない点と、表では単一列を主キーとする必要がある点が挙げられます。また、DB2 EEEでは利用できません。

ネット・サーチ・エクステンダーは、ハイエンドのe-businessシナリオに対処するためのもので、非常に優れたパフォーマンスとスケーラビリティーを備えていますが、これに合わせてアプリケーションを設計できなければなりません。このエクステンダーは、照会がテキスト検索のみである(パラメトリック・データに関する条件と組み合わせない)場合、検索結果が数件でよい場合、およびデータをメイン・メモリーに格納する余裕がある場合に最適です。これら2つのエクステンダーのどちらのほうが適しているのかについてあらかじめ判断するのが難しいこともありますが、もちろん同じ表に対して同時に両方を使用することも可能です。いずれにせよ、現在の製品計画では、これら2つのエクステンダーの機能は1つの製品に統合される予定です。

テキスト・エクステンダーは、全文検索に対して高度な言語サポートが必要な場合に使用します。テキスト・エクステンダーで使用するテキスト検索エンジンは、テキスト情報エクステンダーでもネット・サーチ・エクステンダーでも利用できない言語をサポートしています。特に一部のヨーロッパ言語の場合に言えることですが、高品質の検索結果を保証するには言語サポートが重要です。

現在の計画では、次のバージョンのテキスト情報エクステンダーには、テキスト・エクステンダーを完全に置き換えることができるように機能と対応プラットフォームが追加される予定です。

第4章では、検索機能に焦点を当てながら、テキスト・エクステンダーの機能についてもう少し詳しく説明し、さらにパフォーマンスに関するいくつかのヒントも示します。同様に、第5章ではネット・サーチ・エクステンダー、第6章ではテキスト情報エクステンダーを専ら扱います。巻末には、これらの製品に関する追加情報を入手したい場合に役立つ連絡先およびリンクの一覧が記載されています。

2.アーキテクチャー

この章では、テキスト検索とDB2の表に格納されたパラメトリック・データを対象とする検索を結合する、以下の5種類のアーキテクチャーを比較します。

  • DB2とDB2外部テキスト検索エンジンをベースに構築されたソリューション
  • SQLの「like」関数
  • テキスト・エクステンダー
  • ネット・サーチ・エクステンダー
  • テキスト情報エクステンダー

アプローチの比較基準は以下のとおりです。

  • パフォーマンスおよびスケーラビリティー特性
  • 機能と検索結果の品質
  • 拡張性や統合APIといったその他の側面

上記の基準の重要性は、たとえば以下のようにアプリケーションのシナリオによって異なります。

  • 1日当たり数千万ヒットのアクセスがあり、数百万のテキスト検索可能オブジェクトがデータベースに格納されているWebサイトでは、たとえば1万種類の商品の説明と価格を対象とする検索しか行わない小規模のWebサイトと比べて、パフォーマンスやスケーラビリティーの問題による影響が大きくなります。
  • 特許調査の場合、多少の応答時間の遅れは問題となりませんが、すべての関連文書を漏れなく検索できることが極めて重要になります。それとは対照的に、特定の話題に関する新聞記事を探そうとしている場合は、検索の品質はそれほど重要ではないかもしれません。
  • 商品データベースに対する複合検索を実現しようとする場合、テキスト検索とパラメトリック検索が同じアクセス制御メカニズムを使用しているかどうかについては気にしないかもしれません。実際にその必要はまったくありませんが、一部の情報を機密扱いにする場合や、特定の情報の検索料金を利用者に課金する場合は、単一アクセス制御または統合アクセス制御の概念を取り入れることが非常に重要になる可能性があります。

2.1 DB2とDB2外部テキスト検索エンジンをベースに構築された ソリューション

以下の図は、テキスト・データとパラメトリック・データを対象とする複合検索を実現するために、DB2とテキスト検索エンジンの上にレイヤーを実装するシステムのアーキテクチャーを示しています。ここには検索部のみ、つまり、DB2に格納されたパラメトリック・データに対する検索と、テキスト検索エンジンによって管理されるテキスト索引に対する検索が含まれる照会を評価する際にどのコンポーネントが関係するかが示してあります。このようなアプローチは現在、IBMのContent ManagerやEnterprise Information Portalなどの製品に実装されています。

 
DB2とテキスト検索エンジンの上にレイヤーを実装するシステムのアーキテクチャー
DB2とテキスト検索エンジンの上にレイヤーを実装するシステムのアーキテクチャー

アプリケーション・サーバー(通常は中間層に置かれます)は、複合照会を処理するコンポーネントの上に構築されます。このコンポーネントは、検索時に以下の処理を実行します。

  • DB2に対して照会を発行し、結果をアプリケーション・サーバーに戻す。
  • テキスト検索エンジンに対して照会を発行し、結果をアプリケーション・サーバーに戻す。
  • 結果を結合する。

このようなアプローチの利点と目的は、各自のテキスト検索機能要件を満たした任意の情報検索システムを使用できることにあります。

このソリューションの主な欠点は、テキスト検索結果とDB2検索結果を複合照会ハンドラーに移動し、そこでデータを結合するといった処理をなくすことができないため、パフォーマンスとスケーラビリティーが制限されることです。たとえば、エンド・ユーザーが、100ドル未満(DB2に対する照会)で、かつ書籍のテーマが「リレーショナル・データベース」テクノロジー(TSEに対する照会)である10冊の書籍を調べたかったとします。その場合、10万件のDB2照会結果と1,000件のテキスト照会結果を複合照会ハンドラーに移動する必要があり、さらに10冊の書籍を返すためにこれらのセットを結合しなければなりません。

このタイプのアプリケーションでは、アプリケーションへの結果の移動をチャンク単位で行うことによって問題を解決しようとすることもありますが、あまり効果はありません。なぜなら、たとえば最初のテキスト検索結果のチャンクに価格条件にマッチする結果が含まれていない場合や、最初のDB2検索結果のチャンクにリレーショナル・データベースに関する書籍が含まれていない場合など、最初のチャンクに必要な結果が含まれていない可能性があるからです。

このような複合照会ハンドラーの上にアプリケーションを構築しようとした場合、その他にも以下のような問題があります。

  • 一般に、開発者は、従来どおりSQL APIとTSEのAPIを扱うか、あるいは「統合API」があったとしても、SQLの機能やSQLの広範なプログラミング環境サポートを利用できない。
  • 一般に統合アクセス制御を利用することができない。
  • 通常、DB2の内容とテキスト索引との同期が問題となる。
  • 通常、(前述の問題により)開発コストや維持管理コストが高くなる。

2.2 SQLの「like」関数

DB2をはじめとするすべてのリレーショナル・データベース・システムは、たとえば以下に示すように、特定のパターンを含むストリングを検索する組み込み述部関数「like」を備えています。

select ISBN, PRICE 
from BOOKS
where ABSTRACT LIKE '%mouse%'

これは「マウス」に関する書籍を検索するためのもので、要約のどこかにストリング「mouse」を含むすべての書籍を検索します。DB2は、列「ABSTRACT」にある既存のBツリー索引を利用してこの列のLIKE述部を評価しようとしますが、この場合はストリングの先頭にワイルドカードがあるため、そうすることはできません。一般に、Bツリーはテキスト検索条件の評価に適した索引構造ではありません。この場合、DB2は、要約にストリング「mouse」を含む書籍を見つけるために、実行時におそらく数百万件の書籍要約を走査しなければならないことになります。

DB2のLIKE述部関数によって返されるテキスト検索結果は、テキスト検索の品質に関して現在のユーザーの期待にそいません。上記の照会では、ユーザーの観点から見て適切な書籍がすべて見つかるわけではありません。たとえば、単語「Mouse」を含む要約は見つかりません(LIKE述部関数は大文字小文字を区別するため)。「mouse」の代わりに単語「mice」を使用すると、どちらも見つからないことになります(言語サポートがないため)。逆に、単語「mouse-grey」を含む要約は、関心の対象ではないにもかかわらず条件を満たすことになります(LIKE述部関数はワード境界を無視するため)。あらゆる種類の齧歯類動物に関心があることを簡単に式で表す手段はなく(シソーラスがサポートされないため)、また「mouse」が「house」と同じ文中に含まれることを式で表すこともできません(近接検索もブール検索もサポートされないため)。

したがって、テキスト検索機能を本格的に実現しようとする場合、パフォーマンスの点でも品質の点でも現在のテキスト検索の標準を満たしていないことから、DB2のLIKE述部関数を使用することはできません。

2.3 テキスト・エクステンダーのアーキテクチャー

以下の図は、たとえばリレーショナル・データベース・システムに関する20ドル未満のすべての書籍を検索するための照会など、テキスト・エクステンダー(TE)関数を含むSQL照会の実行に関係するコンポーネントを示しています。

 
テキスト・エクステンダー(TE)関数を含むSQL照会の実行に関係するコンポーネント
テキスト・エクステンダー(TE)関数を含むSQL照会の実行に関係するコンポーネント

アプリケーションは、DB2サーバーに対してSQL照会を発行します。DB2サーバーは、内部でテキスト・エクステンダー関数を呼び出し、その関数がテキスト検索エンジンを使用して、どの書籍がリレーショナル・データベースに関するものなのかを判定します。使用する結合アルゴリズム(ハッシュ、ソート・マージ、ネストされたループ結合など)の決定、および照会の2つの部分(つまり、価格条件とテキスト検索条件)を評価する順序の決定は、DB2オプティマイザーによって行われます。データをアプリケーション・サーバーに移動する必要はありません。アプリケーション開発者は、SQL照会を発行する方法さえ知っていればよいことになります。

したがって、DB2の上にテキスト検索ソリューションを実装するアプローチと比べて、テキスト・エクステンダーアプローチには以下の利点があります。

高いパフォーマンス

  • 途中の結果データをアプリケーション・サーバーに移動する必要がありません。
  • 結果の結合が、このジョブを非常に効率的に実行するDB2によって行われます。

完全な統合ソリューション

  • アプリケーション開発者は、広く知られている1つのAPI、つまりSQLを使用するだけでよいことになります。このAPIは、様々なプログラミング言語やプログラミング環境で利用できます。
  • テキスト索引とDB2の内容との同期は、テキスト・エクステンダーによって処理されます。
  • このエクステンダーは、DB2のアクセス制御概念に完全に統合されています。

拡張性

  • たとえば結果の順序付けやグループ化など、他の標準または拡張DB2検索機能とテキスト検索の併用や、空間データやイメージ・データを対象とする検索とテキスト検索との併用が容易です。
  • ユーザー定義タイプやユーザー定義関数/メソッドのようなDB2のオブジェクト指向機能を使用して、SQLに独自の拡張機能を追加することも可能です。

1995年にテキスト・エクステンダーの最初のバージョンが公開されたとき、これらの利点は他に例を見ないもので、同等の製品は市場にありませんでした。そのうちに、すべての主要データベース・ベンダーがこの分野の製品を開発しました。今日の見地からすると、テキスト・エクステンダーには以下の欠点があります。

  • 基礎となるテキスト検索エンジンが、今日の巨大なデータ・セットを処理できるようには構築されていません。
  • テキスト・エクステンダーには、スカラー関数と表関数という2種類の検索スタイルがあります。照会で追加される述部によっては、一方がもう一方より桁違いにパフォーマンスが優れている可能性があります。残念なことに、どちらが実行速度が速いかを照会ごとに判断する手段はありません(そもそもユーザーが判断すべき事柄ではありません)。一般に、テキスト検索のみの照会に適した選択肢であるという理由から、表関数アプローチを使用します。ただし、表関数には一定の制限があり(たとえば、ビューに対して機能しない)、複合照会に関して言えば、スカラー関数のほうがはるかにパフォーマンスが優れている可能性があります。
  • DB2オプティマイザーには、テキスト検索結果と標準のDB2述部関数の結果を最も効率的に結合できるアルゴリズムを選択するのに適した基準がありません。テキスト検索を実行するコストやテキスト検索結果のサイズは、テキスト検索条件自体に大きく左右されますが、DB2オプティマイザーはテキスト検索条件を考慮しません。
  • テキスト・エクステンダー関数は、ジョブを実行するために、テキスト索引に関する特定の情報を必要とします。この情報はいわゆるハンドル列に保持されますが、この保持が更新のパフォーマンスに影響します。
  • テキスト索引の管理は、標準のDB2索引の管理とは異なります。テキスト・エクステンダーを使用するには、あらかじめテキスト・エクステンダーインスタンス(DB2インスタンスとは異なる)を作成し、さらにデータベースのテキスト検索を有効にする必要があります。このため、エキスパートでないユーザーがテキスト・エクステンダーを使用するのは困難です。

前述の理由により、次に解説するネット・サーチ・エクステンダーおよびテキスト情報エクステンダーのアーキテクチャーが開発されました。これらは表裏一体であり、最終的には1つのオファリングに統合される予定です。

2.4 ネット・サーチ・エクステンダーのアーキテクチャー

一見したところ、ネット・サーチ・エクステンダー(NSE)のアーキテクチャー(下図を参照)は、テキスト・エクステンダーのアーキテクチャーとよく似ていますが、大きな違いがあります。テキスト・エクステンダーは、SQLに完全に統合されたテキスト検索関数を備えています。これらの関数は、標準SQL関数「length」や「concat」を使用するのと同様に、標準SQLステートメント内のどこにでも使用することが可能です。対照的に、ネット・サーチ・エクステンダーが備えているのは一連のストアード・プロシージャーです。そのため、DB2インターフェースとDB2通信インフラストラクチャーを使用すればアプリケーション・サーバーとDB2サーバーの境界を越えることは可能ですが、標準SQL照会ほどの完全な機能は備えていません(以下の解説と比較)。

 
ネット・サーチ・エクステンダー(NSE)のアーキテクチャー
ネット・サーチ・エクステンダー(NSE)のアーキテクチャー

ネット・サーチ・エクステンダーは、メモリー内の表、プリソートされた索引、および非常に高速なテキスト検索エンジンにより、応答時間最適化のシナリオ(つまり、膨大になる可能性があるヒット件数の中から最初のn件のヒットを最短の時間で得ることがアプリケーションの主な目的である場合。一般にWebアプリケーションのシナリオがこれに該当します)において、抜群のパフォーマンスとスケーラビリティーを発揮します。

NSEでは、「テキスト索引作成」時に、表またはビュー(あるいはそれらの一部)をメイン・メモリーに格納するように指定することができます。さらに、いずれかの列に基づいてテキスト索引をソートするように指定することも可能です。たとえば、表「books」に列「abstracts」と書籍の価格が含まれているとすると、「abstracts」列のテキスト索引を書籍の価格に基づいてプリソートすることができます。

NSEストアード・プロシージャーの呼び出しを除けば、実行時のDB2の関与を完全に避けることができます。「リレーショナル・データベースに関するすべての書籍の著者と価格を価格で順序付けして取得する」といった照会は、次のように処理されます。NSEは、テキスト索引に対してテキスト照会「relational databases」を発行します。テキスト検索エンジンは順序を保持し、価格が安い書籍から順番に返します。その後、NSEは、メイン・メモリー内の表のルックアップを実行して、対応する著者および価格の値を取得します。

NSEの主な欠点は、その機能がストアード・プロシージャーのみによって提供されることです。したがって、一般にテキスト検索と、DB2に格納されたパラメトリック・データを対象とする検索またはマルチメディア・データ(イメージなど)を対象とする検索のいずれかとの結合が必要なアプリケーションには適していません。NSEは、場合によってはこの制限を克服するのに役立つ以下の2つの機能を備えています。

  • NSE管理コンポーネントを使用すれば、ユーザーはメモリー内の表の数値列にNSE固有の索引を作成することができます。検索時には、これらの列に対する単純な条件をテキスト検索条件に追加することができ、NSEはこれらの索引を利用して照会全体を評価します。
  • テキスト検索照会に加えて、NSEストアード・プロシージャーへの入力パラメーターとしてSQL照会を指定することができます。この機能は、テキスト検索結果のサイズがごく小規模であることを保証できる場合にのみ使用できます。

以下にいくつかのガイドラインを示します。

  • NSEは、共用リソース要件が非常に高く、データベースのサイズが原因でそれが問題となる可能性があります。さらに、利用可能なハードウェアやオペレーティング・システムによって共用リソースのサイズが制限される可能性があります。
  • NSEは、スループットを最適化する必要があるアプリケーション(つまり、数件の「最もマッチする」結果または何らかのソートされた順序で最初の数件の結果のみを必要とするアプリケーションとは対照的に、完全な結果セットを主な目的とするアプリケーション)には適していません。
  • 基本表ではなく、ビューを処理する必要があるアプリケーションの場合、それらのビューの実体化が可能かどうかを確認する必要があります(NSEでは、ビューは、メイン・メモリー内に実体化してからでないと処理できません)。リソース制約によって実体化が不可能な場合もあります(たとえ基本表が、たとえば1万行といった小規模のものでも、それらの基本表を結合したビューは優に数百万行に及ぶ可能性があります)。また、ビューの実体化を不可能にするSQL表現(レジスターなど)がビュー定義に含まれる可能性もあります。

2.5 テキスト情報エクステンダーのアーキテクチャー

以下の図は、たとえばリレーショナル・データベース・システムに関する20ドル未満のすべての書籍を検索するための照会など、テキスト情報エクステンダー(TIE)関数を含むSQL照会の実行に関係するコンポーネントを示しています。

 
テキスト情報エクステンダー(TIE)関数を含むSQL照会の実行に関係するコンポーネント
テキスト情報エクステンダー(TIE)関数を含むSQL照会の実行に関係するコンポーネント

このアーキテクチャーとテキスト・エクステンダーのアーキテクチャーの大きな違いは、TIEのテキスト検索関数を含む照会のリライトと最適化をDB2エンジンが最初からサポートしている点です。要するに、テキスト・エクステンダーと比べて、リライターの拡張によってユーザビリティーが向上し、オプティマイザーの拡張によってパフォーマンスが向上しています。テキスト・エクステンダーのアーキテクチャーの解説で挙げた他のアーキテクチャー上の利点はすべてTIEにも同様に当てはまるため、ここでは繰り返しません。

TIEの最初のリリースの主な問題は、以下のとおりです。

  • 現在の実装では、単一列を主キーとする表の場合にのみテキスト索引の作成が可能です。また、主キーのデータ・タイプに関する制限もあります。
  • テキスト検索関数は、DB2 UDFインターフェースを使用して実装されています。UDFインターフェースは、NSEが使用するストアード・プロシージャー・インターフェースと比べて、パフォーマンスやスケーラビリティーが劣るという欠点があります。なぜなら、UDFインフラストラクチャーによって各トランザクションごとにテキスト検索ライブラリーのロードとアンロードが行われるからです。結果セットが少ない単純な照会の場合、ライブラリーのロード回数は、検索自体の必要回数の数倍必要になります。

3.エクステンダーの選択

3.1 製品情報

エクステンダーの歴史と戦略

テキスト・エクステンダー、ネット・サーチ・エクステンダー、およびテキスト情報エクステンダーの製品戦略と位置付けを理解するには、製品の歴史を知るのが有効です。

  • テキスト・エクステンダーは、最も古いDB2エクステンダーで、1994〜1995年に開発されました。当時、SQLへのテキスト検索関数のシームレスな統合は他に例を見ないもので、同等の製品は市場にありませんでした。そのうちに、すべての主要データベース・ベンダーがこの分野の製品を開発するようになりました。
  • ネット・サーチ・エクステンダーは、特定のお客様向けのソリューションとして、テキスト・エクステンダーではパフォーマンスやスケーラビリティーの要件に対処できなかった非常に大規模なWebサイトのニーズに対処することを目的に出発しました(1999〜2000年頃に開発)。ネット・サーチ・エクステンダーはストアード・プロシージャーをベースにしているため、対処できるのは特定のアプリケーション・シナリオと照会タイプのみです(セクション2.4と比較)。したがって、テキスト・エクステンダーを完全に置き換えるのには適していません。
  • テキスト情報エクステンダー(2000〜2001年に開発)は、テキスト・エクステンダーの後継とされているものです。テキスト・エクステンダーが現在サポートしているすべてのプラットフォームと機能をテキスト情報エクステンダーがカバーするようになり次第、テキスト・エクステンダーは提供中止となります。市場の需要により、TIEの最初のバージョンは、テキスト・エクステンダーを完全に置き換えられるようになる前にリリースせざるを得ませんでした。

現在の計画では、ネット・サーチ・エクステンダーとテキスト情報エクステンダーを1つの製品に統合する予定です。

テキスト検索エンジンの歴史と戦略

エクステンダーが提供するテキスト検索機能は、使用するテキスト検索エンジンの機能に完全に依存します。したがって、IBMのテキスト検索エンジン戦略を理解し、どのテキスト検索エンジンがどのエクステンダーで使用されるかについて知ることも重要です。

ネット・サーチ・エクステンダーは、「GTR」テキスト検索エンジンを使用します。一方、テキスト・エクステンダーはテキスト検索エンジン「TSE」を使用します。一言で言えば、GTRはパフォーマンスの点では優れていますが、TSEほどの機能性がなく、特に言語サポートとXMLのような構造化文書のサポートが欠けています。おもしろいことに、GTRはTSE内部でDBCS言語とファジー検索をサポートするために使用されています。TSEのアーキテクチャー上の問題があるため、TSE内部で使用した場合、GTRのパフォーマンスは完全には発揮されません。

IBMでは現在、GTRの優れたパフォーマンスとTSEの優れた機能性を併せ持つ新しいテキスト検索エンジンの開発を進めています。このエンジンは、今後登場するすべてのIBMテキスト検索製品で使用される予定です。

この新しいテキスト検索エンジンの最初のバージョンは、テキスト情報エクステンダーに統合されています。そのカーネルはGTRをベースにしていますが、構造化文書サポートとフリー・テキスト検索サポートが追加されています。以後のいずれかの段階で言語サポートが追加される予定です。

対応プラットフォームと価格

  • ネット・サーチ・エクステンダーは現在、AIX、Sun Solaris、HP UNIX、Linux/Intel、Linux/390、Windows NT(Enterprise Edition)、およびz/OSで使用可能です。
  • ネット・サーチ・エクステンダーは有料です。
  • テキスト・エクステンダーは現在、AIX、Sun Solaris、HP UNIX、Windows NT、OS/2(Enterprise Edition)、およびz/OSで使用可能で、AIX、Sun Solaris、およびWindows NT版のDB2 Extended Enterprise Editionをサポートしています。
  • テキスト・エクステンダーは無料です(別のCDにパッケージされています)。
  • テキスト情報エクステンダーは現在、AIX、Sun Solaris、およびWindows NTで使用可能です(DB2 V7.2 Enterprise Editionのみ)。
  • テキスト情報エクステンダーは無料です(別のCDにパッケージされています)。

以下の表に、各テキスト検索エクステンダーの主な機能を要約します。

機能TE V7.2NSE V7.2TIE V7.2
索引付け
言語索引付けおよび検索ありなしなし
DB2データ・リンク機能によって参照されるデータの索引付け制限付きなしあり
フルテキスト索引の増分更新ありありあり
LOB列に格納されたデータの索引付けありありあり
UDT列に格納されたデータの索引付けありなしあり
クライアント管理ありなしあり
検索
XMLサポート(XMLパーサー)ありなしあり
標準HTMLサポート(HTMLパーサー)ありなしあり
構造化データ(ユーザー定義タグ)を対象とする検索ありありあり
日付/時刻/数値を対象とする属性検索ありありなし
DBCSサポートありありあり
SQLとの検索の統合ありなしあり
ランキングありありあり
ユーザー定義プリソート結果リストなしありなし
検索結果リスト上のカーソルなしありなし
シソーラス・サポートありなしあり
フリー・テキスト検索ありなしあり
近接検索(同じ段落内)ありなしあり
対応プラットフォーム
AIX、SUN、NTでのDB2 EEのサポートありありあり
HPでのDB2 EEのサポートありありなし
AIX、SUN、NTでのDB2 EEEのサポートありなしなし
z/OSありありなし

3.2 ガイドライン

以下のリストではまず3項目のハイレベルのガイドラインを挙げてから、さらに詳しく掘り下げていきます。ガイドラインのいくつかは互いに矛盾するかもしれません。要件に優先順位を付けてもその矛盾を解決できない場合は、2種類のエクステンダーをインストールし、それらを異なった照会シナリオに使用することを検討してみてください。

  • すべての「標準的な」アプリケーションにはテキスト情報エクステンダーを使用します。このエクステンダーは、DB2との統合という点で最も優れており、設計の柔軟性とパフォーマンスの点でも申し分ありません。
  • ネット・サーチ・エクステンダーは、ハイエンドのe-businessシナリオに対処するためのもので、非常に優れたパフォーマンスとスケーラビリティーを備えていますが、ネット・サーチ・エクステンダーに合わせてアプリケーションを設計できなければなりません。ネット・サーチ・エクステンダーは、応答時間の最適化を主な目的とする(つまり、すべてのヒットを高速にするのではなく、最初のヒットを高速にする)場合で、メイン・メモリーにデータを格納する余裕がある場合に使用します。詳細については、セクション2.4を参照してください。
  • テキスト・エクステンダーは、言語処理が最も重要である場合に使用します。ただし、これらの拡張機能を使用するとパフォーマンスの点で不利になることに注意してください。
  • 複数列が一主キーとなる表の場合には、テキスト情報エクステンダーは使用できません。
  • テキスト・データを対象とする検索を標準のパラメトリック・データを対象とする検索や空間検索のような他のタイプの検索と結合する必要がある場合には、テキスト情報エクステンダーを使用する必要があります。
  • アプリケーションが非常に多数の同時テキスト検索照会を生成する場合には、ネット・サーチ・エクステンダーを選んでください。
  • (数件の「最もマッチする」結果または何らかのソートされた順序で最初の数件の結果のみを必要とするアプリケーションとは対照的に)大きな「完全」結果セットを受け取る必要があるアプリケーションでは、ネット・サーチ・エクステンダーを使用してはなりません。
  • 構造化文書(XML、HTML、または独自のフォーマット)をサポートするテキスト検索が必要な場合には、テキスト情報エクステンダーを使用します(ネット・サーチ・エクステンダー自体はXML文書をサポートしていませんが、DB2にデータをロードする際にXML文書やPDF文書を変換できる「Net Search Loader」サービス・オファリングがあります)。
  • 近接検索(単語「b」と同じ段落内にある単語「a」)、フリー・テキスト検索、またはシソーラス・サポートが必要な場合には、ネット・サーチ・エクステンダーは使用できません。
  • 再呼び出しに関する検索結果の品質がアプリケーションにとって極めて重要な場合や、言語的に見てより複雑な言語(ドイツ語など)で文書が記述されている場合には、テキスト・エクステンダーを検討する必要があるかもしれません。
  • アプリケーションでギガバイト範囲のテキスト索引を必要とする場合には、テキスト・エクステンダーを使用してはなりません。

4.テキスト・エクステンダー

4.1 概要

テキスト・エクステンダーは、SQL照会に全文検索機能を追加したものです。このエクステンダーを使用すれば、DB2ユーザーやアプリケーション・プログラマーは、DB2表またはDB2データ・リンク・マネージャーによって管理されるファイルに格納されたテキスト文書全体を検索することができます。主な機能は以下のとおりです。

  • SQLに完全に統合されたテキスト検索関数
  • 英語、ドイツ語、フランス語、日本語をはじめとする22カ国語の索引付けと検索。基本の索引付けと検索は37カ国語をサポート
  • ブール検索(単語および句のand、or、not)
  • 同じ段落または文に含まれる単語の検索
  • フリー・テキスト検索(検索引き数をフリー・テキストとして指定)
  • ファジー検索(たとえば、「Shakepeere」で検索して「Shakespeare」を見つける)
  • シソーラス・サポート(指定した関係に基づく検索語の拡張)
  • 構造化文書(ユーザー定義、またはHTMLやXML)のセクション内の検索
  • 構造化文書内の日付、時刻、および数値属性を対象とする検索
  • 検索結果のランキング
  • フルテキスト索引の増分更新と非同期更新
  • 文字データ・タイプ、ユーザー定義タイプ、ラージ・オブジェクト、およびDB2データ・リンク・マネージャーによって管理される外部ファイルを対象とする索引付けおよび検索のサポート

4.2 例

以下に、DB2 テキスト・エクステンダーの簡単な使用例を示します。以下の3つのステップがあります。

  1. いくつかのサンプル・データを含む小さなデータベース表を作成する。
  2. サンプル・データのフルテキスト索引を作成する。
  3. フルテキスト索引を使用して検索を行う。

「sample」など、既存のデータベースを使用して、オペレーティング・システムのコマンド行でサンプル・コマンドを発行します。

テーブルを作成し、データをロードする

まず、いくつかのDB2コマンドを発行してサンプル表を作成し、いくつかのサンプル・データをロードします。

db2 "CREATE TABLE books (author VARCHAR(30), 
				   story LONG VARCHAR
				   year INTEGER);"

このコマンドにより、物語の著者と物語自体を格納する列を含む表「books」が作成されます。

db2 "INSERT INTO books 
	VALUES ('John', 'A man was running down the street.', 2001)" 
db2 "INSERT INTO books 
	VALUES ('Mike', 'The cat hunts some mice.', 2000)" 
db2 "INSERT INTO books 
	VALUES ('Peter','Some men were standing beside the table.',1999)"

これらのコマンドにより、表にデータがロードされます。

テキスト索引を作成する

テキスト索引を作成するには、DB2コマンドと同様に、オペレーティング・システムのコマンド行でDB2 テキスト・エクステンダーコマンドを発行します。DB2 テキスト・エクステンダーコマンドを発行する前に、DB2 テキスト・エクステンダーにデータベース名を知らせるための環境変数を設定します。

export DB2DBDFT=sample

このコマンドにより、デフォルトのデータベース環境変数が設定されます。Microsoft Windowsオペレーティング・システム環境では、「export」コマンドではなく「set」コマンドを使用する必要があります。

db2tx "ENABLE DATABASE"

このコマンドにより、DB2 テキスト・エクステンダーでデータベースを使用する準備が整います。このステップは、各データベースごとに1回だけ実行する必要があり、データベースを作成した直後に実行することができます。

db2tx "ENABLE TEXT COLUMN books story HANDLE story_handle 
	INDEXTYPE LINGUISTIC"

このコマンドにより、列「story」のフルテキスト索引が作成されます。索引付けの間、索引付けされた文書に関する情報を含む列「story_handle」が表に追加されます。テキスト索引を検索する際には、このハンドル列の名前が使用されます。

テキスト索引を対象に検索を行う

DB2 テキスト・エクステンダーの検索機能はDB2関数によって提供されるため、任意のSQL照会で使用することができます。

 db2 "       SELECT 	author, story FROM books 
            WHERE 	DB2TX.CONTAINS (story_handle, '\"mouse\"') = 1 
		AND year >= 2000"

(テキスト検索句を囲む二重引用符の前に付ける必要があるエスケープ文字は、使用するオペレーティング・システム・シェルによって異なります。)この照会により、ハンドル列「story_handle」によって決定されるフルテキスト索引を対象に単語「mouse」が検索されます。見つかった書籍はすべて、2000年より新しいものであるはずです。以下の結果表が返されます。

AUTHOR	STORY 
Mike	The cat hunts some mice.

「mouse」の検索で単語「mice」が見つかったのは、索引付けコマンドで言語索引タイプを先に選択したためです。言語検索機能は、DB2 テキスト・エクステンダーの主な利点の1つです。

その他の関数としては、見つかった文書が検索引き数によってどの程度正確に表現されているかを示す標識を返すRANKや、結果の文書内に見つかった照会語のマッチ回数を返すNO_OF_MATCHESがあります。

4.3 パフォーマンスに関するヒント

  • スカラー関数と表関数: テキスト・エクステンダーには表関数SEARCH_RESULTがありますが、これは機能上、スカラー関数CONTAINS、RANK、およびNO_OF_MATCHESと同等です。照会がテキスト検索のみを実行するものである(パラメトリック・データに関する条件がない)場合、この表関数を使用するとパフォーマンスが向上します。また、テキスト検索条件よりも多くの結果がパラメトリック検索条件によって返されることが期待される場合や、期待される結果のサイズが不確かな場合にも表関数を使用する必要があります。
  • テキスト検索のみの照会の場合には、テキスト検索条件に「RESULT LIMIT」制限を指定することもできます。テキスト照会のパフォーマンスを左右するのは、テキスト索引のサイズではなく、主に返される結果の件数であるため、これによってパフォーマンスが大幅に向上します。 ただし、複合照会や「ORDER BY」句を含む照会で結果サイズ制限を使用する場合は、注意が必要です。たとえば、リレーショナル・データベースに関する書籍で、特定の価格より安いすべての書籍を探そうとしている場合に、テキスト検索の結果を100冊に制限すると、最初の100冊の書籍がいずれも指定した価格より安くないといったことが起こる可能性があります。次の数百冊の書籍の中には、指定した価格より安いものがあるはずですが、それにもかかわらず、空の検索結果が返されることになります。
  • NGRAM索引を使用すると、索引付けおよびテキスト検索を最も効率よく行うことができます。

5.ネット・サーチ・エクステンダー

5.1 概要

ネット・サーチ・エクステンダーを使用すれば、インターネット上のテキストの高速でスケーラブルな全文検索をIBM DB2 Universal Databaseで行うことが可能になります。ネット・サーチ・エクステンダーは、メモリー内のデータベース・テクノロジーとテキスト検索を結合したものです。主な機能は以下のとおりです。

  • ストアード・プロシージャーによって呼び出されるテキスト検索機能
  • 1秒以下の検索応答時間
  • 1秒当たり1,000件の照会まで検索パフォーマンスが低下しない
  • 1時間当たり約1GBの索引付け速度
  • テラバイト単位までのスケーラビリティー
  • 英語、スペイン語、フランス語、日本語、中国語をはじめとする37カ国語の基本検索サポート
  • ブール検索(単語および句のand、or、not)
  • ファジー検索(たとえば、「Shakepeere」で検索して「Shakespeare」を見つける)
  • 構造化文書(ユーザー定義タグ)のセクション内の検索
  • メモリー内の表に格納された数値属性を対象とする検索
  • 検索結果のランキング
  • ラージ・オブジェクト(LOB)および文字データ・タイプを対象とする索引付けと検索のサポート

ネット・サーチ・エクステンダーのユーザー・マニュアルには検索パフォーマンスの最適化に関するセクションがあるため、この章ではパフォーマンスに関するヒントは示しません。

5.2 例

以下に、DB2 ネット・サーチ・エクステンダーの簡単な使用例を示します。以下の3つのステップがあります。

  1. データベース表を作成し、いくつかのサンプル・データをロードする。
  2. サンプル・データのフルテキスト索引を作成する。
  3. フルテキスト索引を使用して検索を行う。

「sample」など、既存のデータベースを使用して、オペレーティング・システムのコマンド行でサンプル・コマンドを発行します。

テーブルを作成し、データをロードする

まず、いくつかのDB2コマンドを発行してサンプル表を作成し、いくつかのサンプル・データをロードします。

 db2 "CREATE TABLE products ( 
                       article_no  INTEGER NOT NULL, 
                       name        VARCHAR(100), 
                       description LONG VARCHAR, 
                       price       INTEGER, 
                       PRIMARY KEY (article_no) 
                        )"

このコマンドにより、商品番号、商品名、説明テキスト、および価格を格納するためのフィールドを含む表「products」が作成されます。ネット・サーチ・エクステンダーでは、いずれかの1つの列に一次キーが必要です。

db2 "INSERT INTO products 
	VALUES (1, 'Lamp', 'Table lamp, blue, 60W', 3200)" 
db2 "INSERT INTO products 
	VALUES (2, 'Cup', 'Large blue coffee cup', 400)" 
db2 "INSERT INTO products 
	VALUES (3, 'Ballpoint pen', 'Yellow plastic ballpoint pen including black refill', 95)"

これらのコマンドにより、表にデータがロードされます。

テキスト索引を作成する

テキスト索引を作成するには、DB2コマンドと同様に、オペレーティング・システムのコマンド行でDB2 ネット・サーチ・エクステンダーコマンドを発行します。

db2nx "ENABLE DATABASE sample"

このコマンドにより、DB2 ネット・サーチ・エクステンダーでデータベースを使用する準備が整います。このステップは、各データベースごとに1回だけ実行する必要があり、データベースを作成した直後に実行することができます。

db2nx "ENABLE TEXT COLUMN products description 
                     INDEX prod_dsc 
                     USING article_no 
                     OPTIMIZE ON (description, price)
                     ORDER BY price ASC
                     DATABASE sample"

このコマンドにより、列「description」のフルテキスト索引「prod_dsc」が作成されます。OPTIMIZE ONオプションを使用すると、「description」および「price」列の内容がメモリー内に保持され、データベース表からの検索よりはるかに速く検索することができます。「ORDER BY」オプションを使用すると、メモリー内の表が価格を基準にプリソートされます。

テキスト索引を対象に検索を行う

DB2 ネット・サーチ・エクステンダーの検索機能はDB2ストアード・プロシージャーによって提供されるため、Java、DB2 CLI、およびNet.Dataアプリケーションから容易に呼び出すことができます。

db2 "call textSearch ( ?, '\"blue\"', 0, 0, 0, 100, 'PROD_DSC', 
                '$DB2NX_INSTOWNERHOMEDIR/db2nx/indices', null, null, 0, ?)"

このコマンドにより、フルテキスト索引「prod_dsc」を対象に、単語「blue」を含む商品説明が検索されます。この場合、索引付けコマンドのOPTIMIZE ONおよびORDER BY文節によって指定されたとおり、メモリー内の表から検索結果が得られます(すべての入力および出力パラメーターの意味については、マニュアルをご覧ください)。

以下の結果セットが返されます。

ARTICLE_NO  	DESCRIPTION             	PRICE 
     2       	Large blue coffee cup   	400
     1       	Table lamp, blue, 60W   	3200

6.テキスト情報エクステンダー

6.1 概要

テキスト情報エクステンダー(TIE)は、SQL照会に全文検索機能を追加したものです。このエクステンダーを使用すれば、DB2ユーザーやアプリケーション・プログラマーは、DB2表またはDB2データ・リンク・マネージャーによって管理されるファイルに格納されたテキスト文書全体を検索することができます。主な機能は以下のとおりです。

  • SQLに完全に統合されたテキスト検索関数
  • ブール検索(単語および句のand、or、not)
  • 同じ段落または文に含まれる単語の検索
  • フリー・テキスト検索(検索引き数をフリー・テキストとして指定)
  • ファジー検索(たとえば、「Shakepeere」で検索して「Shakespeare」を見つける)
  • シソーラス・サポート(指定した関係に基づく検索語の拡張)
  • 構造化文書(ユーザー定義、またはHTMLやXML)のセクション内の検索
  • 検索結果のランキング
  • フルテキスト索引の増分更新と非同期更新
  • 文字データ・タイプ、ユーザー定義タイプ、ラージ・オブジェクト、およびDB2データ・リンク・マネージャーによって管理される任意のデータ・リンクを対象とする索引付けおよび検索のサポート
  • 管理コマンドがDB2管理コマンドとよく似ているため、データベース管理者にとって使いやすい

6.2 例

以下に、DB2 テキスト情報エクステンダーの簡単な使用例を示します。以下の3つのステップがあります。

  1. いくつかのサンプル・データを含む小さなデータベース表を作成する。
  2. サンプル・データのフルテキスト索引を作成する。
  3. フルテキスト索引を使用して検索を行う。

「sample」など、既存のデータベースを使用して、オペレーティング・システムのコマンド行でサンプル・コマンドを発行します。ここでは、データベース名を「sample」と仮定します。

テーブルを作成し、データをロードする

まず、いくつかのDB2コマンドを発行してサンプル表を作成し、いくつかのサンプル・データをロードします。

db2 "INSERT INTO books 
	VALUES ('John', 'A man was running down the street.', 2001)" 
db2 "INSERT INTO books 
	VALUES ('Mike', 'The cat hunts some mice.'), 2000" 
db2 "INSERT INTO books 
	VALUES ('Peter', 'Some men were standing beside the table.',1999)"

これらのコマンドにより、表にデータがロードされます。

テキスト索引を作成する

テキスト索引を作成するには、DB2コマンドと同様に、オペレーティング・システムのコマンド行でDB2 TIEコマンドを発行します。

db2text "ENABLE DATABASE FOR TEXT CONNECT TO sample"

このコマンドにより、DB2 TIEでデータベースを使用する準備が整います。このステップは、各データベースごとに1回だけ実行する必要があり、データベースを作成した直後に実行することができます。

db2text "CREATE INDEX myTextIndex ON books (story) FOR TEXT 
	CONNECT TO sample"

このコマンドにより、列「story」のフルテキスト索引が作成されます。

テキスト索引を対象に検索を行う

DB2 TIEの検索機能は、DB2関数によって提供されるため、任意のSQL照会で使用することができます。

db2 "SELECT author, story FROM books 
        WHERE CONTAINS (story, '\"cat\"') = 1 AND YEAR >= 2000"

(テキスト検索句を囲む二重引用符の前に付ける必要があるエスケープ文字は、使用するオペレーティング・システム・シェルによって異なります。)この照会により、「cats」に関する2000年より新しいすべての書籍が検索されます。以下の結果表が返されます。

AUTHOR   	STORY 
Mike 	The cat hunts some mice.

サポートされるその他の関数としては、見つかった文書が検索引き数によってどの程度正確に表現されているかを示す標識を返すSCOREや、結果の文書内に見つかった照会語のマッチ回数を返すNUMBEROFMATCHESがあります。

6.3 パフォーマンスに関するヒント

  • 主キーのデータ・タイプを自由に選択できる場合には、INTやBIGINTのような「short」タイプを使用します。タイプ「VARCHAR」は、特定の最適化機能が有効にならないため使用してはなりません。その代わりに「VARCHAR FOR BIT DATA」の使用も推奨されます。
  • データの大規模な挿入または削除を行った後は、忘れずに「db2 runstats」を実行してください。実行しないと、オプティマイザーが期待される結果のサイズについて誤った判断をしてしまい、テキスト検索のみの照会でも、まったく不適切な方法を選択する可能性があります。
  • 照会のSELECT部分にSCORE関数が含まれる場合には、同じテキスト列と同じテキスト検索条件を持つCONTAINS述部関数をWHERE部分に追加してください。リライターは、2つの条件をマージし、テキスト検索条件を満たす文書のみについてSCORE値を計算します(他のすべての文書では、いずれにしても値は0になります)。
  • テキスト検索のみの照会の場合、テキスト検索条件に「RESULT LIMIT」制限を指定することもできます。テキスト照会のパフォーマンスは主に返される結果の件数に左右されるため、これによってパフォーマンスが大幅に向上します。 ただし、複合照会や「ORDER BY」句を含む照会で結果サイズ制限を使用する場合には、注意が必要です。たとえば、リレーショナル・データベースに関する書籍で、特定の価格より安いすべての書籍を探そうとしている場合に、テキスト検索の結果を100冊に制限すると、最初の100冊の書籍がいずれも指定した価格より安くないといったことが起こる可能性があります。次の数百冊の書籍の中には、指定した価格より安いものがあるはずですが、誤った結果として空の検索結果が返されることになります。
  • テキスト索引作成中にコミット・カウント値を使用すると、索引付け時間がかなり長くなる可能性があります。

7.その他の情報の入手先

連絡先

ヨーロッパ、中東、およびアフリカ担当:

  • Jurgen Metter
    Content Management Service and Support
    IBM Deutschland Entwicklung GmbH
    Schunaicher Str. 220 71032 Bublingen
    Germany
    Phone: +49-7031-16-4254
    Fax: +49-7031-16-4891
  • Juergen Schimpf
    DB2 UDB Extender Development IBM Deutschland Entwicklung GmbH
    Schunaicher Str. 220
    71032 Bublingen
    Germany
    Phone: +49-7031-16-4583
    Fax: +49-7031-16-4891

米国担当:

  • Stewart Tate
    Content Management Internet Services
    tates@us.ibm.com
    Phone: (408) 463-3175

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=323397
ArticleTitle=DB2の全文検索製品
publish-date=04272005