Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique décrit les trois étapes du processus d’indexation et les composants principaux impliqués dans chacun d’eux, explique le minutage de l’activité d’indexation et fournit des notes aux développeurs tiers qui souhaitent que leurs magasins de données ou formats de fichiers soient indexés.
Cette rubrique est organisée comme suit :
- Aperçu
- Étape 1 : URL de mise en file d’attente pour l’indexation
- Étape 2 : Analyse des URL
- Étape 3 : Mise à jour de l’index
- Comment l’indexation est planifiée
- Remarques sur les implémenteurs
- rubriques connexes
Aperçu
Windows Search prend en charge l’indexation des propriétés et du contenu à partir de fichiers de différents formats de fichiers, tels que des formats .doc ou .jpeg, et des magasins de données, tels que le système de fichiers ou les boîtes aux lettres Windows Outlook. Il existe deux types d’index : les index de valeur qui autorisent le filtrage et le tri en fonction de la valeur entière d’une propriété et d’index inversés qui indexent les mots dans les propriétés textuelles ou le contenu. Si vous disposez d’un format de fichier personnalisé ou d’un magasin de données, vous devez comprendre comment les index Windows Search permettent d’indexer correctement vos éléments.
Le processus d’indexation se produit en trois étapes contrôlées par un composant Windows Search appelé rassembleur. Dans la première étape, le rassembleur ajoute des URL aux files d’attente. Les URL identifient les éléments à indexer et les files d’attente sont simplement des listes d’URL hiérarchisées. Dans la deuxième étape, le rassembleur coordonne d’autres composants Windows Search et tiers pour accéder aux éléments et collecter des données à leur sujet. Enfin, dans la troisième étape, les données collectées sont ajoutées à l’index.
Le diagramme suivant montre les composants principaux et le flux de données via le processus d’indexation. Un certain nombre de composants sont impliqués dans la collecte de données pour l’index. Certains d’entre eux font partie de Windows Search, et certains proviennent d’applications tierces. Si vous disposez d’un magasin de données personnalisé ou d’un format de fichier, Windows Search s’appuie sur votre gestionnaire de protocole et filtre pour accéder aux URL et émettre des propriétés pour l’indexation. Les composants Windows Search sont affichés en bleu et les composants tiers sont affichés en vert.
Étape 1 : mise en file d’attente des URLs pour l’indexation
Dans la première étape de l’indexation, le rassembleur collecte des informations sur les mises à jour des magasins de données, compare ces informations à l’étendue d’analyse connue, puis génère une file d’attente d’URL à parcourir pour collecter des données pour l’index. Pour les sources qui ne sont pas basées sur la notification, telles que les lecteurs FAT, le collecteur initie régulièrement une exploration complète de l’étendue d’analyse afin que les données de l’index restent à jour. Pour les sources telles que NTFS, il ne nécessite qu'une seule exploration et tout le reste est géré par les notifications du journal des modifications USN. Il n’existe pas non plus d’analyse de Microsoft Outlook. Le diagramme suivant montre une vue générale du processus de file d’attente pour l’indexation non-crawl.
Le reste de cette section explique comment Windows Search détermine les URL à analyser et définit certains termes importants le long de la route.
Étendue de l’analyse L’étendue de l’analyse est un ensemble d’URL que Windows Search traverse pour collecter des données sur les éléments que l’utilisateur souhaite indexer pour des recherches plus rapides. Windows Search ajoute certaines URL à l’étendue d’analyse par défaut, comme les chemins d’accès aux dossiers Documents et Images des utilisateurs. D’autres URL peuvent être ajoutées par des applications tierces, des utilisateurs et une stratégie de groupe. Enfin, les utilisateurs et la stratégie de groupe peuvent exclure explicitement les URL. Windows Search accepte toutes les URL ajoutées et supprime les URL exclues pour déterminer l’étendue d’analyse. Il s’agit du jeu d’URL de travail à partir duquel le rassembleur commence son travail.
Cueilleur Le rassembleur est un composant Windows Search qui collecte des informations sur les URL dans l’étendue d’analyse et crée une file d’attente d’URL pour que l’indexeur analyse. Lorsqu’un élément de l’étendue d’analyse est ajouté, supprimé ou mis à jour, le rassembleur est averti par le fournisseur de notifications du magasin de données. Il existe une analyse initiale où le collecteur commence à la racine du périmètre d’analyse. L’URL est transmise au gestionnaire de protocole, puis au IFilter approprié. Le filtre est généralement une énumération de répertoires qui produit plus d’URL. Les notifications sont à l’état stable. En règle générale, chaque magasin de données possède son propre gestionnaire de protocole qui fournit ces notifications. Par exemple, sur le système de fichiers local, le journal des modifications USN agit en tant que fournisseur de notifications pour toutes les URL sous le protocole file://. De même, Microsoft Outlook agit en tant que fournisseur de notifications pour toutes les URL sous le protocole mapi://. Lorsqu’un utilisateur reçoit, déplace ou supprime un e-mail, Outlook avertit le rassembleur de l’état modifié de l’e-mail. À partir de ces notifications, le rassembleur crée des files d’attente d’indexation d’URL à analyser.
Indexation des files d’attente Les files d’attente d’indexation sont des listes d’URL qui identifient les éléments qui doivent être indexés ou réindexés. Le collecteur compare les URL qu’il reçoit des fournisseurs de notifications aux URL du périmètre d'exploration. Chaque URL des fournisseurs de notifications qui se trouve dans l’étendue de l’analyse est ajoutée à une file d’attente utilisée par le rassembleur pour hiérarchiser les URL à traiter ensuite.
Il existe trois files d’attente : notifications à haute priorité, notifications normales et explorations périodiques. La file d’attente à priorité élevée concerne les notifications qui doivent être traitées immédiatement. Par exemple, lorsqu’un utilisateur modifie la propriété de titre d’un élément dans l’Explorateur Windows, la vue Explorateur Windows doit être mise à jour immédiatement après la modification. La file d’attente de notification normale concerne toutes les notifications de modification restantes. Les files d’attente de notification sont traitées avant la file d’attente d’analyse, car les éléments modifiés sont plus susceptibles d’intéresser un utilisateur. Le rassembleur accède aux données des URL de chaque file d'attente selon le principe premier entré, premier sorti (FIFO).
Pour plus d’informations sur la hiérarchisation et les API d’événement introduites dans Windows 7, consultez Indexation des priorités et événements d’ensemble de lignes dans Windows 7. Pour plus d’informations sur la gestion et les notifications de l’étendue d’analyse, consultez Fournir des notifications de modification et utiliser le Gestionnaire d’étendue d’analyse.
Étape 2 : analyse d’URL
Dans la deuxième étape de l'indexation, le crawler analyse les files d'attente, accède aux entrepôts de données et récupère les flux d'éléments. Tout d’abord, le rassembleur recherche le gestionnaire de protocole approprié pour chaque URL. Ensuite, le rassembleur transmet l’URL au gestionnaire de protocole. Le gestionnaire de protocole accède à l’élément et transmet les métadonnées d’élément au rassembleur. Le rassembleur utilise les métadonnées pour identifier le filtre correct.
Le diagramme suivant montre une vue générale du processus d’analyse d’URL. Cette étape comprend une coordination et une communication considérables entre les composants.
Le reste de cette section décrit comment Windows Search accède aux éléments pour l’indexation et explique les rôles de chacun des composants impliqués.
Cueilleur À l’étape 2, l’étape d’analyse, le rassembleur traite les URL dans les files d’attente, en commençant par la file d’attente de priorité élevée. Chaque URL est examinée pour identifier son protocole. Le rassembleur recherche ensuite le gestionnaire de protocole inscrit pour ce protocole et l’instancie dans le processus hôte du protocole de recherche.
Hôte de protocole de recherche L’hôte de protocole de recherche est simplement un processus hôte encapsulé pour les gestionnaires de protocole. En règle générale, Windows Search crée deux processus hôtes, un qui s’exécute dans le contexte de sécurité système et un qui s’exécute dans le contexte de sécurité utilisateur. Cette séparation garantit que les données spécifiques à un utilisateur ne sont jamais exécutées dans le contexte système.
Windows Search utilise également le processus hôte pour isoler une instance d’un gestionnaire de protocole à partir d’autres processus ou applications. De cette façon, aucune application externe ne peut accéder à cette instance spécifique du gestionnaire de protocole et, si le gestionnaire de protocole échoue de façon inattendue, seul le processus d’indexation est affecté. Étant donné que le processus hôte exécute du code tiers (gestionnaires de protocole), Windows Search redémarre périodiquement le processus pour réduire la durée durant laquelle une attaque réussie peut exploiter des informations dans le processus. Au-delà de cela, l’hôte de protocole de recherche n’affecte pas l’analyse des URL ou l’indexation d’éléments.
Gestionnaires de protocole Les gestionnaires de protocole fournissent l’accès aux éléments d’un magasin de données à l’aide du protocole du magasin de données. Par exemple, le gestionnaire de protocole NTFS fournit l’accès aux fichiers sur un lecteur local à l’aide du protocole file://. Le gestionnaire de protocole sait comment parcourir le magasin de données, identifier les éléments nouveaux ou mis à jour et notifier le rassembleur. Ensuite, lorsque l’analyse commence, le gestionnaire de protocole fournit un objet IUrlAccessor au rassembleur pour établir une liaison au flux sous-jacent de l’élément et retourner des métadonnées d’élément telles que les restrictions de sécurité et l’heure de dernière modification.
Note
Les gestionnaires de protocole ne sont pas des composants Windows Search ; ils sont des composants du protocole et du magasin de données spécifiques auxquels ils sont conçus pour accéder. Si vous avez un magasin de données personnalisé que vous souhaitez indexer, vous devez implémenter un gestionnaire de protocole. Pour plus d’informations sur les gestionnaires de protocole et sur la façon d’implémenter un, reportez-vous au développement de gestionnaires de protocole.
Métadonnées et flux À l’aide de métadonnées retournées par l’objet IUrlAccessor du gestionnaire de protocole, le rassembleur identifie le filtre approprié pour l’URL. Le rassembleur analyse l’extension de nom de fichier de l’élément et recherche le filtre inscrit pour cette extension. Si le rassembleur ne parvient pas à trouver un filtre, Windows Search utilise les métadonnées pour dériver un ensemble minimal d’informations de propriété système (comme System.ItemName) et met à jour l’index. Sinon, si le rassembleur trouve le filtre, la troisième étape de l’indexation commence.
Étape 3 : mise à jour de l’index
Dans la troisième étape de l’indexation, le rassembleur instancie le filtre approprié pour l’URL et initialise le filtre avec le flux à partir de l’objet IUrlAccessor . Le filtre accède ensuite à l’élément et retourne le contenu de l’index. Si vous avez un format de fichier personnalisé, Windows Search s’appuie sur votre filtre pour accéder aux URL et émettre du contenu et des propriétés pour l’indexation.
Le diagramme suivant montre une vue générale du processus d’accès aux données. Cette étape comprend une coordination et une communication considérables entre les composants.
Le reste de cette section décrit comment Windows Search accède aux données d’élément pour l’indexation et explique les rôles de chacun des composants impliqués.
Cueilleur Au début de cette étape, le rôle du rassembleur consiste à instancier le filtre approprié pour l’élément et à le transmettre au flux d’éléments. À la fin de cette étape, le rassembleur prend le contenu et les propriétés émis par le gestionnaire de filtres et de propriétés et met à jour l’index.
Hôte de filtre L’hôte de filtre est simplement un processus hôte pour les filtres et les gestionnaires de propriétés et sert à des fins similaires à l’hôte de protocole de recherche. Le processus hôte isole les filtres et les gestionnaires de propriétés du reste du système pour les mêmes raisons de sécurité et de stabilité que les processus hôtes du protocole de recherche isolent les gestionnaires de protocole. Le processus hôte s’exécute avec des droits minimaux (il ne peut même pas accéder au système de fichiers) et est parfois recyclé pour se protéger contre les attaques de sécurité. Windows Search surveille également l’utilisation des ressources afin que si un filtre consomme trop de ressources, le processus hôte est recyclé.
Filtres Les filtres sont des composants critiques dans le processus d’indexation qui émettent des informations d’élément pour le rassembleur. Les filtres sont nommés après l’interface principale utilisée dans leur implémentation, l’interface IFilter et, par conséquent, sont parfois appelés IFilters. Il existe deux types de filtres : un qui interagit avec des éléments individuels tels que des fichiers et un qui interagit avec des conteneurs comme des dossiers. Les deux fournissent des données pour l’index.
À l’aide de métadonnées retournées par l’objet IUrlAccessor du gestionnaire de protocole, le rassembleur identifie le filtre approprié pour une URL particulière et le transmet au flux. Le rassembleur identifie le filtre correct via un gestionnaire de protocole ou par l’extension de nom de fichier, le type MIME ou l’identificateur de classe (CLSID). Si l’URL pointe vers un conteneur, le filtre émet des propriétés pour le conteneur et énumère les éléments du conteneur (URL enfants). Si l'URL pointe vers un élément, le filtre retourne le contenu textuel, le cas échéant, la lecture des propriétés est plus complexe que celle des gestionnaires de propriétés. En règle générale, nous recommandons aux filtres d'émettre le contenu des éléments et aux gestionnaires de propriétés d'émettre les propriétés des éléments. Toutefois, si votre filtre doit fonctionner avec des applications plus anciennes qui ne reconnaissent pas les gestionnaires de propriétés, vous pouvez également implémenter le filtre pour émettre des propriétés.
Note
Les filtres ne sont pas des composants Windows Search ; ils sont des composants liés au format de fichier ou au conteneur spécifique qu’ils sont conçus pour accéder. Pour plus d’informations sur les filtres et sur l’implémentation d’un format de fichier ou d’un conteneur personnalisé, consultez les meilleures pratiques pour créer des gestionnaires de filtres dans Windows Search.
Le tableau suivant répertorie les résultats reçus par le rassembleur à partir d’un filtre (IFilter) et d’un gestionnaire de propriétés (IPropertyStore) pendant le processus d’indexation.
| IFilter | IPropertyStore | |
|---|---|---|
| Autoriser l’écriture | Non | Oui |
| Mélanger le contenu et les caractéristiques | Oui | Non |
| Multilingue | Oui | Non |
| Émettre des liens | Oui | Non |
| MIME | Oui | Non |
| Limites de texte | Phrase, paragraphe, chapitre | Aucun |
| Client /serveur | Les deux | Client |
| Implémentation | Complex | Simple |
Gestionnaires de propriétés Les gestionnaires de propriétés sont des composants qui lisent et écrivent des propriétés pour un format de fichier particulier. Ils accèdent aux éléments et émettent des propriétés pour le rassembleur de la même façon que les filtres pour le contenu. Les gestionnaires de propriétés sont plus faciles à implémenter que les filtres. Si un format de fichier textuel est très simple ou que les fichiers sont censés être très petits, le gestionnaire de propriétés peut émettre à la fois des propriétés et du contenu.
Note
Les gestionnaires de propriétés ne sont pas des composants Windows Search ; il s’agit de composants liés au format de fichier spécifique qu’ils sont conçus pour accéder. Pour plus d’informations sur les gestionnaires de propriétés et sur la façon d’implémenter un gestionnaire de propriétés pour un format de fichier personnalisé, consultez Développement de gestionnaires de propriétés pour Windows Search.
Propriétés Windows Search fournit un système de propriétés qui inclut une grande bibliothèque de propriétés. Toute propriété peut apparaître sur n’importe quel élément tel que défini par le filtre ou le gestionnaire de propriétés. Si vous avez un format de fichier personnalisé, vous pouvez mapper les propriétés de votre format de fichier à ces propriétés système et créer de nouvelles propriétés personnalisées. Lorsque votre filtre ou gestionnaire de propriétés émet ces propriétés, le rassembleur met à jour l’index afin que les utilisateurs puissent effectuer des recherches à l’aide de vos propriétés. Pour plus d’informations sur la création et l’inscription de propriétés personnalisées pour un format de fichier, consultez Le système de propriétés.
SystemIndex L'index, appelé SystemIndex, stocke les données indexées et se compose d'un store de propriétés, ainsi que d'indices sur les propriétés et le contenu des éléments, et d'un index inversé pour le contenu textuel et les propriétés. Une fois que le rassembleur met à jour l’index, l’index peut être interrogé par Windows Search et d’autres applications. Pour plus d’informations sur les façons d’interroger l’index, consultez Interroger l’index par programmation.
Note
N’oubliez pas que lorsque vous réinscrivez un schéma, les modifications apportées aux attributs des propriétés précédemment définies peuvent ne pas être respectées par l’indexeur. La solution consiste à reconstruire l’index ou à introduire de nouvelles propriétés qui reflètent les modifications au lieu de mettre à jour les anciennes (non recommandées). Pour plus d’informations, consultez Note to Implementers in Properties System Overview.
Comment l’indexation est planifiée
Lorsque Windows Search est installé pour la première fois, il effectue une indexation complète de l’étendue d’analyse, en effectuant des pauses pendant les périodes d’E/S élevées et d’activité utilisateur. L’étendue d’analyse par défaut se compose des emplacements de bibliothèque par défaut, tels que Documents, Musique, Images et Vidéos. Les notifications sont traitées même avant que le crawl initial ne soit terminé. Parfois, le collecteur analyse les URL du périmètre d'exploration complet. Ces explorations complètes garantissent que les données de l'index sont mises à jour. Par exemple, si un fournisseur de notifications ne parvient pas à envoyer des notifications ou si le service Windows Search est arrêté de façon inattendue, le rassembleur n’a aucune connaissance des éléments nouveaux ou modifiés et n’indexe pas ces éléments. Il existe deux types de sources : notification uniquement et notification activée. Dans les deux sources, le rassembleur analyse initialement l’index. Après l'analyse initiale, les sources uniquement destinées aux notifications n'effectueront plus jamais d'exploration complète, sauf en cas d'échec, comme lorsqu'il y a une réinitialisation du journal des modifications USN. Les sources activées pour les notifications effectuent une analyse incrémentielle lorsque l’indexeur est démarré, mais écoutent ensuite les notifications en cours d’exécution. NTFS et Microsoft Outlook ne fournissent que des notifications. Internet Explorer et FAT sont activés pour les notifications.
Remarques sur les implémenteurs
La qualité des données dans l’index et l’efficacité du processus d’indexation dépendent en grande partie de votre implémentation de filtre et de gestionnaire de propriétés. Étant donné que le filtre est appelé chaque fois qu’une URL identifie votre format de fichier, le processus d’indexation peut ralentir considérablement si votre filtre est inefficace. Si votre gestionnaire de propriétés ne mappe pas correctement toutes les propriétés de fichier aux propriétés système ou n’émet pas correctement ces propriétés, les données de l’index sont incorrectes et les recherches ultérieures pour ces propriétés retournent des résultats incorrects. Si votre filtre ou gestionnaire de propriétés échoue, l’indexeur ne pourra pas indexer les données.
Les applications et les processus autres que Windows Search s’appuient sur des gestionnaires de protocole, des filtres et des gestionnaires de propriétés. Vos implémentations peuvent affecter ces applications de manière à ce que vous ne vous attendiez pas. Le Guide de développement Windows Search fournit des conseils sur les choix de conception et sur le test de chacun de ces composants.
Rubriques connexes
Indexation, interrogation et notifications dans Windows Search
Qu’est-ce qui est inclus dans l’index
Processus d’interrogation dans Windows Search