Planifier le schéma d’index (FAST Search Server 2010 for SharePoint)

Mise à jour : 10 février 2011

Ff599529.Important(fr-fr,office.14).gifImportant :

Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Cet article contient des observations sur la planification du schéma d’index dans Microsoft FAST Search Server 2010 for SharePoint. Le schéma d’index permet de spécifier les propriétés gérées qui peuvent faire l’objet d’une recherche dans l’index de recherche et les fonctionnalités d’indexation et de requête associées à ces propriétés.

Dans cet article :

  • Vue d'ensemble du schéma de l'index

  • Propriétés analysées et managées

  • Fonctionnalités de pertinence

  • Fonctionnalités d'optimisation de requête

Vue d'ensemble du schéma de l'index

Le schéma d'index vous permet de configurer les fonctionnalités suivantes :

  • Les propriétés à inclure dans l'index. Vous définissez le mappage de propriétés analysées sur des propriétés gérées et les fonctionnalités de l'index associé.

  • Index de texte intégral. Cela définit la façon d'appliquer des requêtes de texte intégral par rapport à un ensemble de propriétés gérées.

  • Classez les profils. Cela définit la façon d'obtenir un jeu de résultats trié par rang.

  • Affinage de la requête. Cela décrit la façon dont les statistiques d'informations sur les propriétés gérées peuvent être retournées dans les résultats de requête et utilisées pour l'optimisation de requête.

Vous devez envisager la stratégie de schéma d'index avant de déployer une batterie de serveurs à grande échelle FAST Search Server 2010 for SharePoint. Assurez-vous que vous envisagez de la stratégie globale d'index de schéma avant de commencer l'indexation de grandes quantités de contenu. Dans le cas contraire, vous devez réindexer tout le contenu pour les modifications prennent effet. Il est possible d'apporter des modifications incrémentielles à la correspondance sans interruption de service ou des interruptions de service de recherche, mais il est très peu de pratique appliquer des modifications importantes après avoir indexé grande quantité de contenu.

Si votre déploiement indexe de nombreux documents millions, il est recommandé de régler le schéma d'index et associé à l'utilisateur final les fonctionnalités de recherche sur une installation plus réduite de test avec un sous-ensemble approprié du contenu que vous voulez indexer.

Le plan de schéma de l'index doit prendre en compte deux aspects principaux :

  1. Le principal objectif pour le plan de schéma d'index consiste à définir la fonction de votre choix pour votre application.

  2. Certaines fonctionnalités de schéma d'index aura un impact significatif sur la batterie de serveurs de fastsearch cotation. Lorsque vous activez certaines fonctionnalités, cela peut avoir un impact significatif sur l'utilisation des ressources dans la batterie de serveurs et peut par conséquent un impact sur le dimensionnement de votre batterie de serveurs.

Cet article traite des aspects clés du schéma d'index que vous devez prendre en considération lors de la phase de planification. Les articles suivants fournissent des détails supplémentaires concernant divers aspects du schéma de l'index :

Propriétés analysées et managées

Éléments indexés sont constitués de plusieurs propriétés, qui reflète le contenu réel et les métadonnées pour les articles.

Propriétés analysées

Les propriétés analysées sont extraites de sources de contenu afin de rendre les données disponibles pour la recherche de métadonnées. Les propriétés analysées sont généralement signalées par les connecteurs d'indexation, mais peuvent également être créées au cours de traitement par un IFilter ou d'un extracteur de propriété.

Une propriété analysée est définie de manière unique par nom, Propset et VariantType.

Chaque propriété analysée appartient à une catégorie de propriété analysée, qui est un regroupement de haut niveau des propriétés analysées en fonction de l'iFilter et Protocol Handler (accordé par le connecteur de l'indexation utilisée et la source de données) est utilisé pour extraire les métadonnées à partir du contenu.

Exemples de catégories :

  • Données de l'entreprise – les métadonnées qui est associée au contenu du catalogue de données métiers.

  • Courrier-ces métadonnées sont associée à Microsoft Exchange Server.

  • Office – les métadonnées contenues dans les documents Microsoft Office comme Word, Excel, PowerPoint, etc..

  • Personnes – les métadonnées qui sont associée avec les profils d'utilisateurs dans SharePoint. La majorité d'entre elles sont également mappés sur différentes des propriétés gérées à partir de Active Directory et les informations de SharePoint.

  • Site Web – les métadonnées HTML associées aux pages web.

