SQL Server 2005 のフルテキスト検索機能 : 内部構造と強化機能について

  • [アーティクル]

Andrew Cencini
Microsoft Corporation

December 2003

対象 :
   Microsoft® SQL Server 2005
   Transact-SQL (T-SQL) 言語

概要 : 開発者とデータベース管理者向けに SQL Server 2005 のフルテキスト検索機能の長所と新機能を説明します。

目次

はじめに
フルテキスト検索機能について
フルテキスト検索のアーキテクチャ
データベース管理者向けの新機能
開発者向けの新機能
まとめ
関連資料

はじめに

Microsoft SQL Server 2005 のフルテキスト検索機能では、エンタープライズ レベルの検索機能がデータベースで利用できるようになりました。 パフォーマンス、管理の容易性、および機能が大幅に強化されたことにより、どんなサイズのアプリケーションでも最適な検索機能を実現できます。

この資料の対象読者は、データベース管理者と開発者です。 まず、フルテキスト検索機能の概要とアーキテクチャについて説明し、その後、重要な強化機能と新機能の詳細を説明します。

フルテキスト検索機能について

フルテキスト検索を使用すると、SQL Server データベースに格納されているテキスト データに高速かつ柔軟にインデックスを作成して、キーワード ベースでデータをクエリできるようになります。 LIKE 述語は文字列パターンにしか対応していませんが、フルテキスト検索のクエリでは、データベースに格納されているデータに対して特定の言語のルールに基づいて単語や語句に対応する言語検索を実行できます。

フルテキスト検索の使用によるパフォーマンスの向上は、構造化されていない大量のテキスト データに対してクエリを実行する際に最も実感できるでしょう。 数万行ものテキスト データに対して LIKE クエリ ('%cencini%' など) を実行すると、クエリ結果が表示されるまでに数分かかりますが、同じデータに対してフルテキスト クエリ ('cencini') を実行した場合、クエリ結果は (返される行数によって異なりますが) 数秒またはそれ以下の時間で表示されます。

フルテキスト インデックスは、テキスト データが含まれている列だけでなく、BLOB 型の列に格納されている Microsoft® Word 文書などの書式設定されたバイナリ データにも構築できます。

テキスト形式のデータをデータベースに格納して管理するという慣習が普及するにつれて、さまざまなアプリケーションでフルテキスト検索の機能を使用する機会が増えてきました。 通常、フルテキスト検索は、(Web サイト、製品カタログ、ニュース アイテム、その他のデータを検索する) Web ベースのアプリケーション、ドキュメント管理システム、SQL Server データベースのデータを検索する機能を提供する必要があるカスタム アプリケーションなどで使用されています。

SQL Server 2005 のフルテキスト検索には拡張性があり、比較的少数で単純なクエリしか使用しない小規模なモバイルや個人的な用途から、膨大な量のテキスト データに対して多数の複雑なクエリを実行する高度な基幹業務アプリケーションまで幅広い用途で使用できます。 フルテキスト検索には統合された管理機能と使いやすい Transact-SQL クエリの構文が用意されているので、検索機能を提供するアプリケーションを容易に、かつすばやく構築することができます。

また、フルテキスト検索は拡張性の高い機能です。 サードパーティ ベンダの単語区切りや語幹検索を追加すれば、フルテキスト エンジンのインデックスとクエリで追加の言語がサポートされるようになります。また、フルテキスト エンジンでは、多数のサードパーティ製のフィルタがサポートされており、追加のドキュメント形式をフィルタ選択することもできます。 公開されている一連の著名なインターフェイスでは、フルテキスト エンジンを拡張するためのフレームワークが提供されています。詳細については、MSDN トピック「IFilter」(英語)、「IWordBreaker」(英語)、 および「Istemmer」(英語) を参照してください。

つまり、SQL Server に格納されているテキスト形式のデータを管理するアプリケーションで、フルテキスト検索を使用すると、データベース プラットフォームに高速で堅牢なエンタープライズ クラスの検索機能を統合できるという大きな付加価値を得られる場合があります。

フルテキスト検索のアーキテクチャ

SQL Server のフルテキスト検索は、Microsoft Full-Text Engine for SQL Server (MSFTESQL) によって機能しています。 また、このエンジンは Microsoft Search (MSSearch) テクノロジに基づいてビルドされたもので、以前よりも密接に SQL Server 2005 データ-ベース エンジンと統合されています。 SQL Server 2005 リリースのアーキテクチャ上の最大の強化点は、複数のフルテキスト エンジンをサイド バイ サイドでインストールできることです。 つまり、SQL Server 2005 のインスタンスごとに、専用の MSFTESQL が存在するようになりました。これには、インスタンス レベルで専用のコンポーネント (単語区切りやフィルタ)、リソース (メモリなど)、および構成 (resource_usage などのサービス レベルの設定) が含まれます。

(以前のバージョンの SQL Server のフルテキスト検索エンジンは、すべての SQL Server のインスタンスで共有されていました。その上、このフルテキスト検索エンジンは、オペレーティング システムや Exchange、SharePoint Portal Server など他のマイクロソフト製品とも共有されていました。 このアプローチでは、MSSearch を使用しているオペレーティング システムや他の製品に更新プログラムを適用した場合、MSSearch を使用している他のすべての製品に大きな影響や好ましくない影響が及ぶことがありました。)

では、SQL Server 2005 のフルテキスト検索について詳しく見てみましょう。

インデックス作成

フルテキスト インデックスは、フルテキスト エンジンにより構築および管理されている特殊なトークン ベースの機能上のインデックスです。 フルテキスト インデックスの構築プロセスは、他の種類のインデックスを構築するプロセスとは異なります。 フルテキスト インデックスの構築プロセスでは、特定の行に格納されている値に基づいて B-tree 構造を構築するのではなく、MSFTESQL により、インデックスを作成したテキストの個別のトークンに基づいて反転、スタック、および圧縮されたインデックスの構造が構築されます。

インデックスの構造

フルテキスト インデックスの構造を十分に理解すると、フルテキスト エンジンの機能を理解するのに役立ちます。 基本的なフルテキスト インデックスを表形式で表示した例を見てみましょう。

**注   **実際のフルテキスト インデックスには、この表に示したデータ以外の情報が含まれています。 この表は、説明用に作成したものです。

Keyword ColId DocId Occ
token1 1 1 1
token1 1 1 5
token1 1 2 2
token1 2 1 1
token2 1 1 5
token2 2 4 11
(など) ... (など) ... (など) ... (など) ...

Keyword 列は、インデックス作成時に取得した単一のトークンに相当します。 トークンの構成要素は、"単語区切り" という名前のフルテキスト エンジンのコンポーネントにより決まります。 フルテキスト検索でサポートされている各言語では、その言語の単語の区切り目のルールに基づいてテキスト ストリームを個別のトークンに分割する単語区切りがあります。

