Share via

FAST Search 固有のコネクタの展開を計画する (FAST Search Server 2010 for SharePoint)

  • [アーティクル]

 

適用先: FAST Search Server 2010

トピックの最終更新日: 2010-11-04

Lotus Notes データベースや Web コンテンツに対して FAST Search 固有のコネクタを使用してコンテンツのクロールを開始するときは、その前にいくつか検討すべき事項があります。最初に検索の要件とクロールするコンテンツの構成を確認して必要な情報を収集しておけば、コネクタをより効果的にセットアップできます。

複数のコンテンツ コレクションを作成するか検討する

FAST Search Server 2010 for SharePoint では、クロールしたコンテンツを FAST Search Server 2010 for SharePoint インデックスに供給するためにコンテンツ コレクションが使用されます。すべてのコンテンツを同一のコンテンツ コレクション (既定では sp) に供給することも選択肢の 1 つにできます。

しかし、ときには FAST Search 固有の特定のコネクタ構成のコンテンツをコンテンツ コレクションから削除しなければならないこともあります。それにはコンテンツ コレクションをクリアするしかなく、そのために特定のコンテンツ コレクションのコンテンツをすべて削除する Windows PowerShell のコマンドを実行する必要があります。この場合は、そのコンテンツ コレクションに供給されるすべてのコンテンツ ソースを再度クロールしなければならなくなるので、多くの時間がかかります。

そこで将来、特定のコンテンツ コレクションのコンテンツを削除しなければならなくなることが予想される場合には、FAST Search 固有のコネクタ構成に関するコンテンツ コレクションを分けて作成することを検討してください。FAST Search 固有のコネクタ構成ごとにコンテンツ コレクションを分けておけば、インデックスのコンテンツが失われないので、同じコレクションに供給されるその他のコンテンツ ソースを再度クロールしなくて済みます。

重要

追加のコンテンツ コレクションを作成するとメモリを消費します。実行中のインデックス ノードごとにコンテンツ コレクションあたり 500 MB のメモリが追加で消費されることを考慮する必要があります。たとえば、2 つのインデクサーと 2 つのコンテンツ コレクションがある環境では、メモリ消費量の合計は 2 x (2 x 500 MB) = 2000 MB、つまり、インデクサー全体で 2 GB になります。

FAST Search Lotus Notes コネクタを実装する前に検討すべき事項は次のとおりです。

  • クロールしてインデックスを作成するデータがあるのは、どの Domino サーバーか。

  • 各サーバーのどのデータベースをクロールしてインデックスを作成するか。

  • 検索可能にする Lotus Notes ドキュメントを選択するためのデータベース ビュー (もしあれば)。

  • 検索可能にする (または検索可能にしない) 添付ファイルの種類 (pdf、txt、doc、nsf、ppt など)。

  • データにアクセスする権限をどのアカウントに与えるか。

  • 検索可能にするデータベース メタデータの種類。

  • クロールしてインデックスを作成する Lotus Notes ドキュメントの総数。

    • クロールする Lotus Notes ドキュメントの総数は、コネクタの状態データを追跡するために使用する SQL Server データベースの種類に影響します。SQL Server Express データベースの最大サイズは約 4 GB です。これはおよそ 200 万個の Lotus Notes アイテムに相当します。これよりも多くのアイテムをクロールすることを計画している場合には、SQL Server 2008 Enterprise (またはそれ以降) を使用してください。

    • 状態追跡データベースを別のものに変更する手順は、「FAST Search Lotus Notes コネクタを構成する」に説明されています。

  • コネクタの実行頻度 (毎日、毎週、毎月など)。

    • Lotus Notes コンテンツの種類に応じて、求められる情報の鮮度も異なります。たとえば、電子メール データベースは毎日クロールする必要があるのに対し、アーカイブ データベースは週 1 回 (または月 1 回) クロールすれば済みます。このような場合は、そのコンテンツ セットごとに構成を分けて作成してください。

  • コネクタ構成をいくつかに分けて作成する必要があるか。クロールをいくつかの構成に分割し、それぞれの構成を別々にスケジュールすることがあります。これには次のような理由が考えられます。

    • 求められる情報の鮮度が異なる。

    • コンテンツによって、含む/含まないの規則が異なる。たとえば、電子メールに添付された Lotus Notes データベースについてはインデックスを作成しないが、プロジェクト データベースに添付された Lotus Notes データベースについてはインデックスを作成する。

    • コンテンツの部分部分でプロパティ マッピングが異なる。たとえば、電子メールのプロパティ "last modified" が最終変更日時のタイムスタンプで、プロジェクト データベースのプロパティ "last modified" がドキュメントを最後に変更したユーザーの名前であるような場合。これらの 2 つのプロパティは種類が異なるので、同じ管理プロパティ内にインデックスを作成できません。したがって、この 2 つには別のプロパティ マッピングが必要です。これは構成を分けることで実現されます。

    • 検索エンジンのコンテンツ コレクションを分けるためにコンテンツをそれぞれ別に供給する必要がある。将来のある時点で特定の構成 (および対応するコンテンツ) を削除する可能性がある場合は、その構成のコンテンツ コレクションを別に分けて使用します。こうしておけば、コンテンツ コレクションを削除するだけで、その構成に関してインデックスが作成されたコンテンツをすべて削除でき、別の構成に関してはクロール データを失わずに済みます。コンテンツ コレクションを分ける必要があるかどうかの判断については、記事『クロール ルールを管理する (FAST Search Lotus Notes Connector)』のセクション「Considerations when modifying the filters」を参照してください。

  • アイテムの状態追跡を使用するかどうか。

    • アイテムの状態追跡は、各アイテムが最後にクロールされた日時とそのクロールの状態をエラー メッセージなどと共に記録する機能です。この情報は自動的にクリアされないデータベース テーブルに格納されます。各クロールのアイテム数とクロールの実行頻度によっては、このテーブルがかなり大きくなることがあります。

      必要なら FAST Search Lotus Notes コンテンツ コネクタの構成ファイル パラメーター ConnectorExecution/EnableStatustracker を false に設定してアイテムの状態追跡をオフにします。コネクタが実行されていないとき定期的に connectors.statustracker テーブルの内容を手動で削除する方法もあります。

