索引の最適化

索引の同期化を頻繁に行うと、最終的にCONTEXT索引が断片化します。索引の断片化は、問合せ応答時間に悪影響を与える場合があります。したがって、索引の断片化を減少させ、最善の問合せパフォーマンスを実現するために、時間をおいてCONTEXT索引を最適化する必要があります。索引の最適化を理解するには、索引の構造と同期化の内容を理解する必要があります。

この項では、次の項目について説明します。

CONTEXT索引の構造

CONTEXTCONTEXT索引は、各ワードにそのワードを含むドキュメントのリストが格納された逆向きの索引です。たとえば、初期の索引付け操作が1つ終了すると、ワードDOGのエントリは次のようになります。

DOG DOC1 DOC3 DOC5

索引の断片化

新しいドキュメントが元表に追加されると、索引は新しい行の追加によって同期化されます。たとえば、ワードdogを含む新しいドキュメント(DOC 7など)を元表に追加し、索引を同期化すると、次のようになります。

DOG DOC1 DOC3 DOC5
DOG DOC7

続くDML操作によって、新しい行が次のように作成されるとします。

DOG DOC1 DOC3 DOC5
DOG DOC7
DOG DOC9
DOG DOC11

新しいドキュメントの追加と索引の同期化は、索引の断片化の原因になります。特に、バックグラウンドDMLの場合は索引を頻繁に同期化するため、一般的に、バッチ・モードでの同期化に比べて断片化が増加します。

バッチ処理の頻度を少なくすると、ドキュメント・リストが長くなり、索引内の行数も減ります。したがって、断片化も減少します。

CTX_DDL.OPTIMIZE_INDEXを使用して、FULL(完全)またはFAST(高速)モードで索引を最適化すると、索引の断片化を減少させることができます。

ドキュメントの無効性とガベージ・コレクション

ドキュメントを元表から削除すると、Oracle Textでは、そのドキュメントに削除済のマークが設定されます。ただし、索引は即時に変更されません。

古い情報が領域を占有していると問合せ時に余分なオーバーヘッドが発生するため、索引をFULLモードで最適化して古い情報を削除する必要があります。この処理はガベージ・コレクションと呼ばれます。元表に対する更新または削除を頻繁に行う場合は、ガベージ・コレクションのためにFULLモードで最適化を行う必要があります。

単一のトークンの最適化

索引全体の最適化以外に、単一のトークンも最適化できます。トークン・モードを使用すると、参照頻度の低いトークンの最適化に時間をかけずに、検索頻度の高い索引トークンを最適化できます。

たとえば、トークンDOGの更新と問合せが頻繁に行われる場合、索引内のこのトークンのみの最適化を指定できます。

トークンを最適化すると、そのトークンの問合せ応答時間が短縮できます。

索引の最適化を単一のトークンで行うには、CTX_DDL.OPTIMIZE_INDEXを使用します。

索引の断片化およびガベージ・データの表示

CTX_REPORT.INDEX_STATSプロシージャを使用すると、索引の統計レポートを作成できます。このレポートには、最適な行の断片化に関する情報、最も断片化されているトークン、および索引内のガベージ・データの量が含まれています。大規模な索引の場合はこのレポートの実行に時間がかかることがありますが、このレポートは索引を最適化する必要があるかどうかの判断に役立ちます。

例: 索引の最適化

索引を最適化する場合は、CTX_DDL.OPTIMIZE_INDEXを使用することをお薦めします。