ColId 列は、フルテキスト インデックスが作成された特定のテーブルと列に対応する数値です。 1 つのフルテキスト カタログには複数のテーブルや列が格納されることがあります。ColId 値は、クエリの対象範囲をフルテキスト クエリで指定されたテーブルと列のキーワードに限定するために使用されます。

Keyword/ColId ペアの DocId 値は、フルテキスト インデックスが作成されたテーブルの特定のフルテキスト キー値にマップされます。 検索条件を満たす DocId 値がフルテキスト エンジンからデータベース エンジンに渡され、これらの値はクエリ対象のベース テーブルのフルテキスト キー値にマップされます。

注   DocId 値は、内部では圧縮可能な 4 バイトの integer 型の値として表されており、フルテキスト キーのデータ型と異なる場合があります。 そのため、SQL Server 2005 では、1 つのフルテキスト カタログでインデックスを作成できる行数の上限は約 2,000,000,000 行になります。

Occ 列は、リストのリストです。各 DocId 値には、その DocId 値内で特定のキーワードの相対オフセットに対応する発生回数値のリストがあります。 発生回数値は、語句または近くにある単語を検索したり、関連性のスコアを計算したりする場合に役立ちます。たとえば、語句の場合は発生回数値が数値的に近い値になり、スコアの計算には、DocId の発生回数値や特定のフルテキスト インデックスを使用できます。

既に説明したように、DocId 値と Occ 値が圧縮される第一の理由は、クエリ時の使用領域や I/O の負荷を抑えるためです。 インデックス作成プロセスでは、一定サイズのインデックスのフラグメントが生成され、これらのフラグメントは定期的にマージされ、大きなマスタ インデックスになります。この処理を行わないと、この特別なキーが設定された圧縮構造にインデックスを挿入するタスクを、各行で数千回行うことになり、インデックス挿入のコストが非常に高くなります。

フルテキスト インデックスの構造の概略はつかめたと思うので、今度は、SQL Server 2005 のフルテキスト検索では、どのようにデータベースに格納されている膨大な量のテキスト データを処理して、データにフルテキスト インデックスを構築できるようになったかについて説明しましょう。

インデックス作成プロセス

インデックス作成プロセスは、データの収集とフルテキスト インデックス構成の構築という 2 つの概念的な過程があります。 SQL Server 2005 では、フルテキスト インデックス作成プロセスの効率化を図り、その相乗効果でパフォーマンスを向上させるために、フルテキストの収集メカニズムのアーキテクチャが強化されました。

フルテキストの作成 (別称、"クロール") が開始されると、データベース エンジンにより、大量のデータがメモリにプッシュされ、インデックスの作成を開始することがフルテキスト エンジンに通知されます。 (テーブルの列の値にはフルテキスト インデックスが作成されます)。 フルテキスト エンジンでは、プロトコル ハンドラ コンポーネントを使用して、インデックスを作成するパイプラインを経由してメモリからデータをプルし、フルテキスト インデックスが作成されます。

以前のバージョンの SQL Server の収集プロセスは、上記のバッチ処理セマンティクスではなく、Web クロールと同様に行単位のプル メカニズムに基づいていました。 SQL Server 2005 のバッチ処理メカニズムでは、リソースが積極かつ効率的に使用され、大量のデータに対してフルテキスト インデックスを作成する処理のパフォーマンスが向上しました。

注   BLOB 型の列に格納されているデータにインデックスを作成する場合、IFilter インターフェイスを実装した特別なコンポーネントが使用され、列に格納されているデータに指定されたファイル形式 (Microsoft Word など) に基づいてテキストが取得されます。 一部のフィルタ コンポーネントでは BLOB 型のデータをメモリにプッシュするのではなく、ディスクへの書き込みが必要になることがあるため、この型のデータに関しては、インデックス作成プロセスが若干異なる場合があります。

