Oracle Database 11g Release 1(11.1) Oracle Textの新機能

Transcription

1 Oracle ホワイト ペーパー 2007 年 5 月

2 はじめに Oracle Text は テキスト情報の検索 取得 管理を行うための仕組みであり データベース環境に完全に統合されています Oracle Database 11g Release 1(11.1) に付属した Oracle Text は その業界トップ レベルの品質を維持すべく 様々な新機能を導入しています Oracle Text の新機能は 大きく次の 4 つに分類できます パフォーマンスの向上 アプリケーション停止時間の最小化 グローバリゼーション対応 保守の容易性 このホワイト ペーパーでは これらの新機能の概要を説明します 使用例などの詳細については 製品付属のマニュアルをご参照ください 新機能の概要 パフォーマンスの向上 o 検索パフォーマンスの向上 スケーラビリティの向上 o SDATA セクションとコンポジット ドメイン索引 o ローカル パーティション索引のパーティション数の増加 o パラレル索引最適化 (Rebuild モード ) 2

3 o ユーザー定義スコア アプリケーション停止時間の最小化 o 増分索引作成機能 o オンライン索引再作成 グローバリゼーション対応 o 数多くの言語を処理する AUTO_LEXER o INDEX_STEMS での対応言語数の増加 保守の容易性 o Oracle Enterprise Manager に Oracle Text Manager の機能が組み込まれました Oracle Text Manager を利用すると 次のことが可能になります テキスト索引の状態を監視 索引の設定情報を変更 索引レベルの統計データ生成 ( ディスク スペース 断片化 ガベージ 単語の出現頻度など ) 問題の診断と 失敗した操作のやり直し ログ管理 o 使用機能のトラッキング ( 特定のシステムでどの機能が利用されているのかを素早く確認することが可能 ) 検索パフォーマンスの向上 SDATA セクションとコンポジット ドメイン索引 SDATA セクションとコンポジット ドメイン索引は 互いに密接に関連しています 実際 これらは同じ機能の 2 つの側面として捉えることができます これらは テキスト検索と構造化検索を同時に問い合わせる コンポジット ( 複合 ) 問合せ のパフォーマンスを向上させるように設計されています 例として 次の問合せについて考えてみます SELECT item_id FROM items WHERE CONTAINS (description, 'madonna') > 0 AND itmtype = 'BOOK' AND price < 10 ORDER BY price DESC; この問合せが抱える問題は 複数の索引が使用されることにあります 必要な B ツリー索引やビットマップ索引が作成されており 適切な実行計画がある場合 CONTAINS 条件または構造化条件が非常に選択的であれば 通常 この問合せは非常に効率的に実行されます ( このとき 問合せにヒットしたレコードをソートする場合には 元表にアクセスする必要があります ) 3

4 ただし どちらの条件も選択的でなく ( 例えば CONTAINS 条件にヒットしたレコードのサイズが 5K itmtype 列の条件にヒットしたレコードのサイズが 10K price 列の条件にヒットしたレコードのサイズが 30K の場合 ) かつ全体の問合せ結果が選択的である場合 最善の実行計画では テキスト索引からのアクセスか またはテキスト索引とビットマップ索引を組み合わせた操作を実行することになります このような最適な実行計画を使用しても テキスト索引内部の DOCID から外部の ROWID への変換や 元表にアクセスする余分なオーバーヘッドが発生するため 問合せのパフォーマンスは不十分である場合があります これらの問合せがテキスト検索の条件のみのシンプルな検索と同等のパフォーマンスを発揮する可能性はきわめて低いと言えます Oracle Database 10g Release 1(11.1) では MDATA( メタデータ ) セクションが導入されました MDATA セクションを利用すると メタデータの情報はテキスト索引の内部に格納れます これにより 上述の問合せを以下のように書き換えることができます MDATA セクションは Oracle Database 10g で導入されました MDATA セクションを利用することで 短いテキスト フィールドに対する等価検索を実行できます SELECT item_id FROM items WHERE CONTAINS (description, 'madonna and MDATA(itmtype, BOOK)') > 0 AND price < 10 ORDER BY price DESC; この書き換えにより ある程度はパフォーマンスが改善されます 場合によっては DOCID から ROWID への不要な変換が多数取り除かれます また itmtype 列の情報をテキスト索引から取得できるため itmtype='book' という条件を評価するために元表にアクセスする必要はなくなります しかし 問題が完全に解決されるわけではありません MDATA で使用できるのは等価検索のみであり price < 10 という条件を指定することはできません MDATA をソートで使用することはできません SDATA セクション SDATA セクションは MDATA セクションと同じような方法で定義され 使用されます しかし MDATA とは異なり 等価検索だけではなく 数値または日付フィールドの範囲検索で使用できます Oracle Database 11g Release 1(11.1) では 以下のような問合せを実行できます SELECT item_id FROM items WHERE CONTAINS (description, 'madonna and SDATA(itmtype=''BOOK'') and SDATA(price<10)') > 0 ORDER BY price DESC; ここでは テキスト問合せの一部として範囲検索を実施しています これは さまざまな状況において有効な新機能です コンポジット ドメイン索引 コンポジット ドメイン索引では SDATA セクションと同じテクノロジを利用していますが より標準的な方法で使いやすくなっています はじめに 用語について説明します ドメイン索引 とは 特定のタイプのデータ ( この例の場合 テキスト データ ) に対して使用するタイプの索引です 4

