Google Search Appliance : alternative viable au moteur de recherche de MOSS 2007 ?
Contexte
Il y a quelques temps j’ai eu l’occasion de m’intéresser à la Google Search Appliance (GSA), la solution de recherche en entreprise made in Google. L’objectif était d’indexer quelques centaines de milliers de documents, essentiellement situés dans des sites WSS, et de permettre une recherche intégrée à SharePoint Portal Server 2003. Face à la GSA, d’autres moteurs étaient testés, dont celui de MOSS.
Architecture
La Google Search Appliance est un serveur physique à part entière. Sous la forme d’un ou de plusieurs racks, ce serveur comprends tous les services nécessaires à la recherche : exploration, indexation, interrogation et administration.
La recherche dans MOSS 2007 nécessite un service d’index, un service de recherche et un ou des serveurs frontaux. Dans la pratique ces services peuvent être sur la même machine. Pour tenir la montée en charge, il est toutefois conseillé de séparer l’indexation des frontaux web. Les fichiers d’index sont alors propagés sur les frontaux, ce qui peut potentiellement prendre du temps selon la taille et le type des données indexées.
Exploration
MOSS 2007 et la Google Search Appliance (GSA) ont un fonctionnement commun : des URL leur sont fournies comme point de départ d’exploration et les moteurs se débrouillent en suivant les liens. Surprise en ce qui concerne les sites WSS v 2.0, puisque MOSS 2007 ne les reconnaît pas comme des sites internes, mais qu’il doit donc les crawler comme n’importe quel autre site externe au lieu d’interroger la base SQL Server associée. Il faudra donc fournir les URL de tous les sites WSS à indexer, tout comme pour la GSA. Une page listant tous ces sites pourra donc être très utile. Les deux moteurs peuvent indexer d’autres éléments. Google peut attaquer des bases de données et MOSS 2007, via le Business Data Catalog, peut indexer lui aussi des bases de données… mais aussi des Web Services. Donc potentiellement du SAP, du Siebel, des données collectées par BizTalk, etc.
Du côté de l’administration, il est possible pour les deux moteurs de planifier l’exploration à heure fixe, ou de faire une exploration continue. Il est possible de définir des credentials pour l’accès à chacun des serveurs avec la Google Search Appliance. Bref, que ce soit pour la GSA ou pour MOSS 2007, l’exploration est suffisamment flexible pour accéder au contenu sans que cela s’en ressente.
Indexation
Les algorithmes de la GSA sont d’une puissance impressionnante. D’ailleurs, comparé au moteur de SPS2003, la pertinence des réponses de la GSA est sans commune mesure. Mais par rapport à MOSS 2007 ce n’est pas aussi évident.
En effet, la principale amélioration de la recherche avec MOSS 2007, c’est bien les algorithmes de recherche. Je n’ai pas suffisamment d’élément pour déterminer si l’un est meilleur que l’autre. Quoi qu’il en soit, les moteurs ont chacun leurs atouts. MOSS 2007 indexe des métadonnées propres à SharePoint là où la GSA ne peut que s’appuyer sur le contenu des sites indexés. De son côté, la GSA bénéficie d’un système de « feeds », c'est-à-dire un mécanisme qui permet de pousser du contenu et de l’associer à des données déjà indexés. Ainsi, la GSA est en mesure d’ajouter ses propres métadonnées sous peu qu’on développe un outil pour s’en occuper. La GSA peut donc rattraper MOSS 2007 sur les metadonnées, mais l’effort d’intégration peut être très conséquent.
Sécurité
La sécurité a été revue côté SharePoint, ceci pour éviter que des informations confidentielles ne remontent malencontreusement dans les résultats de la recherche. Un utilisateur ne voit donc que les résultats auxquels il a accès.
Du côté de la Google Search Appliance, les choses se compliquent considérablement. Il existe en réalité trois modes d’interrogation. L’interrogation peut être faite sur un contenu public, c'est-à-dire accessible à tout le monde. La recherche est alors très rapide et tout se passe bien. L’interrogation peut également être lancée sur un contenu sécurisé. La Google Search Applicance fait alors une série de requête HEAD avec les credentials de l’utilisateur pour déterminer à quels sites il a accès. Le serveur s’arrête lorsqu’il a trouvé suffisamment de sites accessibles et affiche les résultats. Premier constat : la performance de la recherche dépend énormément de l’utilisation des serveurs, mais aussi de l’état du réseau entre les données indexées et la Google Search Appliance. J’ai personnellement fréquemment attendu 5 à 10 secondes avant d’obtenir les résultats des recherches (sur une base de plusieurs centaines de milliers de documents indexés). Pas de problème pour utiliser la GoogleBox avec NTML… en revanche avec Kerberos c’est une autre paire de manches. La « solution » proposée par Google s’appuie sur le protocole SAML : "l'Access Connector". Il faut installer un serveur Web et configurer la Google Search Appliance pour qu’elle redirige les requêtes vers ce serveur. Le serveur hébergeant ce site Web doit être marqué comme « Trusted for delegation » par le controleur de domaine et le pool d’application doit tourner avec un compte bénéficiant de privilèges particuliers. Enfin, avec Kerberos, la commande setSPN est de rigueur pour le bon fonctionnement du site Web. Autrement dit, c’est très contraignant, pas sans impact pour les applications hébergées sur le même serveur… et c’est potentiellement des risques de sécurité supplémentaires. Enfin, la mise en place d’une telle solution se fait sentir en termes de performances… car il m’a fallu plusieurs dizaines de secondes avant d’obtenir les résultats. Et encore, une requête sur deux tombe en TimeOut (dans ce cas les résultats trouvés avant le TimeOut devraient remonter... mais il cette partie semnle bien buggée) . Bref, la sécurité consitue LE point noir de la Google Search Appliance. J’ai néanmoins pu obtenir de meilleurs résultats en limitant l’accès à la Google Search Appliance pour que seuls les serveurs frontaux de SharePoint puissent y accéder. J’ai passé tous les documents en public et j’ai créé une WebPart « proxy » interrogeant la googleBox et réalisant des requêtes head pour filtrer les résultats. C’est le meilleur résultat que j’ai pu obtenir avec cette solution.
Rendu des résultats
La Google Search Appliance propose une interface permettant de modifier le rendu des résultats en quelques clics (logo, barre de navigation, …). Il s’agit en réalité d’un fichier de transformation XSL qu’il est possible de modifier à loisir. Bref, la partie rendu est un véritable bonheur.
Côté MOSS c’est encore mieux. Le XSL a lui aussi fait son apparition (http://www.wssdemo.com/blog/Lists/Posts/Post.aspx?ID=222), mais l’interface de résultats de la recherche bénéficie également d’une intégration accrue des outils Office. Il est possible d’obtenir le même résultat avec la Google Search Appliance, mais avec de (trop) gros efforts d’intégration.
Autres Fonctionnalités
La Google Search Appliance dispose des OneBox. Il s’agit d’une sorte d’add-in permettant d’associer des données aux résultats de la recherche. Par exemple, une recherche sur l’annuaire va ramener une liste de personnes. Le module OneBox va permettre d’ajouter des données comme l’agenda du jour des personnes remontées. Bref, toujours contre quelques efforts d’intégration, il est possible de faire des choses très sympathiques. La GSA bénéficie également d’un système d’interrogation puissant sous réserve que les utilisateurs sachent s’en servir. La syntaxe permet de restreindre la recherche à certains sites, des caractères clés permettent de faire de vraies recherches booléennes, et la recherche est multi-langue… un véritable multi-langue qui marche bien et que je ne m’explique toujours pas. On retrouve la gestion de l’orthographe approchée, la mise en relief des mots recherchés dans les résultats, le filtrage des sites redondants…
MOSS 2007 m’a surpris tellement il avait d’améliorations. Il est possible de faire des recherches sur des colonnes de liste particulières et ainsi, par exemple, de rechercher tous les utilisateurs qui parlent allemand, toutes les news ayant été écrites par madame Z, etc. La recherche avancée bénéficie également d’un multi-langue pas complètement fonctionnel. En effet, celui-ci s’appuie sur les méta-données des documents office… c’est donc uniquement les documents Word qui en bénéficient. On retrouve également une orthographe approchée, la mise en relief des mots recherchés dans les résultats, le filtrage des sites redondants… bref, des notions qui faisaient défaut à SPS 2003.
Licences
La Google Search Appliance est à 30 000€ pour 500 000 documents. Le prix augmente ensuite avec le nombre de documents indexés. Il faut d’ailleurs passer un peu de temps à customiser l’indexation pour ne pas se retrouver avec la même page Web indexée plusieurs milliers de fois à cause d’un paramètre qui diffère à la fin de l’URL.
Pour MOSS, la question des licences se pose différemment selon l'utilisation de MOSS Server for Search ou de MOSS.
Conclusions
La Google Search Appliance a donc des atouts, comme sa pertinence et sa flexibilité, mais elle ne s'intégrera pas dans SharePoint sans des frais d'intégration très conséquents. Compte tenu des moteurs actuels, elle ne trouve pas beaucoup sa place dans MOSS. D'avantage au sein de sites WSS selon moi.
Malgré une prochaine version censée être plus rapide (Access Connector intégré à la GSA), la Google Search Appliance n'est pas à son aise avec Kerberos et perd énormément d'intérêt. Bref, c'est une solution viable seulement s'il n'est pas question de sécurité... ce qui semble inconcevable avec la recherche en entreprise.
Ressources
[MAJ : vous trouverez la suite de cet article "un an après" sur ce blog : http://blogs.developpeur.org/gribouillon/archive/2008/04/01/google-search-appliance-et-sharepoint-un-an-apr-s.aspx]
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