この処理の一環として、収集されたテキスト データは、単語区切りにより、個別のトークン (キーワード） に分割されます。 トークン分割に使用される言語は、列レベルで指定されているか、または BLOB データや XML データのフィルタ コンポーネントで確認できます。

"ノイズ" ワード (検索条件として重要ではない単語) を削除したり、トークンがフルテキスト インデックスやインデックスのフラグメントに格納される前にトークンを標準化したりするために、追加の処理が実行されることがあります。

図 1. に SQL Server 2005 のフルテキスト エンジンのコンポーネントの概要を示します。

図 1. SQL Server 2005 のフルテキスト エンジン コンポーネント

インデックスの作成が完了したら、最終的な "マスタ インデックス" のマージ プロセスがトリガされます。 インデックス フラグメントをマージすると、多数のインデックス フラグメントをクエリするのではなく、マスタ インデックスだけをクエリすれば良いので、クエリ パフォーマンスが向上し、関連性の順位付けには、より精度の高いスコアの統計を使用できるようになります。 インデックス フラグメントをマージする際には大量のデータを書き込んだり、読み込んだりする必要があるので、マスタ インデックスへのマージ プロセスでは、I/O の負荷が高くなることがあります。ただし、マージ中に着信するクエリがブロックされることはありません。

クエリ

フルテキスト インデックスのクエリは、非常に高速で柔軟性があります。 上記の特殊なインデックス構造により、特定の検索条件に一致するデータが容易に、かつすばやく検出されるようになりました。

以下に SQL Server 2005 のフルテキスト クエリの例を示します。

SELECT ProductModelId, ProductName
FROM ProductModel
WHERE CONTAINS(CatalogDescription, ' " aluminum alloy " ')

このクエリでは、ProductModel テーブルで CatalogDescription フィールドに語句 "aluminum alloy" が含まれる行の ProductModelId と ProductName が返されます。

クエリのフルテキスト部分が解析されて、フルテキスト エンジンに送信され、ProductModel テーブルのフルテキスト インデックスに対して照合されます。 検索条件のクエリ語句 (この場合は "aluminum alloy") は、列またはクエリで指定されている言語の単語区切りによりトークン分割され、ノイズ ワードは削除され、一致した DocId 値のリストがフルテキスト エンジンによって返されます。 データベース エンジン内では、フルテキスト キー値に DocId 値をマップする内部構造に対して DocId 値のリストが照合され、検索条件と一致した行の ProductModelId と ProductName の値を返すために、結果のフルテキスト キー値が ProductModel テーブルに結合されます。

注   以前のバージョンの SQL Server では、DocId をフルテキスト キー値にマップする処理は、フルテキスト エンジンで実行されていました。 SQL Server 2005 では、この処理はより効率性と一貫性の高いキャッシュ方法を利用できるデータベース エンジンに移行されました。 この移行とクエリ エンジンの機能強化により、フルテキスト クエリの処理速度は以前のバージョンの SQL Server よりも高速になっています。 フルテキスト クエリのパフォーマンスの向上の幅はクエリによって異なり、向上の幅が緩やかなるクエリも、劇的な向上が見られるクエリもあります。

上記のクエリの例は、単純なフルテキスト クエリです。 フルテキスト クエリの構文は堅牢かつ単純なので、非常に強力なクエリ式を評価できるようになりました。 この資料では、フルテキスト検索の式の各要素の詳細は説明しません。詳細については、SQL Server 2005 Books Online を参照してください。

順位付け

SQL Server のフルテキスト検索では、返されたデータの関連性についてのスコア (順位付けの値) が生成されます。この行単位の順位付けの値を並べ替えのセマンティクスとして使用して、関連性の高いデータから順に表示することができます。

フルテキスト クエリの順位付けの値は、CONTAINSTABLE または FREETEXTTABLE フルテキスト クエリ句から返されます。 CONTAINSTABLE 句および FREETEXTTABLE 句は、key 列と rank 列の 2 つの列を返すテーブル値関数と同じように動作します。key 列は、フルテキスト インデックスが作成されたベース テーブルへの結合に使用することができ、rank 列は、順位付けの値に基づいて結果を並べ替えるのに使用できます。 CONTAINS 句と FREETEXT 句は Transact-SQL 言語の述語なので、これらの句では順位付けの値は返されません。

フルテキスト クエリでは、CONTAINSTABLE、重み付け ISABOUT を指定した CONTAINSTABLE、および FREETEXTTABLE という 3 種類の順位付けが使用されます。 これらすべての関数は、クエリで使用されている単語の分布とインデックスが設定されたデータに基づいていますが、動作が異なります。 また、これらの順位付けの方法は、どれも完璧ではありません。パフォーマンス上の理由により、多くの値が特定の桁数に丸められたり、標準化されたりします。 クエリ結果の順位付けは、同じクエリで返された他の結果の順位付けと比較する場合にのみ有益です。 クエリ結果の順位付けは、別のクエリの結果の順位付けとは比較できません。クエリの対象が同じカタログでも、別のカタログであっても同様です。

順位付けは発展途上の技術です。この分野の発展に合わせて、マイクロソフトでは順位付けの機能を変更することを検討しています。 そのため、MSSeach を基に構築されるアプリケーションは、特定の順位付けの実装に依存しないようにする必要があります。特定の順位付けの実装に依存すると、新しいバージョンの MSSearch がリリースされたときに、アプリケーションが機能しなくなる可能性があります。 実際、SQL Server 2005 の MSSearch で採用されている順位付けは、SharePoint Portal Server、インデックス サービス、SQL Server 2000 などの製品の順位付けとはいくつかの点において異なります。

ブール句の順位付けは、AND 句のノードからは最下位順位を、OR 句のノードから最上位順位を取得することによって行われます。 順位を直接比較することはできないので、この方法は、せいぜい間違った概算を立てることにしかなりません。 そのため、FREETEXTTABLE(col1,  'foo') AND CONTAINSTABLE(col1, 'bar') のようなクエリを実行することはお勧めしません。 上記の組み合わせクエリの結果は、FREETEXTTABLE 句を使用した順位付けか、CONTAINSTABLE 句を使用した順位付けなのかを判断する術はありません。

順位付けの統計

インデックスが構築されると、順位付けに使用する統計が収集されます。 インデックスのサイズを抑え、計算が複雑にならないようにするため、統計が特定の桁数に丸められることがあります。

カタログの構築中、データにインデックスが作成されるのに合わせてアルゴリズムにより小さなインデックスが作成されます。その後、これらのインデックスは大きなインデックスにマージされます。 このプロセスは、何度も繰り返し行われます。 小さなインデックスを大きなマスタ インデックスにマージする最終プロセスを、"マスタ マージ" と呼びます。 統計にはクエリ結果を含む個別のインデックスから取得されるもの、マスタ インデックスから取得されるもの、マスタ マージが実行されたときにのみ算出されるものがあります。 そのため、統計の順位付けの精度と適時性は状況によって大幅に異なります。 インデックスは時間の経過と共にマージされるため、同じクエリを実行しても実行した時期が異なると返される順位の結果が異なるのは、このためです。 さらに、フルテキスト インデックスが作成されたデータが追加、修正、および削除されると、これらの変更内容が統計や順位付けの計算に影響を与えます。

以下に順位付けを計算する際によく使用される重要な統計値の一覧を示します。

  • Property: document の属性。 この値は、SQL Server の列に相当します。

  • Document: クエリで返されるエンティティ。 これは、SQL Server の行に相当します。 行に複数のフルテキスト インデックスが作成された列が含まれるのと同様に、document でも複数の property を保持できます。

  • Index: 1 つ以上の document の反転された 1 つのインデックス。 この値全体がメモリ内またはディスク上に存在できます。 多くのクエリの統計は、一致するデータが検出されたインデックスによって異なります。

  • Catalog: クエリで 1 つのエンティティとして扱われるインデックスの集合。 catalog は、SQL Server の管理者が認識する組織単位です。

  • Word: フルテキスト エンジンの照合単位。 ドキュメントのテキスト ストリームは、言語固有の単語区切りにより単語にトークン分割されます。

  • Occurrence: 単語区切りによって特定された document property 内の単語オフセット。 1 つ目の単語の occurrence は 1 で、次の単語の occurrence は 2 のようになります。 語句や近くにある単語をクエリする際の偽陽性を防ぐため、文末では 8 件の occurrence がスキップされます。 段落末では、128 件の occurrence がスキップされます。

  • Key: property と word の組み合わせ。

  • HitCount: 結果に含まれる key の発生回数。

  • Log2: 4 バイト値の最上位ビット セット。 2 を底に持つ対数計算の処理速度が他の対数計算よりも速いため、2 を底に持つ対数が採用されました。 2 を底に持つ対数の計算は、10 を底に持つ対数や e を底に持つ対数の計算よりも高速です。

    unsigned Log2 ( unsigned long s )
{
    for ( unsigned iLog2 = 0; s != 0; iLog2++ )
        s >>= 1;
    return iLog2;
}

  • IndexDocumentCount: index に含まれる document の総数。

  • KeyDocumentCount: key を含む index 内の document 数。

  • MaxOccurrence: ある document の特定の property の index に格納されている occurrence の最大値。

  • MaxQueryRank: エンジンにより返される順位付けの最大値 (1000)。

CONTAINSTABLE による順位付け

StatisticalWeight = Log2( ( 2 + IndexDocumentCount ) / KeyDocumentCount )
Rank = min( MaxQueryRank, HitCount * 16 * StatisticalWeight / MaxOccurrence )

一致した語句は、個別の key と同様に順位が付けられますが、KeyDocumentCount (語句を含む document の数) は 1 になることが予想されています。多くの場合、この予想は正しくなく、語句には個別のキーよりも高い重み付けが設定されることがあります。

ISABOUT による順位付け

ISABOUT は、従来の情報検索用語のベクトル空間クエリです。 既定で使用されている順位付けのアルゴリズムは、著名な Jaccard の手法です。 この順位付けは、クエリ内の用語ごとに計算され、次のように組み合わされます。

ContainsRank = 上記の CONTAINSTABLE で 1 つの用語の順位付けに使用したものと同じ数式です。
Weight = クエリで各用語に指定された重みです。  MaxQueryRank は既定の重みです。
WeightedSum = Σ[key=1 to n] ContainsRankKey * WeightKey
Rank =  ( MaxQueryRank * WeightedSum ) / ( ( Σ[key=1 to n] ContainsRankKey2 ) 
      + ( Σ[key=1 to n] WeightKey2 ) - ( WeightedSum ) )

合計は、4 バイトの符号なしの integer 型を使用して計算されます。 そのため、integer 型でオーバーフローが発生する可能性があるため、ベクトル空間クエリには 4294 個以上のキーを含めることはできません。 その他の計算は 8 バイトの integer 型で行われます。

FREETEXT による順位付け

FREETEXT による順位付けは、Okapi BM 25 の順位付けの数式に基づいています。 クエリ内の用語に順位が付けられ、値が合計されます。 FREETEXT クエリでは、屈折して生成された単語 (元のクエリ用語の語幹) を使用してクエリに単語が追加されます。これらの単語は、特別な重みや生成元とのリレーションシップがない別の用語として処理されます。 シソーラス機能で生成されたシノニムは、同等の重みがある別の用語として処理されます。

Rank = Σ[Terms in Query] w ( ( ( k1 + 1 ) tf ) / ( K + tf ) ) * ( ( k3 + 1 ) qtf / ( k3 + qtf ) ) )