5 通常の Oracle 用語におけるコンポジット索引は 複数の列を対象とする索引を指します コンポジット ドメイン索引 (CDI Composite Domain Index) は 一般的なドメイン索引の拡張として 複数の列を索引付けの対象とすることが可能です 最初に例に挙げた問合せをもう一度見てみましょう SELECT item_id FROM items WHERE CONTAINS (description, 'madonna') > 0 AND itmtype = 'BOOK' AND price < 10 ORDER BY price DESC; この問合せに適切な索引を 以前のバージョンの Oracle で作成するには 次の SQL コマンドを実行することになります CREATE INDEX typeind ON items (itmtype); CREATE INDEX priceind ON items (price); CREATE INDEX descind ON items (description) INDEXTYPE IS ctxsys.context; Oracle Database 11g Release 1(11.1) では 1 つの SQL コマンドで必要な操作をすべて実行できます CREATE INDEX compind ON items (description) INDEXTYPE IS ctxsys.context FILTER BY itmtype, price SORT BY price; このとき Oracle は price 列や itmtype 列のデータをテキスト索引の内部に保存します 問合せを変更する必要はありません ( これは SDATA の時と同様です ) オプティマイザはテキスト索引だけで問合せ条件が評価可能であることを理解し 行の絞り込み処理はテキスト索引の側で実行され 検索条件を満たす itemtype 値と price 値が取得されます さらに Oracle は テキスト索引に対して 正しくソートされた行を返すよう要求します この方法は データベースがすべての行を取得した上でソートするよりもかなり効率的です 注 : コンポジット ドメイン索引は 構造化のみの検索における B ツリー索引を置き換えるものではありません 以下に例を示します select * from items where itmtype='book'; この実行結果は 次の問合せの結果とは異なる場合があります select * from items where contains(description, 'SDATA(itmtype="BOOK")')>0; SDATA セクションはテキスト索引の一部であるため 同期化処理が完了したドキュメントのみが検索対象となります 前者の問合せでは 条件に合う行であれば同期されていなくても返されますが 後者の問合せではそれらの行は同期されていないと返されません 5

6 SDATA セクションを含むテキスト索引が作成されると $S 表が作成されます ($S 表は CREATE INDEX 文で FILTER BY 句や ORDER BY 句を使用して暗黙的に作成されていても 明示的に ctx_ddl.add_sdata_section を使用して作成されていても生成されます )$S 表は SDATA セクションの値を参照するために利用されます $S 表は索引構成表 (IOT Index-Oraganized Table) であり オーバーフロー セグメントを含めることはできません したがって $S 表に対して PCTTHRESHOLD 句または OVERFLOW 句を含んだ記憶域プリファレンスを指定した場合 CREATE INDEX 文の実行中にエラーが発生します また $S 表を作成する表領域は データベース ブロック サイズが 4 KB 以上である必要があります ローカル パーティション索引のパーティション数の増加 データベース表のパーティション化や テキスト索引のローカル パーティション化は テキスト索引のパフォーマンスを最大化する一般的な方法です ( 限られた数のパーティションだけがヒットするように問合せが最適化されている場合 ) Oracle Database 10g で使用できるテキスト索引のパーティション数の最大は 9999 でしたが Oracle Database 11g ではこの制限が緩和され テキスト索引のパーティション数の制限は表パーティションの制限と同じ すなわち 1,048,575 になりました パラレル索引最適化 (Rebuild モード ) Rebuild モードで索引を最適化すると もっともきれいな索引を構築できます しかし Rebuild モードの索引最適化プロセスは 索引の完全コピーを取って新しいブロックにこれを格納するため 十分なディスク領域を必要とします このリリースでは この Rebuild モードでの索引最適化をパラレルに実行することができます アプリケーション停止時間の最小化 増分索引作成機能 CTX_DDL.SYNC_INDEX プロシージャに 新しいパラメータ MAXTIME が導入されました これにより SYNC コールの実行時間を制限できるようになりました CTX_DDL.POPULATE_PENDING と組み合わせて使用すると システムの負荷が少ない時間に少しずつ索引を作成できます この機能は 次に説明するオンライン索引再作成と組み合わせると特に効果的です オンライン索引再作成 たとえば 区切り文字や大文字小文字の区別などの索引オプションを変更する場合 テキスト索引を再作成する必要があります このような場合 以前のバージョンでは 新しい索引の構築に必要な時間内はずっと このテキスト索引を使用することができませんでした 索引のサイズが大きい場合は この処理が何日にも及ぶことがありました Oracle Database 11g では シャドウ テキスト索引を作成できます この機能を利用すると 元のテキスト索引を使用したままで索引を構築することができ 索引の構築が完了すると 元の索引は新しく構築されたシャドウ索引と交換できます 交換が実行されるとすぐに問合せが新しい索引に自動的に移行します 6