FAST Search データベース コネクタを実装する前に検討すべき事項は次のとおりです。

  • どのサーバーのデータベースにクロールしてインデックスを作成するデータがあるか。

  • クロールしてインデックスを作成するデータがあるのは、どのデータベース/テーブルか。

  • クロールしてインデックスを作成するデータ ソースごとに SQL クエリを定式化する (あるいはデータベース所有者に定式化してもらう) 準備をすること。これにはデータベース クライアント ツールが役に立ちます。

  • SQL クエリごとに、どの列 (複数の場合もあり) をドキュメント ID として使用するかを決めること。

  • SQL クエリの結果として返される行を同じ ID で 1 つの FAST Search Lotus Notes コネクタ ドキュメントに結合するかどうかを決めること。

  • 増分更新をどのように構成するか。更新された行を見つけるためのタイムスタンプの列がデータベースにあるか、それとも、そのような列を追加できるか調べます。そのような列がないか、それを追加できない場合は、チェックサムやフラグによる方法を使用します。

  • アイテムの状態追跡を使用するかどうか。

    • アイテムの状態追跡は、各アイテムが最後にクロールされた日時とそのクロールの状態をエラー メッセージなどと共に記録する機能です。この情報は自動的にクリアされないデータベース テーブルに格納されます。各クロールのアイテム数とクロールの実行頻度によっては、このテーブルがかなり大きくなることがあります。

      必要なら FAST Search データベース コネクタの構成ファイル パラメーター ConnectorExecution/EnableStatusTracker を false に設定してアイテムの状態追跡をオフにします。コネクタが実行されていないとき定期的に connectors.statustracker テーブルの内容を手動で削除する方法もあります。

FAST Search Web クローラーを実装する前に検討すべき事項は次のとおりです。

  • 使用するクローラー構成の数。クロールする複数の独立した Web サイトで異なるクロール構成ルールが必要なときは、複数の FAST Search Web クローラー構成を使用することを検討してください。多くの場合は、代わりにサブ コレクションを使うこともできます。

  • 使用する FAST Search Web クローラー サーバーの数。クロールする Web サイトの数が多いときは、複数の FAST Search Web クローラー サーバー (複数ノード Web クローラーと呼ばれる) の使用を検討してください。なお、1 つの DNS ドメイン (たとえば、*.contoso.com) は、1 つの FAST Search Web クローラー サーバーでしかクロールできません。

  • クロールしてインデックスを作成するデータがあるのは、どの Web サイトか。

  • クロールする Web サイトの数、コンテンツが要求される速度、Web サイトが再訪問される頻度。

  • どのような Web サイトまたは Web サイトの部分をインデックス作成の対象とするか。たとえば、不要なデータでインデックスを汚染したり、Web サーバーにそこで処理できないような負荷をかけたりする、CVS リポジトリのフロントエンドや、同様の Web フロントエンドを持つその他のシステム。

  • 認証が必要な Web サイト、必要な認証の種類、データにアクセスする権限を与えるアカウント。