上記の式のプレースホルダは、次のような意味になります。

  • w は、Robertson-Sparck Jones の式による重み付けです。
  • もともと、w は次のように定義されていました。
w = log10 ( ( ( r + 0.5 ) * ( N - n - R + r + 0.5 ) ) / ( ( R - r + 0.5 ) * ( n - r + 0.5 ) ) )

後に、上記の式は、次のように簡略化されました。

w = log10 ( ( ( r + 0.5 ) * ( N - R + r + 0.5 ) ) / ( ( R - r + 0.5 ) * ( n - r + 0.5 ) ) )
  • R は、ユーザーにより関係があるとマークされた document の数です。 これは SQL Server 2005 のフルテキスト検索には実装されていないので、無視されます。
  • ｒ は、ユーザーにより関係があるとマークされ、用語が含まれている document の数です。 これも実装されていません。
  • N は、クエリ内の property の値を持つ document の数です。
  • n は、用語が含まれている document の数です。
  • K は、( k1 * ( ( 1 – b ) + ( b * dl / avdl ) ) ) です。
  • dl は、document の長さ (word occurrence 単位) です。
  • avdl は、クエリが展開される property の document の平均の長さ (word occurrence 単位) です。
  • k1、b、および k3 は、それぞれ定数 1.2、0.75、および 8.0 です。
  • tf は、特定の document で特定の用語が出現する頻度です。
  • qtf は、クエリで特定の用語が出現する頻度です。

順位付けの計算に関する問題点

上記の順位付けの計算処理は、多くの要因に依存しています。

  • 単語区切りによって、テキストのトークン分割方法が異なります。 たとえば、ある単語区切りでは "dog-house" という文字列が "dog" と "house" に分割されますが、別の単語区切りでは "dog-house" と分割されることがあります。 つまり、使用されている単語が異なるだけでなくドキュメントの長さも異なるので、照合と順位付けは、指定された言語に基づいて行われます。 ドキュメントの長さが異なると、文字列内の単語のいずれにも関係しないクエリの順位付けに影響があります。

  • IndexDocumentCount などの統計は、状況によって大きく異なります。 たとえば、あるカタログのマスタ インデックスが 20 億行あるとします。このような場合に、新しいドキュメントのインデックスがメモリ内インデックスに作成されると、メモリ内インデックスのドキュメント数に基づいたドキュメントの順位付けは、マスタ インデックスのドキュメント数に基づいたドキュメントの順位付けと異なります。 そのため、すべてのインデックス作成プロセスが完了したら、ALTER FULLTEXT CATALOG ... REORGANIZE DDL ステートメントを使用してインデックスをマスタ インデックスにマージすることをお勧めします。

  • 単語区切りとフィルタを組み合わせて、文章や段落を検索できます。 文末では 8、段落末では 128 の occurrence がスキップされます。 そのため、MaxOccurrence は、property 値で検出された文章と段落の数によって大幅に異なります。

  • MaxOccurrence 値は、32 通りの範囲のいずれかの範囲に標準化されます。 つまり、たとえば、50 単語を含むドキュメントが 100 単語を含むドキュメントと同様に処理されます。標準化には、次の表が使用されます。 ドキュメントの長さは、隣接する表の値 32 から 128 までの範囲に収まっているので、ドキュメントを同じ長さ 128 (32 < docLength <= 128) と見なして効率良く処理することができます。

    { 16, 32, 128, 256, 512, 725, 1024, 1450, 2048, 2896, 4096, 5792, 8192, 11585, 
16384, 23170, 28000, 32768, 39554, 46340, 55938, 65536, 92681, 131072, 185363, 
262144, 370727, 524288, 741455, 1048576, 2097152, 4194304 };

  • TOP_N_BY_RANK を新しい順位付けの事前計算オプションと一緒に使用している場合、順位付けの計算中に値を丸める追加の処理が行われることがあります (このオプションについては、この資料の後半で説明します)。そのため、順位付けの事前計算オプションが有効になっているか、または無効になっているかによって、これらの値に違いが生じることがあります。

フルテキスト検索について十分に理解していただけたと思うので、今度は、SQL Server 2005 で導入された新しい機能をご紹介しましょう。

データベース管理者向けの新機能

フルテキスト エンジンのサイド バイ サイド インストール

フルテキスト エンジンのサイド バイ サイド インストールについては、既に「フルテキスト検索のアーキテクチャ」に記載しましたが、データベース管理者向けの詳細情報については説明しませんでした。

まず、フルテキスト エンジンをサイド バイ サイドでインストールできるようになったことにより、サーバーの管理と更新作業が簡略化されます。 以前は、OS、他の SQL Server インスタンス、および他の製品と Microsoft Serach (MSSearch) サービスが共有されていたため、オペレーティング システムの Service Pack をインストールしたり、システム上に存在する他のインスタンスやサーバー製品を更新したりすることによって SQL Server が影響を受けることがありました。 また、SharePoint Portal Server などの製品をインストールすると、システムに新しいバージョンの MSSearch が導入されるため、フルテキスト検索の動作が変更されることがありました。 しかし、SQL Server 2005 では、フルテキスト エンジンをインスタンス レベルで分離することによって、このような悪影響を回避できるようになりました。