Un sous-ensemble de toutes les propriétés analysées est mappé automatiquement à l'index de texte intégral par défaut. Cela signifie qu'une requête de mot-clé simple correspondra le contenu de toutes ces propriétés. Plusieurs propriétés analysées de contenir des métadonnées sont sans pertinence ou être défectueux d'effet sur la pertinence de la recherche. Les conditions de décident si une propriété analysée est automatiquement mappée sont les suivantes :

  • Uniquement des propriétés avec des types variant correspondant à une chaîne ou une liste de chaînes analysées.

  • Analysé les propriétés qui sont connues pour fournir le contenu non souhaité dans l'index de recherche sont exclus en définissant leur propriété IsMappedToContents “ false ”.

  • Étant donné que chaque propriété analysée appartient à une catégorie (déterminée par sa propset), la catégorie a une propriété booléenne (MapToContents) qui définit la valeur par défaut de la propriété IsMappedToContents des nouvelles propriétés analysées.

Pour plus d'informations sur le mappage de propriété analysée, voir la rubrique Mappage des propriétés analysées (FAST Search Server 2010 for SharePoint).

Propriétés gérées

Les propriétés gérées sont les métadonnées qui peuvent être recherchées ou utilisée d'autres manières, par exemple, qui est affichée dans les résultats de recherche.

Les propriétés analysées contient une grande quantité de métadonnées de différentes propriétés. Une clé phase de votre planification de déploiement consiste à déterminer que le mappage de ces les propriétés analysées sur des propriétés gérées. Dans l'écran la plus simple, un index de recherche peut contenir la représentation sous forme de recherche du corps et le titre d'un document. Mais vous rencontrerez rapidement la puissance de mappage et en indexant les métadonnées de vos sources de contenu différents. En utilisant les services de gestion de schéma FAST Search Server 2010 for SharePoint, vous pouvez explorer les propriétés analysées les sources de contenu et décidez d'un mappage vers les propriétés gérées. Vous pourrez affecter des fonctionnalités pour les données managées propriétés qui fournissent un valeur ajoutent à l'utilisateur final lorsqu'ils effectuent sa requête.

Le schéma d'index par défaut fournit des mappages par défaut qui sont adaptés aux formats de contenu courantes. Comme le système de pertinence optimisé, examinez la qualité du contenu dans les propriétés gérées, déterminer s'il existe d'autres propriétés analysées qui ont une meilleure qualité pour votre contenu et mettre à jour les mappages.

Vous devez effectuer un réglage initial du mappage de propriété analysée sur une installation de test avec une quantité limitée de contenu. Cela rend beaucoup plus facile de tester vos modifications.

Vous pouvez activer l'optimisation de requête pour une propriété gérée à l'aide d'une configuration raffineur.

Vous pouvez associer une propriété gérée à un ou plusieurs index de texte intégral.

Fonctionnalités de pertinence

Vous pouvez activer et modifier un ensemble de fonctionnalités qui affectent le tri d'intérêt pour de résultat de requête. Cet article se concentre principalement sur l'effet sur les performances de ces fonctionnalités, comme cela peut être important de savoir avant de dimensionnement de votre batterie de serveurs FAST Search Server 2010 for SharePoint. Pour plus d'informations sur la façon dont vous pouvez optimiser la pertinence de votre installation de la batterie de serveurs FAST Search Server 2010 for SharePoint, voir la rubrique Paramétrer la pertinence (FAST Search Server 2010 for SharePoint).

Index de texte intégral

Plusieurs propriétés gérées peuvent être regroupées en un index de texte intégral. Ainsi, une requête à exécuter sur plusieurs propriétés gérées en même temps. Index de texte intégral permettent d'avoir la priorité dynamique de requêtes (résultats triés par pertinence). Lorsque vous tapez une série de mots dans la zone de recherche de votre requête front-end, cela débouche généralement sur une requête par rapport à l'index de texte intégral par défaut nommé content. Il est également possible d'interroger des propriétés gérées séparément, mais ces correspondances de la requête ne contribue pas au classement du résultat de requête.

Un index de texte intégral contient généralement un ensemble de propriétés gérées qui représente le contenu de l'élément que vous interrogez. Cela inclut le corps de l'élément, le titre, l'URL et ainsi de suite.

Dans certains cas, il peut être souhaitable de définir plusieurs index de texte intégral pour les différents types de requêtes ou des applications différentes. Bien que cela donne une grande quantité de flexibilité, elle aura un certain coût pour l'espace disque et l'utilisation des ressources système telles que les descripteurs de fichiers de performances. Il est donc pas recommandé de définir des index de texte plus de 10 à l'intérieur d'un schéma de l'index.

Profils de rang

