Windows Search でのインデックス作成プロセス
このトピックでは、インデックス作成プロセスの 3 つの段階と、それぞれに関係する主要なコンポーネントについて説明し、インデックス作成アクティビティのタイミングについて説明し、データ ストアまたはファイル形式のインデックスを作成するサード パーティの開発者向けにメモを提供します。
このトピックは次のように整理されています。
概要
Windows Search では、.doc形式や .jpeg 形式などのさまざまなファイル形式のファイル、およびファイル システムや Windows Outlook メールボックスなどのデータ ストアからのプロパティとコンテンツのインデックス作成がサポートされています。 インデックスには、プロパティの値全体によるフィルター処理と並べ替えを可能にする値インデックスと、テキスト プロパティまたはコンテンツ内の単語にインデックスを付ける反転インデックスの 2 種類があります。 カスタム ファイル形式またはデータ ストアがある場合は、アイテムのインデックスを正しく作成するために、Windows Search インデックスの方法を理解する必要があります。
インデックス作成プロセスは、Gatherer と呼ばれる Windows Search コンポーネントによって制御される 3 つの段階で行われます。 最初のステージでは、Gatherer によってキューに URL が追加されます。 URL はインデックスを作成するアイテムを識別し、キューは単に URL の優先順位付けされたリストです。 2 番目のステージでは、Gatherer は、アイテムにアクセスしてそれらに関するデータを収集するために、他の Windows Search およびサードパーティのコンポーネントを調整します。 最後に、3 番目のステージでは、収集されたデータがインデックスに追加されます。
次の図は、インデックス作成プロセスを通じたデータの主要コンポーネントとフローを示しています。 インデックスのデータの収集には、多数のコンポーネントが関係しています。 これらの一部は Windows Search の一部であり、一部はサード パーティ製アプリケーションから取得されます。 カスタム データ ストアまたはファイル形式がある場合、Windows Search はプロトコル ハンドラーとフィルターを使用して URL にアクセスし、インデックス作成用のプロパティを出力します。 Windows Search コンポーネントは青で表示され、サードパーティのコンポーネントは緑色で表示されます。
ステージ 1: インデックス作成のキュー URL
インデックス作成の最初の段階では、Gatherer はデータ ストアの更新に関する情報を収集し、その情報を既知のクロール スコープと比較した後、スキャンしてインデックスのデータを収集する URL のキューを構築します。 FAT ドライブなどの通知に基づかないソースの場合、Gatherer はクロール スコープの完全なトラバーサルを定期的に開始して、インデックス内のデータが最新の状態に保たれるようにします。 NTFS などのソースの場合、1 つのクロールのみが存在し、それ以外はすべて USN 変更ジャーナルからの通知によって処理されます。 また、Microsoft Outlook のクロールはありません。 次の図は、非クロール インデックス作成のキュー プロセスの概要を示しています。
このセクションの残りの部分では、クロールする URL を Windows Search で決定し、その過程でいくつかの重要な用語を定義する方法について説明します。
クロール スコープ クロール スコープは、Windows Search がスキャンして、より高速な検索のためにインデックスを作成する必要があるアイテムに関するデータを収集する URL のセットです。 Windows Search では、ユーザーの [ドキュメント ] フォルダーや [画像 ] フォルダーへのパスなど、既定でクロール スコープにいくつかの URL が追加されます。 その他の URL は、サードパーティ製のアプリケーション、ユーザー、グループ ポリシーによって追加できます。 最後に、ユーザーとグループ ポリシーの両方で URL を明示的に除外できます。 Windows Search は、追加されたすべての URL を取得し、除外された URL を削除してクロール スコープを決定します。 これは、Gatherer が作業を開始する URL のワーキング セットです。
Gatherer Gatherer は、クロール スコープ内の URL に関する情報を収集し、インデクサーがクロールする URL のキューを作成する Windows Search コンポーネントです。 クロール スコープ内のアイテムが追加、削除、または更新されると、データ ストアの通知プロバイダーから収集者に通知されます。 最初のクロールでは、Gatherer がクロール スコープ ルートから開始されます。 URL はプロトコル ハンドラーに渡され、次に適切な IFilter に渡されます。 フィルターは通常、より多くの URL を生成するディレクトリ列挙です。 通知は安定した状態です。 通常、各データ ストアには、これらの通知を提供する独自のプロトコル ハンドラーがあります。 たとえば、ローカル ファイル システムでは、 USN 変更ジャーナル は、file:// プロトコルのすべての URL の通知プロバイダーとして機能します。 同様に、Microsoft Outlook は、mapi:// プロトコルのすべての URL の通知プロバイダーとして機能します。 ユーザーがメールを受信、移動、または削除すると、メールの変更された状態が収集者に通知されます。 これらの通知から、Gatherer はクロールする URL のインデックス作成キューを作成します。
インデックス作成キュー インデックス作成キューは、インデックスを作成または再インデックスする必要がある項目を識別する URL の一覧です。 Gatherer は、通知プロバイダーから受信した URL とクロール スコープ内の URL を比較します。 クロール スコープに含まれる通知プロバイダーからのすべての URL は、次に処理する URL の優先順位付けに収集者が使用するキューに追加されます。
キューには、優先度の高い通知、通常の通知、定期的なクロールの 3 つがあります。 優先度の高いキューは、すぐに処理する必要がある通知用です。 たとえば、ユーザーが Windows エクスプローラーでアイテムのタイトル プロパティを変更した場合、変更直後に Windows エクスプローラー ビューを更新する必要があります。 通常の通知キューは、残りのすべての変更通知用です。 変更されたアイテムがユーザーにとって関心を持つ可能性が高いため、通知キューはクロール キューの前に処理されます。 Gatherer は、各キューの URL のデータに最初から順にアクセスします。
Windows 7 で導入された優先度設定とイベント API の詳細については、「Windows 7 での インデックス作成の優先度設定と行セット イベント」を参照してください。 クロール スコープの管理と通知の詳細については、「変更通知 の提供 」および 「クロール スコープ マネージャーの使用」を参照してください。
ステージ 2: クロール URL
インデックス作成の 2 番目のステージでは、Gatherer はキューをクロールし、データ ストアにアクセスし、アイテム ストリームを取得します。 まず、Gatherer は各 URL の適切なプロトコル ハンドラーを見つけます。 その後、Gatherer は URL をプロトコル ハンドラーに渡します。 プロトコル ハンドラーはアイテムにアクセスし、アイテム メタデータを Gatherer に渡します。 Gatherer はメタデータを使用して正しいフィルターを識別します。
次の図は、URL クロール プロセスの概要を示しています。 この段階には、コンポーネント間のかなりの調整と通信が含まれます。
このセクションの残りの部分では、Windows Search がインデックス作成のためにアイテムにアクセスする方法と、関連する各コンポーネントの役割について説明します。
Gatherer ステージ 2 では、クロール ステージでは、Gatherer によってキュー内の URL が処理され、優先度の高いキューから開始されます。 各 URL は、そのプロトコルを識別するために検査されます。 その後、Gatherer は、そのプロトコルに登録されているプロトコル ハンドラーを検索し、検索プロトコル ホスト プロセスでインスタンス化します。
検索プロトコル ホスト 検索プロトコル ホストは、プロトコル ハンドラーのボックス化されたホスト プロセスにすぎません。 通常、Windows Search は、システム セキュリティ コンテキストで実行されるホスト プロセスとユーザー セキュリティ コンテキストで実行されるホスト プロセスの 2 つを作成します。 この分離により、ユーザーに固有のデータがシステム コンテキストで実行されることはありません。
Windows Search では、ホスト プロセスを使用して、プロトコル ハンドラーのインスタンスを他のプロセスまたはアプリケーションから分離します。 これにより、外部アプリケーションはプロトコル ハンドラーの特定のインスタンスにアクセスできず、プロトコル ハンドラーが予期せず失敗した場合は、インデックス作成プロセスのみが影響を受けます。 ホスト プロセスはサード パーティのコード (プロトコル ハンドラー) を実行するため、Windows Search はプロセスを定期的にリサイクルして、成功した攻撃がプロセス内の情報を悪用する時間を最小限に抑えます。 それ以上に、検索プロトコル ホストは、URL のクロールやアイテムのインデックス作成には影響しません。
プロトコル ハンドラー プロトコル ハンドラーは、データ ストアのプロトコルを使用して、データ ストア内のアイテムへのアクセスを提供します。 たとえば、NTFS プロトコル ハンドラーは、file:// プロトコルを使用してローカル ドライブ上のファイルへのアクセスを提供します。 プロトコル ハンドラーは、データ ストアを走査し、新規または更新された項目を特定し、収集者に通知する方法を認識します。 次に、クロールが開始されると、プロトコル ハンドラーは、アイテムの基になるストリームにバインドし、セキュリティ制限や最終変更時刻などのアイテム メタデータを返す IUrlAccessor オブジェクトを Gatherer に提供します。
Note
プロトコル ハンドラーは Windows Search コンポーネントではありません。これらは、アクセスするように設計された特定のプロトコルとデータ ストアのコンポーネントです。 インデックスを作成するカスタム データ ストアがある場合は、プロトコル ハンドラーを実装する必要があります。 プロトコル ハンドラーの詳細と実装方法については、 プロトコル ハンドラーの開発に関するページを参照してください。
メタデータとストリーム プロトコル ハンドラーの IUrlAccessor オブジェクトによって返されるメタデータを使用して、Gatherer によって URL の正しいフィルターが識別されます。 Gatherer は、アイテムのファイル名拡張子を解析し、その拡張子に登録されているフィルターを検索します。 Gatherer がフィルターを見つけられない場合、Windows Search はメタデータを使用してシステム プロパティ情報の最小セット (System.ItemName など) を派生させ、インデックスを更新します。 それ以外の場合、Gatherer によってフィルターが見つかると、インデックス作成の第 3 段階が開始されます。
ステージ 3: インデックスの更新
インデックス作成の 3 番目のステージでは、Gatherer によって URL の正しいフィルターがインスタンス化され、 IUrlAccessor オブジェクトからのストリームを使用してフィルターが初期化されます。 その後、フィルターはアイテムにアクセスし、インデックスのコンテンツを返します。 カスタム ファイル形式がある場合、Windows Search はフィルターを使用して URL にアクセスし、インデックス作成用のコンテンツとプロパティを出力します。
次の図は、データ アクセス プロセスの概要を示しています。 この段階には、コンポーネント間のかなりの調整と通信が含まれます。
このセクションの残りの部分では、Windows Search がインデックス作成のためにアイテム データにアクセスする方法と、関連する各コンポーネントの役割について説明します。
Gatherer このステージの開始時に、Gatherer のロールは、アイテムの正しいフィルターをインスタンス化し、項目ストリームを渡すことです。 このステージの最後に、Gatherer はフィルターおよびプロパティ ハンドラーによって出力されたコンテンツとプロパティを受け取り、インデックスを更新します。
フィルター ホスト フィルター ホストは、フィルターとプロパティ ハンドラーのホスト プロセスにすぎず、検索プロトコル ホストと同様の目的を果たします。 ホスト プロセスは、検索プロトコル ホスト プロセスがプロトコル ハンドラーを分離するのと同じセキュリティと安定性の理由から、システムの残りの部分からフィルターとプロパティ ハンドラーを分離します。 ホスト プロセスは最小限の権限で実行され (ファイル システムにアクセスすることもできません)、セキュリティ攻撃から保護するためにリサイクルされる場合があります。 Windows Search では、リソースの使用も監視されるため、フィルターで消費されるリソースが多すぎると、ホスト プロセスがリサイクルされます。
フィルター フィルターは、Gatherer の項目情報を出力するインデックス作成プロセスの重要なコンポーネントです。 フィルターは、実装で使用されるプリンシパル インターフェイス 、 IFilter インターフェイスに名前が付けられ、その結果、IFilters と呼ばれることもあります。 フィルターには、ファイルなどの個々の項目と対話するフィルターと、フォルダーなどのコンテナーと対話するフィルターの 2 種類があります。 どちらもインデックスのデータを提供します。
プロトコル ハンドラーの IUrlAccessor オブジェクトによって返されるメタデータを使用して、Gatherer は特定の URL の正しいフィルターを識別し、ストリームに渡します。 Gatherer は、プロトコル ハンドラーまたはファイル名拡張子、MIME の種類、またはクラス識別子 (CLSID) によって、正しいフィルターを識別します。 URL がコンテナーを指している場合、フィルターはコンテナーのプロパティを出力し、コンテナー内の項目 (子 URL) を列挙します。 URL が項目を指している場合、プロパティの読み取りがあり、プロパティ ハンドラーよりも複雑な場合、フィルターはテキスト コンテンツを返します。 一般に、フィルターは項目の内容を出力し、プロパティ ハンドラーは項目のプロパティを出力することをお勧めします。 ただし、プロパティ ハンドラーを認識しない古いアプリケーションでフィルターを使用する必要がある場合は、フィルターを実装してプロパティを出力することもできます。
Note
フィルターは Windows Search コンポーネントではありません。これらは、アクセスするように設計された特定のファイル形式またはコンテナーに関連するコンポーネントです。 フィルターの詳細と、カスタム ファイル形式またはコンテナー用にフィルターを実装する方法の詳細については、「 Windows Search でフィルター ハンドラーを作成するためのベスト プラクティス」を参照してください。
次の表は、インデックス作成プロセス中に Gatherer がフィルター (IFilter) とプロパティ ハンドラー (IPropertyStore) から受け取る結果の一覧です。
| Ifilter | IPropertyStore | |
|---|---|---|
| 書き込みを許可する | いいえ | はい |
| コンテンツとプロパティを混在させる | はい | いいえ |
| 多 言語 | はい | いいえ |
| リンクを出力する | はい | いいえ |
| MIME | はい | いいえ |
| テキストの境界 | 文、段落、章 | None |
| クライアント/サーバー | 両方 | クライアント |
| 実装 | Complex | シンプル |
プロパティ ハンドラー プロパティ ハンドラーは、特定のファイル形式のプロパティの読み取りと書き込みを行うコンポーネントです。 アイテムにアクセスし、コンテンツにフィルターを適用するのと同じ方法で、Gatherer のプロパティを出力します。 プロパティ ハンドラーは、フィルターよりも実装が簡単です。 テキスト ベースのファイル形式が非常に単純な場合、またはファイルが非常に小さいと予想される場合、プロパティ ハンドラーはプロパティとコンテンツの両方を出力できます。
Note
プロパティ ハンドラーは Windows Search コンポーネントではありません。これらは、アクセスするように設計された特定のファイル形式に関連するコンポーネントです。 プロパティ ハンドラーの詳細と、カスタム ファイル形式用にプロパティ ハンドラーを実装する方法の詳細については、「 Windows Search 用のプロパティ ハンドラーの開発」を参照してください。
プロパティ Windows Search には、 プロパティ の大規模なライブラリを含むプロパティ システムが用意されています。 任意のプロパティは、フィルターまたはプロパティ ハンドラーによって定義されている任意の項目に表示できます。 カスタム ファイル形式がある場合は、ファイル形式のプロパティをこれらのシステム プロパティにマップし、新しいカスタム プロパティを作成できます。 フィルターまたはプロパティ ハンドラーがこれらのプロパティを出力すると、ユーザーがプロパティを使用して検索できるように、Gatherer によってインデックスが更新されます。 ファイル形式のカスタム プロパティの作成と登録の詳細については、「 プロパティ システム」を参照してください。
SystemIndex SystemIndex と呼ばれるインデックスは、インデックス付きデータを格納し、プロパティ ストアと、アイテム プロパティのプロパティとコンテンツに対するインデックス、およびテキストコンテンツとプロパティの反転インデックスで構成されます。 Gatherer がインデックスを更新した後、Windows Search やその他のアプリケーションによってインデックスに対してクエリを実行できます。 インデックスに対してクエリを実行する方法の詳細については、「 プログラムによるインデックスのクエリ」を参照してください。
Note
スキーマを再登録するときに、以前に定義されたプロパティの属性に加えられた変更がインデクサーによって考慮されないことに注意してください。 解決策は、インデックスを再構築するか、古いものを更新するのではなく、変更を反映する新しいプロパティを導入することです (推奨されません)。 詳細については、「プロパティ システムの概要」の「実装者への注意」を参照してください。
インデックス作成のスケジュール方法
Windows Search が最初にインストールされると、クロール スコープの完全なインデックス作成が実行され、高 I/O およびユーザー アクティビティの期間中は一時停止されます。 既定のクロール スコープは、 ドキュメント、 音楽、 画像、 ビデオなどの既定のライブラリの場所で構成されます。 通知は、最初のクロールが完了する前でも処理されます。 場合によっては、Gatherer はフル クロール スコープから URL をクロールします。 これらのフル クロールにより、インデックス内のデータが最新であることが保証されます。 たとえば、通知プロバイダーが通知の送信に失敗した場合、または Windows Search Serviceが予期せず終了した場合、Gatherer は新しいアイテムや変更されたアイテムを認識せず、これらのアイテムのインデックスを作成しません。 ソースには、通知のみと有効な通知の 2 種類があります。 どちらのソースでも、Gatherer は最初にインデックスをクロールします。 最初のクロールの後、 USN 変更ジャーナル のロール オーバーなどのエラーがない限り、通知専用ソースはフル クロールを再度実行することはありません。 通知が有効なソースは、インデクサーの起動時に増分クロールを実行しますが、実行中に通知をリッスンします。 NTFS と Microsoft Outlook は通知のみです。 インターネット エクスプローラーと FAT は通知が有効になっています。
注意 (実装者)
インデックス内のデータの品質とインデックス作成プロセスの効率は、フィルターとプロパティ ハンドラーの実装によって大きく異なります。 URL によってファイル形式が識別されるたびにフィルターが呼び出されるため、フィルターが非効率的な場合、インデックス作成プロセスの速度が大幅に低下する可能性があります。 プロパティ ハンドラーがすべてのファイル プロパティをシステム プロパティに正しくマップしない場合、またはこれらのプロパティを正しく出力しない場合、インデックス内のデータは正しく行われず、後でこれらのプロパティを検索すると、正しくない結果が返されます。 フィルターまたはプロパティ ハンドラーが失敗した場合、インデクサーはデータのインデックスを作成できません。
Windows Search 以外のアプリケーションとプロセスは、プロトコル ハンドラー、フィルター、およびプロパティ ハンドラーに依存します。 実装は、予期しない方法でこれらのアプリケーションに影響を与える可能性があります。 Windows Search 開発ガイドでは、設計の選択とこれらの各コンポーネントのテストに関するアドバイスを提供します。
関連トピック
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示