サイド バイ サイド インストールにより、SQL Server 2005 では、以下のコンポーネントがインスタンス レベルで存在するようになります。

  • MSFTESQL。 フルテキスト エンジン サービスでは、フィルタ デーモン コンポーネントが管理され、管理作業が行われ、フルテキスト クエリが実行されます。 名前付きインスタンスでは、このコンポーネントは MSFTESQL$<instance_name> という名前になります。
  • MSFTEFD。 フルテキスト フィルタ デーモンにより、インデックスの作成やクエリに使用されるサードパーティの拡張コンポーネント (単語区切り、語幹検索、フィルタなど) が安全に読み込まれ、操作されます。この際、フルテキスト エンジン サービス自体が危険にさらされることはありません。
  • 単語区切り、語幹検索、およびフィルタ。 各インスタンスでは、独自の単語区切り、語幹検索、およびフィルタの組み合わせが使用できるようになり、オペレーティング システムで提供されているコンポーネントに依存する必要がなくなりました。 また、これらのコンポーネントは、各インスタンス レベルで、より簡単に登録および構成できるようになりました。 詳細については、SQL Server 2005 Books Online を参照してください。

セキュリティの強化

SQL Server 2005 では、サイド バイ サイド インストールが可能になったことにより、フルテキスト検索のセキュリティが強化されました。以前のバージョンの SQL Server では、LocalSystem として共有の MSSearch サービスを実行する必要がありましたが、多くの組織のセキュリティ ポリシーでは、サービスを権限の低いセキュリティ コンテキストで実行することが要請されていました。 SQL Server 2005 では、フルテキスト エンジンでは、LocalSystem アカウントではなく、データベース エンジンと同じアカウントを使用するようになりました。その結果、ロックダウンされた環境でもフルテキスト検索機能を簡単に展開できるようになっただけでなく、サイド バイ サイド アプローチにより、サービスを共有する設定で発生することのある悪影響が生じる危険もなくなりました。

SQL Server 2005 のフルテキスト検索では、署名されていないバイナリがフルテキスト エンジンの処理に読み込まれることも回避されます。 フルテキスト検索では、フィルタ、語幹検索、および単語区切りの拡張可能なアーキテクチャが公開されているので、サードパーティ製のコンポーネントをインストールすることもできます。 危険なコードや信頼されないコードが実行されることを回避するため、フルテキスト検索の既定の設定では、信頼のおける発行元で Authenticode で署名されていないコンポーネントを読み込むことが禁止されています。

インデックス作成のパフォーマンスとスケール変換の強化

以前バージョンの SQL Server と比較して SQL Server 2005 のフルテキスト検索で最も強化されたのは、フルテキスト インデックス作成のパフォーマンスです。 フルテキストの収集メカニズムのアーキテクチャの再編とインデックスのマージ方法の向上により、インデックス作成のパフォーマンスが大幅に向上されたことが社内で行ったテストで確認されました (収集メカニズムについては、既に「インデックス作成」で簡単に説明しました)。 たとえば、同じハードウェアと同じデータ セット (2 億行のテキスト データ) を使用した場合、SQL Server 2000 では、このデータにフルテキスト インデックスを作成するのに約 14 日かかりましたが、SQL Server 2005 では同じ条件で同じ処理を行うのに、たったの 10 時間弱しかかかりませんでした。

SQL Server 2005 では、インデックス作成のアーキテクチャが再編されたことにより、リソースの使用率も向上しました。 大容量のメモリを利用できるサーバーでフルテキスト インデックスを構築すると、大量のデータにインデックスを作成する処理には大容量のメモリが使用されるため、最適なパフォーマンスが実現されます。

SQL Server 2005 のフルテキスト インデックスは、大容量のデータを処理するように拡張することもできます。 以前のバージョンの SQL Server では、数十万から 200 万～ 300 万行までしか拡張することができませんでしたが、SQL Server 2005 のフルテキスト カタログでは、最大で 2,000,000,000 行のデータがサポートされることが実証済みです (これは、4 バイトの内部 DocId に基づいた結果です)。 さらに、多数の CPU を搭載しているシステムでは、同量のデータを処理するようにインデックス作成プロセスを拡張することもできます。 複数の CPU を使用した場合のインデックス作成時のテキスト エンジンの拡張性は、以前のバージョンの SQL Server と比べて格段に向上しました (フルテキスト エンジンは、32 ビット プラットフォームでは約 16 基の CPU まで拡張することができます)。

フルテキストのデータ定義言語

SQL Server2005 では、フルテキスト インデックスが過去最短速度で作成されるようになっただけでなく、インデックス作成プロセスが簡単になりました。 SQL Server 2005 では、フルテキスト インデックスとカタログを作成、変更、および削除するためのデータ定義言語 (DDL) が導入されました (以前のバージョンの SQL Server でインデックスやカタログの作成に使用されていたシステム ストアド プロシージャは、将来サポートされなくなる可能性がありますが、SQL Server 2005 では機能します)。

以下にフルテキストの DDL ステートメントの簡単な例を示します。

USE AdventureWorks
GO
-- フルテキスト カタログの作成。アクセントの区別の有無を指定できるように
-- なりました。このカタログは既定のカタログとして作成されているため、
-- カタログを指定していないインデックスでは、このカタログが使用されます。
CREATE FULLTEXT CATALOG AwCat WITH ACCENT_SENSITIVITY=OFF AS DEFAULT
GO

-- ProductModel テーブルの AwCat (既定) にインデックスを作成します。
-- ProductModelId を FT キーとして使用しています (ProductModelId は
-- 一意で NULL 値が許可されない単一列です)。また、手動による変更の
-- 追跡を行うようにして、定期的に変更内容を同期できるようにしました。
CREATE FULLTEXT INDEX ON ProductModel(CatalogDescription) 
KEY INDEX PK_ProductModel_ProductModelId WITH CHANGE_TRACKING MANUAL
GO

-- ProductModel で手動による変更の追跡の更新を開始します。フルテキスト
-- 作成オプションの詳細については、Books Online を参照してください。
ALTER FULLTEXT INDEX ON ProductModel START MANUAL POPULATION
GO

-- AwCat でマスタ マージをトリガします。この操作により、クエリの
-- パフォーマンスが向上し、順位付けの精度が上がります。この処理は、 
-- 完全な作成または手動による作成を行った後に、自動的に実行されます。
-- この処理は多数の更新を伴う変更の自動追跡でも周期的に役立ちます。
ALTER FULLTEXT CATALOG AwCat REORGANIZE
GO

SQL Server 2005 でフルテキストの DDL を使用すると、使いやすい構文を使用できるようになるだけでなく、多数のフルテキスト検索の新機能も利用できるようになります。

バックアップ、復元、および復旧

SQL Server 2005 のフルテキストに統合されている最たる機能は、フルテキスト カタログのバックアップ、復元、および復旧に通常のデータベースやトランザクション ログ ファイルのバックアップ、復元、および復旧に使用するのと同じ機能を使用できることです。 フルテキスト カタログは、フルテキスト エンジンで管理されており、ファイル システムに格納されています。 以前のバージョンの SQL Server では、フルテキスト カタログのバックアップは SQL Server のデータ ファイルとは別に作成する必要があり、これらのバックアップを一緒に作成すると、障害発生時にスムーズに復旧できない要因となることがありました。