Personnaliser les profils de rang et la création de nouveaux profils rang a petit d'effet sur les ressources système statiques telles que mémoire et espace disque. Les fonctionnalités de profil rang sont généralement du temps de requête les paramètres n'affectent pas l'indexation des éléments et l'espace disque associé. L'effet des modifications apportées aux profils de rang a principalement effet de performances de requête comme indiqué dans la liste suivante.

  • Seuil d'arrêt-mot. Il s'agit d'un paramètre important pour éviter que les requêtes pour les mots très courantes prend trop de ressources pour évaluer. Afin de toujours fournir une pertinence juste de classement des correspondances de l'élément avec cet entrée du glossaire, vous devez utiliser la fonctionnalité de niveau d'importance dans le schéma d'index.

  • Booster de propriété gérée. Il s'agit d'un moyen efficace d'atteindre le booster de pertinence ciblées pour les documents que vous avez déjà géré des propriétés de certaines valeurs. Chaque augmentation de la propriété gérée définition va ajouter à la période d'évaluation pour toutes les requêtes. Par conséquent, veillez à ne pas définir trop de ce type augmente dans le même profil de rang. Il est préférable de définir plusieurs profils de rang avec l'augmentation de la propriété managée cible la définition.

Pour plus d'informations sur les fonctionnalités de profil de classement, consultez À propos du profil de classement (FAST Search Server 2010 for SharePoint).

Tri de texte intégral

Tri des résultats de texte intégral après permet des propriétés managées que vous avez pour obtenir un tri par ordre alphabétique de résultats au lieu de tri par défaut en fonction de leur pertinence (classement). Fourniture de tri efficace sur le résultat jeu nécessite des structures de données supplémentaires dans l'index, et cette fonctionnalité est donc configurable par la propriété gérée.

Définir plusieurs propriétés managées que tri est activée aura un impact significatif sur l'utilisation de la mémoire dans le composant de requête correspondante.

Vous pouvez contrôler cette fonctionnalité via le paramètre de propriété gérée SortableType dans le schéma d'index.

Envisagez d'utiliser la valeur de configuration LatentSortable si vous souhaitez préparer les structures de données d'index pour le tri des résultats, mais il ne souhaitez pas activer la fonction encore pour l'évaluation de la requête. Lorsque vous utilisez cette option les structures de données requis pour le tri des résultats n'est pas chargé dans la mémoire principale, et elle n'aura donc aucun effet sur les performances. Le paramètre peut ultérieurement être modifié à partir de latente à active afin d'activer la fonctionnalité. Dans ce cas, la modification aura effet immédiat (aucune exigence pour les éléments de la réindexation).

résumé avec la correspondance en surbrillance

FAST Search Server 2010 for SharePoint inclut un générateur de synthèse automatique configurable qui peut générer des résumés mis en surbrillance d'accès pour les propriétés sélectionnées dans les résultats de requête en fonction de la requête d'entrée. Vous pouvez contrôler cette fonctionnalité via le paramètre de propriété gérée SummaryType dans le schéma d'index. Par défaut, la synthèse en surbrillance d'accès est configurée pour les propriétés titlebody.

Configuration d'accès Création résumée en surbrillance pour les autres propriétés gérées auront un impact sur les performances de la création de résultat de requête, en particulier si la propriété gérée, en moyenne contient beaucoup de texte.

Un paramètre de performance clés qu'affecte atteinte création résumée en surbrillance est le paramètre de MaxResultSize de propriété gérée dans le schéma d'index. Cela affecte la quantité de contenu textuel de la propriété gérée est stockée avec l'index. Pour les propriétés gérées qui ne sont pas configurées pour obtenir d'accès résumé en surbrillance ce paramètre affecte la quantité de contenu qui est retournée dans la requête aboutit, avec un effet direct sur les performances des requêtes. Cela s'applique en particulier pour les accès disque et les e/S réseau. Pour les propriétés gérées qui est configuré pour obtenir d'accès résumé en surbrillance ce paramètre affecte la charge de traitement de la création de la synthèse en surbrillance d'accès pour chaque test dans la liste d'accès de requête.

Optimisation de pertinence de langue d'Asie

Chinois, japonais et coréen langues nécessitent la normalisation des caractères/mot différent que la plupart des autres langages. Ces langues n'utilisent pas espaces régulièrement pour marquer des limites de jetons ; textes dans ces langues doivent être jetons par un composant de création de jetons propres aux langues. Nous appelons CJC langues pour ces langues.

FAST Search Server 2010 for SharePoint effectue de la création de jetons spécifiques langue basée sur la détection automatique de la langue pour les éléments indexés et les paramètres régionaux de l'utilisateur final, mais en prenant une approche alternative la normalisation appelée recherche de sous-chaîne.

Recherche de sous-chaîne, souvent appelée recherche N-g, est généralement appliqué à des propriétés gérées qui sont considérés comme étant difficiles à transformer automatiquement. Ces textes contiennent souvent plusieurs mots rares ou les mots nouveaux, tels que les noms de produits ou de mots rarement figurant dans le dictionnaire de système du Générateur de jetons de.

