Windows Search の通知プロセス
このトピックは次のように整理されています。
通知プロセスの概要
データ ストアのデータにインデックスを作成するには、次の 3 つの方法があります。
- クロール
- インデクサーによって管理される通知
- プロバイダーによって管理される通知
各アプローチのメリットについては、次のセクションで説明します。
クロール
通知が有効なソースは、起動時に増分クロールを実行し、通知または明示的なコマンドを使用して再度クロールします。 これは、Windows Vista 以降で自動的に行われます。 Windows Vista より前のオペレーティング システムでは、 タスク スケジューラ でスケジュールされたイベントを設定し、開始ページでクロールを開始するためにコードを呼び出す必要があります。 通知の形式を実装する必要はありません。 バックグラウンド プロセスとして、インデクサーはクロール スコープを走査し、変更を探してカタログを更新します。 このオプションは、ほぼすべての状況で推奨されます。
Indexer-Managed通知
インデクサーで管理される通知では、データ ストア内のデータが変更されたときにインデクサーに通知する通知戦略を実装し、インデクサーは通知の追跡とデータのインデックス作成を管理します。 この状況では、コンポーネント (通知プロバイダーと呼びます) がデータ ストアを監視し、ストアへの変更に関する情報を収集してから、インデックス作成が必要なアイテムの一覧をインデクサーに定期的に通知します。 インデクサーは、障害が発生した場合の通知の回復と解決を担当します。 このオプションは、"送信して忘れる" 戦略と考えることができます。これにより、インデクサー クロールの頻度が減ります。
Provider-Managed通知
プロバイダーが管理する通知では、通知プロバイダーが通知を追跡する必要があり、障害が発生した場合の通知の回復と解決を担当する点を除き、2 番目の方法に似た通知戦略を実装します。 このような状況では、通知プロバイダーはデータ ストアを監視し、ストアへの変更に関する情報を収集して維持し、インデックス作成が必要なアイテムの一覧をインデクサーに定期的に通知し、インデクサーから状態の更新を受信し、失敗した場合に通知を再送信します。
Note
このオプションは、データ ストアの増分クロールによってパフォーマンスが大幅に低下することが予想され、インデックス作成の状態をきめ細かく制御または分析する必要がある 場合を除き、推奨されません 。
行セットの通知
Windows 7 以降では、インデックス作成イベントを使用すると、プロバイダーは行セットに関する通知を受信できます。 インデックス作成イベントを使用するプロバイダーは、実際のファイル システムの場所の動作に似た方法で行セットを維持できます。 ライブラリと検索は、Windows 7 のファイル システム以外の場所の主な例です。 インデクサー イベントはライブラリ ビューに対して行われます。通知はファイル フォルダー ビューに対して行われます。 イベントの通知を受信するには、 IRowsetEvents インターフェイスを実装する必要があります。 データ レイヤーは、インデクサー イベントの主要なクライアントであり、アイテム ビュー UI のイベントの処理を決定します。 詳細については、「 Windows 7 でのインデックス作成の優先順位付けイベントと行セット イベント」を参照してください。
これに対し、Windows Vista では、ファイル プロパティの編集用のシェル キャッシュを除き、クエリ ベースのビューにはイベントが関連付けされません。 検索を実行すると、返される結果は静的になります。 そのため、検索語句に一致する別のドキュメントがシステムに追加された場合、ビューは更新されず、新しい追加が含まれます。 この動作は、静的な Web ベースの結果の標準です。 ただし、ストレージの場所に対してクエリベースのビューを提供しようとしている場合、静的な結果は受け入れにくいです。 ユーザーは、インデクサーのコンテンツが最新であることを期待しています。 詳細については、「 変更のインデックスへの通知」を参照してください。 リファレンス ドキュメントについては、「 通知インターフェイス」を参照してください。
関連トピック