SQL Server 2005 では、フルテキスト カタログは、データベース、ログ ファイル、およびファイルグループのバックアップに含めることができます。 バックアップを実行すると、フルテキスト カタログのバックアップ作成時点でのフルテキスト カタログとデータベースの整合性を確保するため、インデックスの作成処理が一時的に停止されます。 通常のログ ファイルのバックアップにはフルテキストの変更の追跡ログが含められるので、インデックスは前回の完全バックアップまたは差分バックアップ以降に変更されたデータについてのみ作成し直す必要があります (回復を迅速に行えるようにするには、フルテキスト カタログのスキーマ変更後またはフルテキスト カタログに大量のデータを読み込んだ後には、完全バックアップまたは差分バックアップを作成することをお勧めします)。

上記の AdventureWorks データベースの例を使用しましょう (このデータベースには、AwCat フルテキスト カタログが含まれています)。次のコマンドを実行して、データベースとそのフルテキスト カタログのバックアップを作成します。

BACKUP DATABASE AdventureWorks TO DISK='C:\backups\aw.dmp'
GO

データベースのバックアップを作成したら、次のコマンドを実行して障害状態を人為的に作り出します。

USE master
GO
DROP DATABASE AdventureWorks
GO

上記のコマンドが完了したら、次のコマンドを実行して、データベースとそのフルテキスト カタログを復元します。

RESTORE DATABASE AdventureWorks FROM DISK='C:\backups\aw.dmp'
GO

データベースとフルテキスト カタログを復元したので、次のクエリは、障害が発生する以前と同様に機能します。

USE AdventureWorks
SELECT ProductName
FROM ProductModel
WHERE CONTAINS(CatalogDescription, ' " aluminum alloy " ')

sp_detach_db と sp_attach_db による移行の可能性

SQL Server 2005 のフルテキスト検索では、SQL Server のデータベース ファイルがデタッチ、移動、および再アタッチできるのと同様に、フルテキスト カタログを簡単にデタッチおよび移動する機能が用意されています。 sp_detach_db と sp_attach_db にフルテキスト カタログも含められます。 データベースをデタッチした後に、フルテキスト カタログまたはデータベース ファイル、あるいはその両方を移動しても、データベースに再アタッチできます。 フルテキスト カタログのメタデータは、更新され、データベースやフルテキスト カタログの場所の変更内容が反映されます。 この機能により、データベースを複数のサーバーで構築、テスト、移動、および展開する作業が簡略化されます。

詳細な状態レポート

フルテキスト ユーザーに最大限の管理容易性とサポート可能性を提供するため、SQL Server 2005 のフルテキスト検索には、データベース管理者がエラーを簡単に診断および修復できる方法が用意されています。

SQL Server 2005 フルテキスト クロールのログ記録メカニズムにより、\LOG ディレクトリにはフルテキスト カタログごとに詳細なテキスト形式のログが保存されます。これらのログには、フルテキストの作成、実用的なエラー メッセージ (必要に応じて問題の推奨解決策) に関する情報提供を目的としたメッセージが記録されています。

また、フルテキストの作成などの処理の状態レポートの精度が高くなったので、サーバーで実行されているさまざまな処理の追跡作業が簡略化されました。 さらに、状態レポートの詳細なプロパティは OBJECTPROPERTY など多数の組み込みの関数に追加され、すべてのフルテキスト メタデータは新しいカタログ ビュー (sys.fulltext_catalogs、sys.fulltext_indexes、sys.fulltext_index_columns など) で公開されるようになりました。

フルテキスト クエリのプロファイラ サポート

SQL Server 2005 ではプロファイラ ツールにフルテキスト クエリ イベントが追加されたので、データベースの管理とプロファイルの作業が簡略化されました。 フルテキスト クエリ イベントを追加すると、フルテキスト クエリの実行に関する詳細な情報が提供されようになるため、パフォーマンスのボトルネックを特定するのに役立ちます。 フルテキスト クエリのプロファイラ トレースを使用すると、フルテキスト クエリが Transact-SQL クエリの他の部分と比較して、どの程度、効率的または非効率的であるのかを理解したり、インデックスの照合やクエリの他の部分を最適化できるかどうかを判断できます。

開発者向けの新機能

シソーラス機能

SQL Server 2005 のフルテキスト検索に新しく導入された "シソーラス機能" を使用すると、開発者は、着信したフルテキスト クエリで指定されている検索語句をプログラムでより適切または役立つ検索用語に拡張または置換して、着信したフルテキスト クエリを再定義できます。 フルテキストのシソーラスを使用すると、カスタム スクリプトを使用して着信したクエリ文字列を解析して、拡張または置換する必要がありません。また、シソーラスは、フルテキスト クエリの標準的な構文を使用して簡単に使用できます。 以下に、シソーラス機能を使用する CONTAINS クエリの例を示します。

SELECT ProductId, ProductName
FROM ProductModel
WHERE CONTAINS(CatalogDescription, ' FORMSOF(THESAURUS, metal) ')

FREETEXT クエリでは、シソーラス機能は FREETEXT クエリ処理の一環として自動的に呼び出されます。次に、例を示します。

SELECT ProductId, ProductName
FROM ProductModel
WHERE FREETEXT(CatalogDescription, ' metal ')

FREETEXT クエリでは、既に説明した CONTAINS クエリと同様にシソーラス機能が呼び出されます。 フルテキストのシソーラス機能により、言語ごとに拡張および置換の処理を構成できます。

構成可能なアクセントの区別

以前のバージョンの SQL Server では、フルテキスト カタログとクエリは、既定で、アクセントが区別されるようになっていました。 SQL Server 2005 では、アクセントの区別はカタログ レベルの設定になり、この設定は既に説明した新機能のフルテキスト カタログの DDL を使用して構成できます。 たとえば、アクセントが区別されないフルテキスト カタログに対して、"café" をクエリすると、"café" と "cafe" キーワードが含まれる行が一致する行として返されます。 逆に、アクセントが区別されるフルテキスト カタログに対して、"café" をクエリすると "café" というキーワードが含まれる行のみが一致する行として返されます。

このアクセントの区別は、次のように CREATE FULLTEXT CATALOG の実行時に構成できます。

CREATE FULLTEXT CATALOG AwCat WITH ACCENT_SENSITIVITY=OFF
GO

または、次のように ALTER FULL TEXT CATALOG を使用して構成することもできます。 

ALTER FULLTEXT CATALOG AwCat REBUILD WITH ACCENT_SENSITIVITY=ON
GO

場合によっては、アプリケーション側で特定のクエリ語句がフィルタ選択されており、アクセント付きおよびアクセントなしの両方の形式の語句が検出されるように "café" のような単語が "café" OR "cafe" 'に拡張されることがあります。 SQL Server 2005 ではアクセントの区別を構成できるようになったので、このようなアプリケーション レベルの処理を行う必要はありません。