La fonctionnalité peut également prendre en considération lorsque le rappel (le nombre total de documents récupérés) est considéré comme beaucoup plus important que la précision (haute pertinence des résultats). Sans la recherche de sous-chaîne activé, une requête de CJC peut, dans certains cas, être jetons incorrecte et par conséquent retourner une liste de résultats meager ou vide. Cela n'aura jamais lieu si la recherche de sous-chaîne est utilisé, comme toutes les sous-chaînes de N gramme de chaque jeton ne sont pas indexés, ainsi que N-g s'étendant sur des limites de jetons. À l'aide de cette fonctionnalité, vous améliorez le rappel (plus élément correspondant trouvé), mais peut également réduire la précision et renvoyer plus d'éléments que vous le souhaitez.

Vous pouvez contrôler cette fonctionnalité via le paramètre de propriété gérée SubstringEnabled dans le schéma d'index.

Notez que la recherche sous-chaîne auront un effet important sur la taille de l'index de ces propriétés gérées. Il est donc pas recommandé que vous utilisez la fonction de texte libre, mais pouvez être considérées comme des métadonnées qui contient les noms de produit spécifique au domaine, des codes et ainsi de suite.

Fonctionnalités d'optimisation de requête

Fonctionnalités d'Optimisation de requête fournissent de l'utilisateur final à l'aide d'options de raffinement pertinents pour leurs requêtes. Il permet la descente dans un résultat de requête à l'aide des données statistiques agrégées calculées pour le résultat de requête. Ceci est généralement utilisée pour les métadonnées associées aux éléments indexés, telles que la date de création, les noms d'auteur et de la personne qui apparaît dans l'élément. En utilisant les options d'optimisation, vous pouvez affiner votre recherche uniquement les éléments présents créé dans une certaine période de temps ou n'afficher que les éléments faisant référence à une personne donnée.

FAST Search Server 2010 for SharePoint prend en charge deux types de requête raffineurs, raffineurs approfondies et raffineurs partielle.

Profondes raffineurs

L'optimisation de requête est basée sur l'agrégation des statistiques de la propriété gérée pour l'ensemble des résultats d'une requête de recherche. L'indexeur crée les données d'agrégation sont utilisées dans une requête de filtrage de processus. L'avantage de l'utilisation de ce type est que les options de raffinement reflètent tous les éléments correspondant à une requête. Il s'agit généralement du mode recommandé, mais raffineurs approfondies de la définition peut avoir un impact significatif sur l'utilisation de la mémoire dans le composant de requête correspondante.

Envisagez d'utiliser le paramètre de configuration LatentRefinement si vous voulez préparer les structures de données d'index pour optimisation complète, mais il ne souhaitez pas activer la fonction encore pour l'évaluation de la requête. Lorsque vous utilisez cette option les structures de données requis pour l'optimisation complète n'est pas chargé dans la mémoire principale, et elle n'aura donc aucun effet sur les performances. Le paramètre peut ultérieurement être modifié à partir de latente à active afin d'activer la fonctionnalité. Dans ce cas, la modification aura effet immédiat (aucune exigence pour les éléments de la réindexation).

Ff599529.Important(fr-fr,office.14).gifImportant :

Navigateurs d'une chaîne comportant de nombreuses valeurs uniques a considérablement les performances impact sur la communication interne de l'E/S entre le nœud correspondant de requête et la nœud (si ils sont sur différents serveurs) de traitement de requête. Si votre installation comporte des index de colonnes, cette interface peut devenir un goulet d'étranglement. Dans ce cas, envisagez d'utiliser le paramètre de configuration CutoffMaxBuckets pour limiter le nombre d'emplacements de raffinement à être évaluée sur chaque colonne d'index.

Peu profonds raffineurs

L'optimisation de requête est basée sur l'agrégation de statistiques de la propriété gérée pour les 100 résultats supérieur d'une requête de recherche. Les données de résultat de raffinement sont créées au cours du traitement du résultat. Dans la mesure où le perfectionnement est limitée à la partie supérieure de la correspondance des résultats, il est impossible de trouver les résultats masqués plus approfondie dans les résultats de requête. D'autre part, cette option d'optimisation n'affecte en rien le processus d'indexation et peut donc s'appliquer immédiatement une fois activée.

Peu profonds raffineurs ont effet de réduire considérablement les performances sur la nœud de traitement de requête et réduiront les performances des requêtes. Envisagez plutôt l'utilisation de deep raffineurs.

Ff599529.note(fr-fr,office.14).gifRemarque :

Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.

Historique des modifications

Date Description Raison

10 février 2011

2011/02/07

Mise à jour du contenu

12 mai 2010

Publication initiale