7 新しい CTX_DDL.RECREATE_INDEX_ONLINE プロシージャを使用して これらの処理をすべて自動で実行できます ( より詳細な設定を行うことも可能です ) この機能により 新しい索引を段階的に作成できるため システムの負荷が少ない時間に少しずつ処理を実行でき ピーク時のシステム パフォーマンスに影響を与えることがなくなります グローバリゼーション対応 新しい AUTO_LEXER 以前のバージョンでは 多言語に対する索引付け機能として WORLD_LEXER が提供されていました しかし WORLD_LEXER では ステミングやセグメンテーションは実行されませんでした 格 性 時制などによって語形が変化する言語の場合 ステミングはきわめて重要です 1 つの単語が何十 何百もの形式を取る可能性がある場合 索引作成中にこれらすべてを識別して 今後の検索で使用できるように 単語の基本形式を索引内に格納する必要があります セグメンテーションは 複合語に含まれる要素を識別するために必要です AUTO_LEXER は 各種言語を自動的に識別します ( これまでと同様に LANGUAGE 列を使用してそれぞれのドキュメントの言語を指定することもできます ) 言語の自動認識機能は 複数の段落を含む長文のドキュメントでもっとも有効に機能します 検索対象となるドキュメントが非常に短い文章の一節などの場合には 手動で言語設定を行うことが推奨されます AUTO_LEXER は 32 言語のセグメンテーションとステミングをサポートします これらのうち 23 言語で文脈に依存したステミングがサポートされます 文脈に依存したステミングでは たとえば 前後の文章を解析してその単語が動詞であるか名詞であるかを認識して適切な処理を行います 次に AUTO_LEXER でサポートされる言語を示します 太字で表記されている言語では 文脈に依存したステミングがサポートされます アラビア語 カタロニア語 簡体字中国語 繁体字中国語 クロアチア語 チェコ語 デンマーク語 オランダ語 英語 フィンランド語 フランス語 ドイツ語 ギリシャ語 ヘブライ語 ハンガリー語 イタリア語 日本語 韓国語 ボークモール語 新ノルウェー語 ペルシア語 ポーランド語 ポルトガル語 ルーマニア語 ロシア語 セルビア語 スロバキア語 スロベニア語 スペイン語 スウェーデン語 タイ語 トルコ語 INDEX_STEMS の対応言語数の増加 BASIC_LEXER を使用して完全な制御を行いながら 各種言語でステミングを使用したい場合はどうすれば良いでしょうか 問題ありません 新しい INDEX_STEMS 機能は 上記リストに太字で表記されているすべての言語で使用できます 7

8 保守の容易性 Oracle Enterprise Manager への統合 Oracle Enterprise Manager の新しい Oracle Text Manager は 包括的な一連の機能を提供します これにより データベース管理者は Oracle Text の索引の状態やステータスを監視し 索引に対する各種メンテナンス タスクを実行できます 使用機能のトラッキング この機能は おもに Oracle 社のサポート サービスと一緒にご利用いただくために提供されています サポート アナリストは 単純な表検索を行うだけで 特定のアプリケーションで使用されている Oracle Text の機能を素早く 簡単に 正確に特定できます また この機能は データベース管理者やコンサルタントが 既存のアプリケーションの仕様を迅速に把握するのにも役立ちます 8

9 年 8 月著者 :Roger Ford 共著者 :Wesley Lin, MohammadFaisal Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : Copyright 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です