クエリ時のノイズ ワード変換

アプリケーション開発者の皆さんは、ユーザーが任意のフルテキスト クエリ式を入力できる場合にフルテキスト検索でノイズ ワードが処理される方法を変更できるようになることを待ち望んでいたと思います。 問題となっていたのは、' "search" NEAR "the" ' のような検索式を指定する CONTAINS のようなクエリを実行しようとすると、クエリにはノイズ ワードしか含まれていないことを示すエラー メッセージが表示され、クエリを実行できないことでした ("the" はノイズ ワードです)。 このような場合に望ましい動作は、ノイズ ワードを無視し、単に "search" という単語を探すようにクエリを処理することです。

SQL Server 2005 では、sp_configure に新しい設定が導入されました。この設定を使用すると、開発者とデータベース管理者はフルテキストによるノイズ ワードの処理を緩やかにすることができます。 次の Transact-SQL ステートメントを実行すると、CONTAINS クエリでノイズ ワードを変換する新しい機能を使用できます。

EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'transform noise words', 1
GO
RECONFIGURE
GO

ノイズ ワードの変換機能の詳細は、SQL Server 2005 Books Online に記載されていますが、1 点だけ補足しておきます。SQL Server 2005 のフルテキスト検索を使用すると、開発者はアプリケーションでノイズ ワード リストのコピーを管理したり、プログラムでクエリ文字列を事前に解析して、ユーザー入力からノイズ ワードを削除したりする必要はありません。

複数列のクエリ

従来、フルテキスト クエリは、特定のテーブルの 1 列 (名前を列指定子として使用) またはすべての列 (アスタリスクを使用) に対して実行されていました。 ただし、この 1 列か全列のアプローチでは、あるテーブルでフルテキスト インデックスが作成されている一部の列に対してクエリを実行する場合、開発者は複数のフルテキスト クエリ句を使用する必要があり、フルテキスト エンジンに対してクエリを個別に実行する必要がありました。 SQL Server 2005 では、列リストの指定が可能になり、開発者は、あるテーブルでインデックスが作成されている 1 つの列、一部の列、またはすべての列を単一クエリでクエリできるようになりました。

それでは例を見てみましょう。

USE MyDb
GO

CREATE TABLE myFt_Table(pk INT NOT NULL, txtCol1 VARCHAR(1024), txtCol2 VARCHAR(1024), 
txtCol3 VARCHAR(1024) )
GO

-- テーブルに値を設定します。

CREATE UNIQUE CLUSTERED INDEX idx1 ON myFt_Table(pk)
GO

CREATE FULLTEXT CATALOG myFtCat WITH ACCENT_SENSITIVITY=OFF AS DEFAULT
GO

CREATE FULLTEXT INDEX ON myFt_Table(txtCol1, txtCol2, txtCol3) 
KEY INDEX idx1
GO

上記の例では、あるデータベースに単純な 4 列構成のテーブルを作成しました。 pk 列は、一意で NULL 値が許可されないフルテキスト キー列で、3 つの varchar 列にはフルテキスト インデックスを作成することにしました。 テーブルとフルテキスト インデックスを作成して、値を設定したので、今度は、いくつかのクエリを見てみましょう。

SELECT pk, txtCol1
FROM myFt_Table
WHERE CONTAINS(txtCol1, ' "foo" AND "bar" ')

SELECT *
FROM myFt_Table
WHERE CONTAINS(*, ' "foo" AND "bar" ')

SELECT pk, txtCol2, txtCol3
FROM myFt_Table
WHERE CONTAINS( ( txtCol2, txtCol3 ) , ' "foo" AND "bar" ')

上記の 3 つ目のクエリでは、3 つの列がかっこ内でコンマ区切りで指定されています。 このクエリは、次のクエリと同等です。

SELECT pk, txtCol2, txtCol3
FROM myFt_Table
WHERE CONTAINS(txtCol2, ' "foo" AND "bar" ')
OR CONTAINS(txtCol3, ' "foo" AND "bar" ')

上記のクエリでは、検索条件を指定するのに複数の句を使用しており、txtCol1 に対する検索を行っていないことに注意してください。 既に説明したように、複数の句を使用すると、フルテキスト エンジンでも複数のテキスト クエリを評価する必要があります。単一のフルテキスト クエリ句で列リストを指定すれば、フルテキスト エンジンで評価する必要のあるクエリ式は 1 つだけになります。 必要に応じて、この技法を使用すると、クエリのパフォーマンスと効率を向上させられます。

クエリ レベルの言語指定

SQL Server 2005 のフルテキスト検索では、インデックス作成時の BLOB および XML ドキュメントで指定されている言語設定が使用されます。 たとえば、次の XML ドキュメントの場合を説明しましょう。

<myXmlDoc>
<docTitle>
<docENUTitle xml:lang="en-us">
Yukon full-text search
</docENUTitle>
<docDEUTitle xml:lang="de">
Yukon full-text search (german equivalent)
</docDEUTitle>
</docTitle>
…
</myXmlDoc>

docENUTitle 要素では、英語 (米国) を使用するように指定されていますが、docDEUTitle ではドイツ語が指定されています。 インデックス作成時、docENUTitle のコンテンツは英語 (米国) の単語区切りでトークン分割され、docDEUTitle コンテンツはドイツ語の単語区切りで解析されます。

では、クエリ時には、どのような処理を行う必要があるのでしょうか。 SQL Server 2005 のフルテキスト クエリ構文 (CONTAINS、CONTAINSTABLE、FREETEXT、FREETEXTTABLE など) では、新しく LANGUAGE <lcid> というパラメータがサポートされるようになりました (このパラメータは、数値または文字列として指定します)。このパラメータを使用すると、列の既定のフルテキスト言語を句レベルの言語でオーバーライドできます。 この句レベルの言語により、フルテキスト クエリのすべての用語に使用する単語区切り、シソーラス、およびノイズ ワードのリストが決まります。 たとえば、ある列の既定のフルテキスト言語が 0 (ニュートラル) に設定されている場合は、次のクエリを実行できます。

-- ニュートラル言語 (列の既定の言語) を使用します。
SELECT * 
FROM ft_Table
WHERE CONTAINS(xmlFtCol, ' "Full-Text Search" ')

-- 英語を使用します。
SELECT * 
FROM ft_Table
WHERE CONTAINS(xmlFtCol, ' "Full-Text Search" ', LANGUAGE 'English')

-- ドイツ語を使用します。
SELECT * 
FROM ft_Table
WHERE CONTAINS(xmlFtCol, ' "Full-Text Search" ', LANGUAGE 'German')

