| Oracle® Textアプリケーション開発者ガイド 11gリリース2 (11.2) B61358-04 |
|
 前 |
 次 |
この章では、問合せおよび索引付けのパフォーマンスを改善する方法について説明します。次の項目について説明します。
デフォルトでは、Oracle Textにより、問合せはスループット向上のために最適化されます。最適化の結果、問合せは最短時間ですべての行を戻します。
ただし、多くの場合(特にWebアプリケーションの場合)、問合せを応答時間が短縮されるように最適化する必要があります。これは大きなヒットリストからできるだけ短い時間で、最初の数個のヒットのみを取得する必要があるためです。
次の各項では、応答時間が短縮されるようにCONTAINS問合せを最適化する方法を説明します。
次のような要因が問合せ応答時間に影響します。
表統計の収集
メモリー割当て
ソート
元表に存在するLOB列
パーティション化
並列性
問合せで語句を拡張する回数
ORDER BY問合せの最初のいくつかの行が必要な場合は、コストベースであるFIRST_ROWS(n)ヒントを使用することをお薦めします。
FIRST_ROWS(n)ヒントは、最初の(n)行をできるだけ短時間で受け取る必要がある場合に使用します。たとえば、次のPL/SQLブロックでは、カーソルを使用して問合せの最初の10ヒットを取り出し、FIRST_ROWS(n)ヒントを使用して応答時間が短縮されるように最適化しています。
declare cursor c is select /*+ FIRST_ROWS(10) */ article_id from articles_tab where contains(article, 'Omophagia')>0 order "by pub_date desc; begin
for i in c loop insert into t_s values(i.pk, i.col); exit when c%rowcount > 11; end loop;
end; /
カーソルcはomophagiaというワードを含むソートされたROWIDを戻すSELECT文です。コードがカーソル内をループして、最初の10行を取り出します。取り出された行は、一時表t_sに格納されます。
FIRST_ROWS(n)ヒントを指定した場合、オプティマイザは上位n個のヒットを戻すコストが低い場合に、テキスト索引に対してROWIDをスコア順で戻すように指示します。
このヒントがない場合、テキスト索引によりCONTAINS述語を満たすすべての行がソートされていない順序で戻された後、Oracle DatabaseによりROWIDがソートされます。このように結果セット全体を取り出すと時間がかかります。
この問合せでは、最初の10ヒットのみが必要なため、ヒントを使用することでパフォーマンスが向上します。
|
注意: FIRST_ROWS(n)ヒントは、問合せで最初の数個のヒットのみが必要な場合に使用します。結果セット全体が必要な場合は、パフォーマンスの低下につながるため、このヒントは使用しないでください。 |
また、DOMAIN_INDEX_SORTヒントを使用して応答時間を短縮することもできます。FIRST_ROWS(n)の場合と同じように、応答時間が短縮されるように問合せが最適化されている場合は、Oracle Textは最初の数行を最短時間で戻します。
たとえば、このヒントは次のように使用できます。
select /*+ DOMAIN_INDEX_SORT */ pk, score(1), col from ctx_tab
where contains(txt_col, 'test', 1) > 0 order by score(1) desc;
ただし、このヒントはルールベースのみです。つまり、Oracle Textでは、ORDER BY句を満たす索引を常に選択します。この結果、CONTAINS句の選択性が非常に高い問合せでは、パフォーマンスが最善にはならないことがあります。そのような場合は、完全にコストベースのFIRST_ROWS(n)ヒントを使用することをお薦めします。
データをパーティション化し、ローカル・パーティション索引を作成すると、問合せのパフォーマンスが向上します。パーティション表では、各パーティションに独自の索引表セットがあります。実際には複数の索引がありますが、各索引からの結果が必要に応じて組み合され、最終的な結果セットが生成されます。
LOCALキーワードを使用して、CONTEXT索引を次のように作成します。
CREATE INDEX index_name ON table_name (column_name)
INDEXTYPE IS ctxsys.context
PARAMETERS ('...')
LOCAL
パーティション化された表および索引を使用すると、次のような問合せのパフォーマンスが向上します。
これは、パーティション・キー列の特定の値範囲に検索を限定する問合せです。たとえば、日付範囲に対する次の問合せについて考えます。
SELECT storyid FROM storytab WHERE CONTAINS(story, 'oliver')>0 and pub_date BETWEEN '1-OCT-93' AND '1-NOV-93';
日付範囲が制限されている場合は、1つのパーティションを検索するだけで問合せが満たされる可能性があります。
これは、最初のn個のヒットのみが必要で、ORDER BY句がパーティション・キーを指定する問合せです。次のように、price列に対するORDER BY問合せで最初の20ヒットをフェッチする場合を考えてみます。
SELECT * FROM (
SELECT itemid FROM item_tab WHERE CONTAINS(item_desc, 'cd player') >0 ORDER BY price) WHERE ROWNUM < 20;
この例では、表はpriceによりパーティション化されており、最初のパーティションからのヒットを取得すれば問合せが満たされる可能性があります。
ローカル・パーティション索引に対してDOMAIN_INDEX_SORTヒントを使用すると、特にスコア順にした場合にパフォーマンスが大幅に低下することがあります。これは、結果をソートする前に、全パーティションにまたがる問合せの全ヒットを取得する必要があるためです。
パフォーマンスの低下を回避するには、DOMAIN_INDEX_SORTヒントを使用するときにインライン・ビューを使用します。DOMAIN_INDEX_SORTヒントを使用すると、次のような条件下で、ローカル・パーティション表の問合せパフォーマンスを向上させることができます。
SCORE()句による順序を含むテキスト問合せ自体がインライン・ビューとして表されている場合
インライン・ビュー内のテキスト問合せにDOMAIN_INDEX_SORTヒントが含まれている場合
インライン・ビューに対する問合せに、ビューからフェッチする行数を制限するROWNUM述語が含まれている場合
たとえば、次のテキスト問合せがあり、パーティション表doc_tabに対してローカル・テキスト索引が作成されているとします。
select doc_id, score(1) from doc_tab
where contains(doc, 'oracle', 1)>0
order by score(1) desc;
ここで、上位20行のみを取り出す場合は、この問合せを次のように再作成します。
select * from
(select /*+ DOMAIN_INDEX_SORT */ doc_id, score(1) from doc_tab
where contains(doc, 'oracle', 1)>0 order by score(1) desc)
where rownum < 21;
|
関連項目:
|
問合せがスループット向上のために最適化された場合は、すべてのヒットが最短時間で戻されます。これはデフォルトの動作です。
次の各項では、スループット向上のために明示的に最適化する方法を説明します。
デフォルトでは、問合せはCHOOSEモードおよびALL_ROWSモードでスループットが向上するように最適化されます。問合せがスループット向上のために最適化された場合は、Oracle Textによってすべての行が最短時間で戻されます。
FIRST_ROWS(n)モードでは、可能な場合、テキスト・ドメイン索引でスコア順にソートされた行が戻されるようにすることで応答時間を短縮するよう、Oracle Databaseのオプティマイザが最適化を行います。これは、FIRST_ROWS(n)ヒントを使用する場合のデフォルトの動作です。
FIRST_ROWS(n)でスループットがさらに向上するように最適化するには、DOMAIN_INDEX_NO_SORTヒントを使用します。スループットの向上とは、すべての行を最短時間で問合せに取り込むことです。
次の例では、スコア順にソートした行を戻すためにテキスト・ドメイン索引を使用せずにスループットを向上させています。かわりに、CONTAINS述語を満たすすべての行が索引から取り出された後で、Oracle Textによって行がソートされます。
select /*+ FIRST_ROWS(10) DOMAIN_INDEX_NO_SORT */ pk, score(1), col from ctx_tab
where contains(txt_col, 'test', 1) > 0 order by score(1) desc;
|
関連項目: 問合せオプティマイザの詳細、およびFIRST_ROWS(n)やCHOOSEなどのヒントの使用方法は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
Oracle Database 11gの拡張性フレームワークのコンポジット・ドメイン索引機能を使用すると、構造化された列をOracle Textで索引付けできます。したがって、テキストと1つ以上の構造化された条件の両方が、Oracle Textの単一の索引の行ソースによって満たされます。次のタイプの問合せのパフォーマンスが向上します。
SQL WHERE句内の、構造化された条件を持つテキスト問合せ
構造化されたORDER BY条件を持つテキスト問合せ
前述の2つの問合せタイプの両方の組合せ
連結されたBツリー索引やビットマップ索引と同様、FILTER BY列およびORDER BY列の数が増えるに従って、アプリケーションではDMLのパフォーマンスが低下します。SCOREによるソートのプッシュダウンが応答時間の短縮のために最適化されている場合、構造化されたソートまたはSCOREと構造化されたソートの組合せのプッシュダウンも同様に、スループットの向上ではなく応答時間の短縮のために最適化されます。ただし、DOMAIN_INDEX_SORTヒントまたはFIRST_ROWS(n)ヒントを使用してフェッチ中にCDIにソートを含めるよう強制した場合、ヒットリスト全体を表示するには問合せ応答時間が大幅にかかります。
FILTER BY列のMDATAへのマッピングがサポートされているため、RANGEおよびLIKEのサポートされた機能を制限することで、問合せのパフォーマンスは等価性検索に対して最適化されます。ただし、FILTER BY列が連続した値を含むかまたはそのカーディナリティが非常に高い場合は、FILTER BY列のMDATAへのマッピングはお薦めしません。このマッピングを実行した場合、非常に細長い$I表が作成され、$Xのパフォーマンスが低下します。このような連続した列の一例として、DATEスタンプを使用した場合があります。このような連続した列の場合は、SDATAへのマッピングをお薦めします。
SORT述語およびFILTER BY述語をCDIに含めるか含めないかには、次のヒントを使用できます。
DOMAIN_INDEX_SORT。問合せオプティマイザは、適用可能なソート条件を、指定したコンポジット・ドメイン索引に含めようとします。
DOMAIN_INDEX_NO_SORT。問合せオプティマイザは、ソート条件を、指定したコンポジット・ドメイン索引に含めないようにします。
DOMAIN_INDEX_FILTER(table name index name)。問合せオプティマイザは、適用可能なFILTER BY述語を、指定したコンポジット・ドメイン索引に含めます。
DOMAIN_INDEX_NO_FILTER(table name index name)。問合せオプティマイザは、適用可能なFILTER BY述語を、指定したコンポジット・ドメイン索引に含めないようにします。
例7-1 CDIヒントを使用したテキスト問合せのパフォーマンス・チューニング
次の例では、表booksに対し、最適化された問合せを実行しています。
SELECT bookid, pub_date, source FROM
(SELECT /*+ domain_index_sort domain_index_filter(books books_ctxcdi) */ bookid, pub_date, source
FROM books
WHERE CONTAINS(text, 'aaa',1)>0 AND bookid >= 80
ORDER BY PUB_DATE desc nulls last, SOURCE asc nulls last, score(1) desc)
WHERE rownum < 20;
|
注意: domain_index_filterヒントは、問合せオプティマイザにCDIの使用を強制しません。かわりに、コストベース・オプティマイザがCDIの使用を選択している場合は、フィルタ述語も索引に含められます。問合せオプティマイザにCDI索引の選択を強制するには、さらにINDEXヒントも使用する必要があります。 |
Oracle Textには、索引付けおよび問合せにおけるボトルネックを特定するためのトレース機能が備わっています。
Oracle Textには、事前定義済のトレースのセットが用意されています。各トレースは一意の番号で識別されます。また、この番号に対するCTX_OUTPUTの記号があります。
各トレースでは、特定の数量を測定します。たとえば、テキスト問合せ時に選択される$I行の数などです。
トレースは累積カウンタです。そのため、使用方法は次のようになります。
ユーザーがトレースを使用可能にします。
ユーザーが複数の操作を実行します。Oracle Textではアクティビティを測定し、トレースの結果を累積します。
ユーザーがトレース値を取得します。これは、手順2で実行されたすべての操作の合計値となります。
ユーザーがトレースを0(ゼロ)に再設定します。
ユーザーが手順2を繰り返します。
このため、たとえば、手順2でユーザーが2つの問合せを実行し、問合せ1で$Iから15行を選択し、問合せ2で$Iから17行を選択した場合、手順3ではトレースの値は32(15 + 17)となります。
トレースは1つのセッションに関連付けられています。トレースは、1つのセッション内で発生した演算を測定できますが、反対に、複数のセッション間で測定を行うことはできません。
パラレル同期化または最適化中に、トレーシングが現在使用可能である場合のみ、トレース・プロファイルはスレーブ・セッションにコピーされます。各スレーブでは、独自のトレースを累積し、終了前にすべてのトレース値を暗黙的にスレーブ・ログ・ファイルに書き込みます。
|
関連項目: 『Oracle Textリファレンス』 |
一般に、パラレル問合せは、大規模なデータ・コレクションと複数のCPUを備え、同時ユーザー数が少ないDSS、OLAPまたは分析システムに最も適しています。または、Oracle Real Application Clusters(Oracle RAC)ノード間でパラレル化されます。
Oracle Textでは、次のようにパラレル問合せをサポートしています。
パラレル問合せは、ローカルのCONTEXT索引のパラレル処理を指します。索引の並列度と様々なシステム属性に基づいて、Oracleにより、索引処理のために起動されるパラレル問合せスレーブの数が決定されます。各パラレル問合せスレーブが、1つ以上の索引パーティションを処理します。これは、パラレルに作成されたローカル索引のデフォルトの問合せ動作です。
ただし、同時ユーザー数が多く負荷の高いシステムで問合せが連続的に実行される場合は、通常上位N個のヒットが最初の数個のパーティションによって満たされるため、問合せのスループットはパラレル問合せによって一般に低下します。たとえば、次のような、ORDER BYパーティション・キー列を持つ典型的な上位N個のテキスト問合せでは、
select * from (
select story_id from stories_tab where contains(...)>0 order by
publication_date desc)
where rownum <= 10;
通常、パラレル問合せを使用するとパフォーマンスが下がります。
ALTER INDEX文を次のように使用して、パラレル索引の操作後にパラレル問合せを使用禁止にできます。
Alter index <text index name> NOPARALLEL; Alter index <text index name> PARALLEL 1;
次のように指定すると、パラレル問合せを使用可能にするか、並列度を上げることができます。
Alter index <text index name> parallel < parallel degree >;
Oracle Textのパフォーマンスを上げるためにOracle Real Application Clusters(Oracle RAC)を使用するかどうかを考慮する場合、解決しようとしているのがどのパフォーマンス問題であるかを理解することが重要です。Oracle RACは、問合せのスループットを向上するためには非常に有効な解決策です。Oracle Textで問合せの負荷が軽く良好なパフォーマンスが得られる場合は、問合せの負荷が増えた場合、Oracle RACによる優れた拡張性を期待できます。
Oracle RAC環境におけるOracle Textのパフォーマンスは、(ローカル・パーティション索引を使用して)テキスト・データとテキスト索引を物理的にパーティション化し、各パーティションが個別のOracle RACノードで処理されるようにすると、さらに向上する場合があります。この方法で、複数のノード間でのキャッシュ・コンテンツの重複を回避することにより、Oracle RAC Cache Fusionのメリットを最大限に活用できます。
Oracle 10gリリース1では、索引の作成時に、Oracle Textの各索引パーティションが個別のデータベース・ファイルに格納される必要があります。これにより、Oracle RACの再マスタリング機能を使用できるようになり、データベース・ファイルのアフィニティが適用されるため、各ノードは特定のデータベース・ファイル、つまり特定のOracle Text索引パーティションに集中します。
Oracle 10gリリース2およびそれ以降では、データベース・オブジェクト・レベルのアフィニティがサポートされています。これにより、索引オブジェクト($I表および$R表)の特定ノードへの割当てが大幅に容易になっています。
Oracle RACは問合せのスループットとパフォーマンスを向上させるソリューションを提供していますが、あらゆる場合に効果があるわけではなく、データの容量が増加しても常に同じパフォーマンス向上が見込めるわけではありません。パフォーマンスの向上を図るには、SGAキャッシュに使用できるメモリー量を増やすか、データをパーティション化して、問合せで表の全パーティションをヒットせずに必要な問合せ結果セットを通常提供できるようにします。
複数の述語を持つ問合せを発行すると、実行計画でブロック操作が行われる場合があります。たとえば、次の複合問合せについて考えます。
select docid from mytab where contains(text, 'oracle', 1) > 0 AND colA > 5 AND colB > 1 AND colC > 3;
すべての述語が非選択的で、colA、colBおよびcolCがビットマップ索引を持つと想定します。Oracle Databaseのコストベース・オプティマイザでは、次の実行計画を選択します。
TABLE ACCESS BY ROWIDS
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP INDEX COLA_BMX
BITMAP INDEX COLB_BMX
BITMAP INDEX COLC_BMX
BITMAP CONVERSION FROM ROWIDS
SORT ORDER BY
DOMAIN INDEX MYINDEX
BITMAP ANDはブロック操作であるため、Oracle Textでは、BITMAP AND操作を実行する前に、Oracle Textのドメイン索引から戻されたROWIDとスコアのペアを一時的に保存する必要があります。
Oracle Textでは、これらのROWIDとスコアのペアをメモリーに保存しようとします。ただし、これらのROWIDとスコアのペアを含む結果セットのサイズがSORT_AREA_SIZE初期化パラメータの値を超える場合は、Oracle Textにより、これらの結果がディスク上の一時セグメントに排出されます。
ディスクに結果を保存すると余分なオーバーヘッドが発生するため、次のようにALTER SESSIONを使用してSORT_AREA_SIZEパラメータを増やすことによって、パフォーマンスが向上します。
alter session set SORT_AREA_SIZE = <new memory size in bytes>;
たとえば、バッファを約8MBに設定するには、次の文を入力します。
alter session set SORT_AREA_SIZE = 8300000;
|
関連項目: SORT_AREA_SIZEの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseリファレンス』を参照してください。 |
この項では、問合せのパフォーマンスに関してよくある質問と、それに対する回答を提供します。
回答: 問合せのパフォーマンスは、一般的に次の2つの基準で判断します。
応答時間。個々の問合せに対する応答を取得するまでの時間です。
スループット。任意の時間内に実行可能な問合せの数(たとえば、1秒当たりの問合せ数)です。
この2つは関連していますが、同一ではありません。通常、負荷の高いシステムでは高いスループットが必要ですが、比較的負荷の低いシステムではレスポンス時間を最短にすることが必要になります。また、問合せの全ヒットをユーザーに戻す必要があるアプリケーションもあれば、順序付け済セットの最初の20ヒットのみを戻すだけでよいアプリケーションもあります。この2つの状況を区別することが重要です。
回答: 最速タイプの問合せは、次の条件を満たす問合せです。
単一のCONTAINS句。
WHERE句内に他の条件がない。
ORDER BY句が存在しない。
結果の最初のページのみが戻される(たとえば、最初の10ヒットまたは20ヒット)。
回答: はい。表に関する統計を収集しておくと、Oracle Textがコストベースの分析を実行できます。これにより、問合せに最も効率的な実行計画をOracle Textが選択できます。
問合せが常に簡単なテキスト問合せ(構造化述語および結合がない)の場合、Oracle Text索引の統計を削除する必要があります。
回答: テキスト索引がROWIDを戻す速度は、データの実際のサイズには影響されません。テキスト問合せの速度は、索引表からフェッチする必要のある行数、要求されるヒット数、問合せにより生成されるヒット数、およびソートの有無に関係します。
回答: ドキュメントの形式(ASCIIプレーン・テキスト、HTMLまたはMicrosoft Word)は、問合せ速度には影響しません。ドキュメントは、問合せ時ではなく索引付け時にプレーン・テキストにフィルタ処理されます。
データがクリーンであるかどうかが、問合せに影響します。スペルチェック済で編集作業が行われた出版用のテキストは、スペルミスや略語の多い電子メールなどの非公式のテキストと比べて、合計語彙数がかなり少なくなる傾向にあります(したがって、索引表のサイズも小さくなります)。指定した索引メモリー設定では、余分なテキストがあるとメモリー使用量が多くなり、クリーンなテキストと比べて断片化される行が増え、問合せの応答時間に悪影響を及ぼす可能性があります。
回答: カーネルがテキスト索引に対して問合せを行う方法は2つあります。1つ目は、カーネルがテキスト索引に対して特定のテキスト検索を満たすすべてのROWIDを問い合せる方法であり、これが最も一般的です。これらのROWIDはまとめて戻されます。2つ目の方法では、カーネルが個々のROWIDをテキスト索引に渡し、その特定のROWIDが特定のテキスト基準を満たしているかどうかを問い合せます。
2つ目の方法は機能的検索と呼ばれ、選択性の高い構造の句が存在する場合はこの方法を使用すると、テキスト索引に対してチェックが必要なROWIDの数はわずかです。機能的検索を使用できる検索の例は、次のとおりです。
SELECT ID, SCORE(1), TEXT FROM MYTABLE
WHERE START_DATE = '21 Oct 1992' <- highly selective AND CONTAINS (TEXT, 'commonword') > 0 <- unselective
構造化列(たとえば、日時や価格など)でORDER BYを行い、テキスト問合せが非選択的な場合にも、機能的検索が使用されます。
回答: すべての問合せで、索引トークン表が参照されます。この表の名前は、DR$indexname$Iの形式です。この表には、トークンのリスト(TOKEN_TEXT列)とトークンが発生する行とワードの位置に関する情報(TOKEN_INFO列)が含まれます。
行情報は内部DOCID値として格納されます。これらは外部ROWID値に変換する必要があります。これに使用される表は、検索のタイプによって決まります。機能的検索の場合は、$K表DR$indexname$Kが使用されます。これは、DOCID/ROWIDの各ペアに対する1行を含む、単純な索引構成表(IOT)です。
索引付き検索の場合は、$R表(DR$indexname$R)が使用されます。この表のBLOB列にはROWIDの完全なリストが保持されます。
このため、SQLトレースを調べて$K表または$R表を検索すれば、機能的検索と索引付き検索のどちらが使用されているかが容易に判断できます。
|
注意: これらの内部索引表は、リリースごとに変更されることがあります。アプリケーションではこれらの表に直接アクセスしないことをお薦めします。 |
回答: はい。低下します。
ソートしない場合、Oracle Textは検索したままの結果を戻すことができます。通常、アプリケーションでは結果を一度に1ページずつ表示するため、この方が高速です。
回答: 関連性スコア(SCORE(n))によるソートは、FIRST_ROWS(n)ヒントを使用すると、非常に高速になります。この場合、Oracle Textはテキスト索引表からフェッチするときに高速の内部ソートを実行します。
このような問合せの例を次に示します。
SELECT /*+ FIRST_ROWS(10) */ ID, SCORE(1), TEXT FROM mytable
WHERE CONTAINS (TEXT, 'searchterm', 1) > 0
ORDER BY SCORE(1) DESC;
これを効率的に行うには、1つのCONTAINS以外の条件をWHERE句に含めないでください。
回答: 問合せを行うには、大規模なシステム・グローバル領域(SGA)を取得する必要があります。SGA関連のパラメータは、Oracle Database初期化ファイルに設定できます。これらのパラメータは動的に設定することもできます。
SORT_AREA_SIZEパラメータは、ORDER BY問合せのソートで使用可能なメモリーを制御します。構造化列で頻繁にORDER BYを行う場合は、このパラメータのサイズを増やす必要があります。
|
関連項目:
|
回答: はい。一般に、SELECT文は元表から複数の列を選択します。Oracle Textでは列をメモリーにフェッチするため、特にこれらの列がほとんど更新されないのに頻繁に選択されるような場合は、元表のLOBなどの長い列は表外に格納する方が効率的です。
LOBを表外に格納するとき、問合せ中にメモリーにフェッチする必要があるのはLOBロケータのみです。表外に格納すると、元表の有効なサイズが減少し、Oracle Textで表全体をメモリーにキャッシュしやすくなります。これにより、元表から列を選択するコストが低減し、テキスト問合せが高速になります。
さらに、メモリーにキャッシュされる元表が小さくなれば、問合せ中により多くの索引表データをキャッシュできるため、パフォーマンスが向上します。
回答: 最も高速の問合せタイプは、WHERE句にCONTAINS句が1つあるのみで、その他の条件が含まれていない問合せです。
複数のCONTAINSを含む次の問合せについて考えます。
SELECT title, isbn FROM booklist
WHERE CONTAINS (title, 'horse') > 0
AND CONTAINS (abstract, 'racing') > 0
セクション検索とWITHIN演算子を次のように使用すると、同じ結果が得られます。
SELECT title, isbn FROM booklist
WHERE CONTAINS (alltext,
'horse WITHIN title AND racing WITHIN abstract')>0
この問合せは、さらに高速になります。このような問合せを使用するには、各列のデータをセクション・タグで囲んで、索引付けのためにすべてのデータを1つのテキスト列にコピーする必要があります。これを実行するには、索引付けの前にPL/SQLプロシージャを使用するか、索引付け時にUSER_DATASTOREデータソースを利用して、構造化列とテキスト列を1つのドキュメントに統合します。
回答: 問合せに使用されるワードごとに、索引表から少なくとも1行をフェッチする必要があります。このため、拡張の数はできるだけ少なくします。
ワイルド・カード、シソーラス、ステミングおよびファジー・マッチングなどの拡張は、作業上必要でないかぎり、使用しないようにします。一般的に、問合せに少数の拡張(たとえば10から20)は許容されますが、多数の拡張(80または100)は使用しないでください。問合せ式の拡張の数を判断するには、問合せフィードバック・メカニズムを使用できます。
さらに、ワイルド・カードおよびステミングの問合せの場合は、プリフィックス、サブストリングまたはステム索引を作成すると、問合せ時から索引付け時への語句拡張コストをなくすことができます。問合せのパフォーマンスは上がりますが、索引付けの時間が長くなり、ディスク領域が大きくなります。
プリフィックス索引およびサブストリング索引により、ワイルド・カードのパフォーマンスが向上します。プリフィックスとサブストリングの索引付けは、BASIC_WORDLISTプリファレンスを使用して使用可能にします。次の例では、プリフィックスとサブストリングの索引付けに対してワードリスト・プリファレンスを設定します。プリフィックス索引付けについては、Oracle Textで3から4文字の長さのトークン・プリフィックスを作成するように指定します。
begin
ctx_ddl.create_preference('mywordlist', 'BASIC_WORDLIST');
ctx_ddl.set_attribute('mywordlist','PREFIX_INDEX','TRUE');
ctx_ddl.set_attribute('mywordlist','PREFIX_MIN_LENGTH', '3');
ctx_ddl.set_attribute('mywordlist','PREFIX_MAX_LENGTH', '4');
ctx_ddl.set_attribute('mywordlist','SUBSTRING_INDEX', 'YES');
end
ステム索引付けは、BASIC_LEXERプリファレンスを使用して使用可能にします。
begin
ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
ctx_ddl.set_attribute ( 'mylex', 'index_stems', 'ENGLISH');
end;
回答: ローカル・パーティションCONTEXT索引は、パーティション表に対して作成できます。つまり、パーティション表上では、各パーティションに独自の索引表セットがあることを意味します。実際には複数の索引がありますが、各索引からの結果が必要に応じて組み合され、最終的な結果セットが生成されます。
この索引は、LOCALキーワードを使用して作成します。
CREATE INDEX index_name ON table_name (column_name)
INDEXTYPE IS ctxsys.context
PARAMETERS ('...')
LOCAL
パーティション表およびローカル索引を使用すると、次のタイプのCONTAINS問合せのパフォーマンスが向上します。
これは、パーティション・キー列の特定の値範囲に検索を限定する問合せです。
これは、最初のn個のヒットのみが必要で、ORDER BY句がパーティション・キーを指定する問合せです。
回答: システム負荷およびサーバー容量により異なります。パラレルに作成された索引の場合にはパラレル問合せがデフォルト動作ですが、通常、負荷の高いシステムでは問合せの全体的なスループットが低下します。
一般に、パラレル問合せは、大規模なデータ・コレクションと複数のCPUを備え、同時ユーザー数が少ないDSSや分析システムに特に適しています。
回答: テーマ情報にCONTEXT索引で索引付けすると、時間がかかり、索引のサイズも大きくなります。ただし、テーマ索引を使用すると、ナレッジ・ベースが(使用可能な場合は)使用され、ABOUT問合せの精度が上がります。アプリケーションでABOUT問合せが頻繁に使用される場合は、索引に対してテーマ・コンポーネントを作成してみる価値はあります。ただし、索引の作成時間と記憶領域が余分に必要になります。
回答: CTXCAT索引は、テキストが小さなチャンク(最大で数行)になっており、特定の構造化基準(通常は数値または日付)に従って、検索で結果セットを制限またはソートする必要がある場合(あるいはその両方)に、最も効率的に機能します。
たとえば、オンラインのオークション・サイトについて考えます。各競売対象品目には、短い説明、現在の入札価格、オークションの開始日と終了日が含まれています。この場合、説明に「antique cabinet」が含まれていて、現在の入札価格が$500未満の全レコードを表示するとします。ユーザーが新しく提示される商品に特に興味がある場合は、結果をオークション開始日でソートする必要があります。
このような検索では、CONTEXT索引に対してCONTAINS構造化問合せを行っても、構造化句およびCONTAINS句に応じてレスポンス時間が大きく異なるため、必ずしも効率的ではありません。これは、構造化句とCONTAINS句の共通部分またはテキスト問合せの順序付けが問合せ時に計算されるためです。
価格や日付などの構造化情報をCTXCAT索引内に含めると、検索条件にかかわらず、問合せ応答時間は常に最適な範囲内にとどまります。これは、テキストと構造化問合せ間の相互作用が、索引付け時に事前に計算されるためです。この結果、問合せ応答時間が最適になります。
回答: 索引作成に要する時間と領域に違いがあります。CTXCAT索引はCONTEXT索引と比べて作成に時間がかかり、使用するディスク領域もかなり多くなります。ディスク領域に余裕がない場合は、CTXCAT索引が適切かどうかを慎重に考慮する必要があります。
問合せ演算子に関しては、CATSEARCH問合せでは問合せテンプレートを使用して、より豊富なCONTEXT文法を使用できるようになっています。CATSEARCH問合せ文法のみを使用する必要があるという古い制限はなくなりました。
回答: オプティマイザ・ヒントINDEX(table column)を通常の方法で使用すると、テキスト索引またはBツリー索引を使用した問合せを実行できます。
NO_INDEX(table column)ヒントを使用すると、特定の索引を使用禁止にすることもできます。
さらに、テキスト問合せではFIRST_ROWS(n)ヒントが特殊な意味を持ち、問合せで最初のn個のヒットが必要な場合に使用できます。DOMAIN_INDEX_SORTヒントをORDER BY SCORE(n) DESCとともに使用すると、Oracleオプティマイザは、ソート済のセットをテキスト索引から受け入れ、それ以上のソートを実行しないように指示されます。
この項では、索引付けのパフォーマンスに関してよくある質問と、それに対する回答を提供します。
回答: テキストの索引付けは、リソース集中型の処理です。索引付けの速度は関連するハードウェアの性能に依存します。索引付けの速度はCPUおよびI/O容量により異なります。元のデータの読込みや索引エントリの書込みに十分なI/O容量がある場合、CPUが制限要素となります。
Intel x86(Core 2アーキテクチャ、2.5GHz)CPUを使用したテストでは、Oracle Textでは1日当たりCPUコアごとに約100GBのテキストを索引付けできました。CPUのクロック速度が増すかCPUアーキテクチャがさらに効率的(あるいはその両方)になると、処理量が増えることが予想されます。
ドキュメント形式、データの場所、ユーザー定義データストアのコール、フィルタ、レクサーなどのその他の要因も、索引付けの速度に影響します。
回答: 索引メモリーは、システム・パラメータDEFAULT_INDEX_MEMORYおよびMAX_INDEX_MEMORYを使用して設定できます。また、CREATE INDEXのパラメータ文字列にmemoryパラメータを指定して、索引メモリーを実行時に設定することもできます。
DEFAULT_INDEX_MEMORY値は、ページングが発生しない範囲で、できるだけ高く設定するようにします。
SORT_AREA_SIZEシステム・パラメータを増やして、索引付けのパフォーマンスを向上させることもできます。
索引メモリーの設定を大きくすることをお薦めします。数百MBまで設定を大きくすると、索引付けの速度が上がり、最終的な索引の断片化が減少します。ただし、索引メモリー設定を高くしすぎると、メモリーのページングが発生し、索引付けの速度が低下します。
索引のパラレル作成では、各プロセスがそれぞれ索引付け用のメモリーを必要とします。巨大な表を扱う場合には、索引作成時と検索時とで、システム・グローバル領域(SGA)のチューニング方法を変えます。問合せでは、システム・グローバル領域(SGA)のブロック・バッファ・キャッシュにできるだけ多くの情報をキャッシュするようにします。このため、ブロック・バッファ・キャッシュには大量のメモリーを割り当てる必要があります。ただし、この設定は索引付けには影響を与えないため、索引作成時には、SGAのサイズを減らして、索引付け処理中の索引メモリー設定を大きくする方が賢明です。
SGAのサイズはOracle Database初期化ファイルで設定します。
|
関連項目:
|
回答: オーバーヘッド(索引表に必要な領域の量)は、元のテキスト量の50%から200%までの範囲で様々です。一般に、テキストの総量が多いほどオーバーヘッドは小さくなりますが、小さなレコードが多数あるほうが、大きなレコードが少数あるよりもオーバーヘッドの消費が大きくなります。また、電子メールや討論記録のような未処理のデータにはスペルミスや略語などの特異なワードが数多く含まれている可能性が高いため、クリーンなデータ(出版されたテキストなど)のほうが未処理のデータよりも必要なオーバーヘッドが小さくなります。
テキストのみの索引は、テキストとテーマを組み合せた索引よりも小さくなります。プリフィックス索引およびサブストリング索引では、索引がかなり大きくなります。
回答: Microsoft Wordファイルのように形式設定されたドキュメントの場合は、ドキュメントに含まれる実際のテキストに比べてサイズが大きくなる傾向があるため、記憶域オーバーヘッドはかなり低くなります。したがって、1GBのWordドキュメントに必要な索引領域が50MBのみであるのに対し、1GBのプレーン・テキストに必要な索引領域は500MBになることがあります。
索引付けに要する時間については、これほど単純ではありません。索引付け対象のテキスト量が減れば明らかな影響は出ますが、索引付けに要する時間を見積るためには、AUTO_FILTERフィルタまたはその他のユーザー定義フィルタを使用してドキュメントをフィルタ処理する時間を相殺することが必要になります。
回答: データが大量にあり、CPUも複数ある場合は、パラレル索引付けにより、索引付けのパフォーマンスが向上します。
索引を作成するときに、次のようにPARALLELキーワードを使用します。
CREATE INDEX index_name ON table_name (column_name)
INDEXTYPE IS ctxsys.context PARAMETERS ('...') PARALLEL 3;
これで、リソースに応じて最大3つの索引付けプロセスを使用して索引が作成されます。
また、パラレル索引付けを使用して、パーティション表のローカル・パーティション索引を作成することもできます。ただし、CPUが複数あるときのみ、索引付けのパフォーマンスは向上します。
|
注意: ローカル・パーティション索引を作成するのにPARALLELを使用すると、パラレル問合せが有効になります。(非パーティション索引をパラレルに作成しても、問合せはパラレルに処理されません。)
パラレル問合せにより、特に負荷の高いシステムでは、問合せのスループットが低下します。このため、パラレル索引作成後はパラレル問合せを使用禁止にすることをお薦めします。この場合は、 |
回答: CPUが複数あるときは、ローカル索引をパラレルで作成することで索引付けのパフォーマンスを改善できます。索引付けをパラレルで行うには、次の2つの方法があります。
ローカル・パーティション索引をパラレルで作成するには、次の2つの方法があります。
CREATE_INDEXで、LOCAL句とともにPARALLEL句を使用します。この場合、最大並列度はユーザーが持つパーティションの数によって制限されます。
使用禁止の索引を最初に作成し、次にDBMS_PCLXUTIL.BUILD_PART_INDEXユーティリティを実行します。このメソッドを使用すると、特にパーティション数以上のCPUがある場合に、並列度が高くなります。
2つ目の方法の例を次に示します。この例の元表には3つのパーティションがあります。まず使用禁止のローカル・パーティション索引を作成してから、DBMS_PCLUTIL.BUILD_PART_INDEXを実行すると、3つのパーティションがパラレルに作成されます(パーティション間並列性)。また、各パーティション内では、索引作成が並列度2でパラレルに実行されます(パーティション内並列性)。
create index tdrbip02bx on tdrbip02b(text)
indextype is ctxsys.context local (partition tdrbip02bx1,
partition tdrbip02bx2,
partition tdrbip02bx3)
unusable;
exec dbms_pclxutil.build_part_index(3,2,'TDRBIP02B','TDRBIP02BX',TRUE);
この項では、索引の更新と関連するパフォーマンスの問題に関してよくある質問と、それに対する回答を提供します。
回答: CTX_DLL.SYNC_INDEXを使用して再索引付けを実行する頻度が低いほど、索引の断片化が少なくなり、索引の最適化を実行する頻度も低く抑えることができます。
ただし、これではデータが次第に古くなるため、ユーザーにとっては不便になる可能性があります。
ほとんどのシステムでは、毎日の夜間の索引付けで対応可能です。この場合、作成されてから1日未満のデータは検索できないということになります。毎時、10分ごとまたは5分ごとに更新を行うシステムもあります。