ニュートラル、英語、およびドイツ語では、それぞれの単語区切りによってテキストのトークン分割方法が異なるため、英語またはドイツ語のクエリに対しては適切な単語区切りを使用することが望ましいでしょう。 キーワードのインデックスは、 XML データに基づいて、指定言語に応じて、英語およびドイツ語の単語区切りを使用して作成されるので、上記のクエリでは言語を指定することが役立ちます。

LANGUAGE <lcid> パラメータの値をストアド プロシージャのフルテキスト クエリ句で使用する場合は、このパラメータの値を Transact-SQL 変数として指定できます。 以下に例を示します。

CREATE PROCEDURE SearchDocuments
   @srchString nvarchar(1024),
   @language int,
   @topN int,
   @searchType smallint
AS
IF @searchType = 0
   SELECT [KEY], [RANK] 
FROM FREETEXTTABLE(Document, Document, @srchString, 
LANGUAGE @language, @topN) 
ORDER BY [RANK] DESC
ELSE
   SELECT [KEY], [RANK] 
FROM CONTAINSTABLE(Document, Document, @srchString, 
LANGUAGE @language, @topN) 
ORDER BY [RANK] DESC
GO

上記の例では、Document テーブルに対して検索を行い、ストアド プロシージャへのパラメータとして検索文字列、クエリ レベルの言語の値 (int)、TOP_N_BY_RANK 値、および CONTAINSTABLE または FREETEXTTABLE のどちらを使用するかの条件が渡されています。

上記のストアド プロシージャにより、この検索処理をユーザー インターフェイスと連動させることが容易になります。 アプリケーションでは、検索文字列をテキスト入力フィールドから取得し、クエリ レベルの言語はサポートしている言語のドロップダウン リスト (このリストは、システム カタログ ビュー sys.fulltext_languages から選択できるようになりました) として扱い 、検索の種類と TOP_N_ BY_RANK 値はドロップダウン ボックスやオプション ボタンで簡単に設定できます。

順位付けの事前計算

SQL Server 2005 のフルテキスト検索機能を使用すると、TOP_N_BY_RANK パラメータを使用する FREETEXTTABLE クエリの新しい最適化を利用できます (上記例参照)。 FREETEXTTABLE クエリと CONTAINSTABLE クエリで使用する順位付けの計算方法が大きく異なるということは、既に説明しました。 SQL Server 2005 で順位付けの事前計算が最適化されたことにより、FREETEXTTABLE クエリでは、フルテキスト カタログで順位付けの値を使用できるようになり、これらの値を急いで計算する必要がなくなりました。 その結果、これらのクエリにより、CONTAINSTABLE クエリと TOP_N_BY_RANK パラメータを使用する FREETEXTTABLE クエリの速度の差が縮まります。

順位付けの事前計算は、sp_configure オプションです。このオプションは以下のように有効にすることができます。

EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'precompute rank', 1
GO
RECONFIGURE
GO

lrtest ツールと cidump ツール

開発者やデータベース管理者を悩ませることが多いのは、インデックス作成時とクエリ実行時におけるフィルタ、語幹検索、単語区切りコンポーネントの動作です。 これらのコンポーネントの動作は、インデックスの作成対象や取得エンティティに直接影響を与えるので、フィルタ、単語区切り、および語幹検索の動作の説明を提供するツールがあると便利でしょう。 また、多くの開発者やデータベース管理者からは、この資料の前半に記載した "インデックス構造" のような形式でフルテキスト カタログのコンテンツをダンプするツールを求める声が多く寄せられています。 フルテキスト カタログのコンテンツにアクセスできるようになると、インデックスを作成したテキストの特性をより詳細に分析できるようになります (たとえば、あるフルテキスト カタログで最も頻繁に使用される用語のトップ 10 を分析することができます)。

SQL Server 2005 には、コンポーネントの動作を例示したり、フルテキスト カタログを分析するのに役立つ 2 つの新しいコマンドライン ツールが同梱されています。 コンポーネントのテストには lrtest.exe、フルテキスト カタログのコンテンツをのダンプには、cidump.exe を使用します。 また、プログラムで DocId 値をフルテキスト キー値にマップする機能も強化されました。詳細については、「フルテキスト検索のアーキテクチャ」セクションの「インデックス作成」を参照してください)。 cidump から返された DocId 値をフルテキスト キー値にマップする必要がある場合、このマップした値にアクセスすると cidump の使用が簡略化されます。

クエリのパフォーマンス向上と順位付け機能の強化

上記で説明したように、SQL Server 2005 ではフルテキスト検索のパフォーマンスとスケーラビリティが向上しました。 フルテキスト検索対応のアプリケーションのデータベース開発者やユーザーは、以前のバージョンの SQL Server を使用した場合よりも、アプリケーションのパフォーマンスが 30 ～ 50% 向上することを実感できると思います。 開発チームでは、フルテキスト エンジン自体のクエリ パフォーマンスを強化すること、データベース エンジンに DocID の値をキーにマップする機能を移行することに重点を置いてきました。 ユーザーは、以前のバージョンの SQL Server と比べて、SQL Server 2005 では、クエリのパフォーマンスが大幅に向上したことを実感できるでしょう。

また、FREETEXTTABLE クエリで返される関連性のスコアは、以前のバージョンの SQL Server よりも精度が上がっています。 フルテキスト検索で使用するスコアの式と Okapi BM-25 スコアリング アルゴリズムの実装の改良により、大容量のデータ セットおよび小容量のデータ セットに対するスコアだけでなく、1 つのテーブルの複数列に対するスコアも向上しました。

まとめ

SQL Server 2005 リリースでは、フルテキスト検索機能が大幅に改良されました。 SQL Server 2005 のフルテキスト検索を使用すると、使いやすく、管理しやすいエンタープライズ クラスの最強のテキスト検索機能であることがおわかりいただけると思います。

関連資料

SQL Server に関する一般的な情報については、Microsoft SQL Server Web サイト を参照してください。

ホワイト ペーパー

次のホワイト ペーパーでは、フルテキスト検索の主要機能についての詳細情報が提供されています。

サンプル アプリケーション

SQL Server 2005 のサンプルには、ItemFinder というアプリケーションが同梱されています。このアプリケーションでは、フルテキスト検索の新機能を利用して、フルテキスト検索のベスト プラクティスを例示しています。 このサンプル アプリケーションには、Transact-SQL スクリプトだけでなく、C# や Visual Basic .NET のソースも含まれています。

ニュースグループ

以下の Usenet ニュースグループでは、フルテキスト検索を使用している他のユーザーに疑問点を投げかけたり、見解を共有することができます。

  • microsoft.public.sqlserver.fulltext (英語)
  • microsoft.beta.yukon.relationalserver.fulltext (英語)

著作権

このドキュメントは暫定版であり、このソフトウェアの最終的な製品版の発売時に実質的に変更されることがあります。

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示、黙示、または法律の規定にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。 このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。 ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。 ただし、これは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係ありません。

© 2004 Microsoft Corporation. All rights reserved.

Microsoft および SQL Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

記載されている会社名、製品名には、各社の商標のものもあります。