L'indexation gagne en puissance

Dans la version 5 de sa solution de recherche pour entreprise, l'éditeur norvégien Fast met en avant sa technique d'indexation des documents. Il explique ainsi la performance de son moteur.

Selon le PDG de l'éditeur norvégien de moteur de recherche Fast Search & Transfer, le volume de données dans les grandes entreprises double tous les ans. Ce qui, mathématiquement, devrait doubler les besoins en serveurs, et donc le budget destiné aux machines liées aux moteurs de recherche. Il n'en est rien. Des éditeurs comme Exalead ou Polyspot ont pris ce problème au sérieux. Fast également. Ainsi, outre des capacités d'administration plus étendues, la dernière mouture d'Enterprise Search Platform du Norvégien serait capable de traiter 2 000 requêtes par seconde sur 40 Petaoctets de données. Ce n'est pas tout. La version 5 d'ESP pourrait intégrer dans son index quelque 200 millions de documents. Et cela sur un seul serveur d'entrée de gamme. Fast met principalement ses performances sur le compte de l'architecture de son index.A l'instar, justement, de son concurrent français Exalead. Ce dernier affiche des performances comparables : 150 millions de pages indexées sur un serveur du même type. Soit, avance son PDG François Bourdoncle, de quoi rentrer l'intégralité du contenu d'un intranet d'un grand compte, sans le courriel.Concrétement, si l'on prend un fichier simple enregistré sous le nom de Bonjour.txt contenant le message ' bonjour DSI ', l'index inversé de ce fichier ressemblera à cela : bonjour:bonjour.txt/DSI:bonjour.txt. Avantage de ce système : les mots ne sont pas indexés deux fois. Ainsi, dans un fichier Aurevoir.txt contenant le texte ' au revoir DSI ', l'index deviendra : aurevoir:aurevoir.txt/bonjour:bonjour.txt/DSI:aurevoir.txt,bonjour.txt. ' L'index ne croît pas en proportion du contenu indexé, mais en fonction de l'ensemble des mots uniques de la totalité des documents ', rappelle Sid Probstein, vice-président chargé de la technologie chez Fast. C'est pourquoi ESP demande moins d'espace de stockage que d'autres solutions.

Dix fois plus performant que Google

L'architecture d'indexation explique aussi les temps de réponse. ' Chaque requête sur ESP entraîne une recherche dans l'intégralité de l'index. Mais ce n'est finalement qu'une opération de lecture. ' Fast estime que sa technique est bien supérieure à celle de ses concurrents. Dont l'inévitable Google. ' Selon les sources, le numéro un du portail de recherche utilise de 10 000 à 20 000 serveurs pour indexer 2 milliards de pages web. ' Fast évalue que cette indexation ne nécessiterait avec sa technologie que 1 500 serveurs.Une chose est sûre : outre leurs propres développements, les éditeurs de moteurs de recherche sont aidés par les constructeurs. ' Techniquement, le matériel avance à grande vitesse, et son coût d'acquisition est moindre ', affirme Yves Simon, de la SSII Hemisphere. Quant à Exalead il considère que ses produits sont à même de tirer totalement parti de l'adressage à 64 bits des nouveaux [e-mail]

Avis d'expert : Yves Simon (SSII Hemisphere) : ' disposer aussi d'outils d'administration efficaces '

' La dernière version du moteur de Fast se caractérise par ses capacités de montée en charge. A périmètre équivalent, la solution peut traiter trois à quatre fois plus d'informations. Cela représente des économies d'échelle faramineuses. Mais le budget n'est que l'une des problématiques des directions informatiques. Une autre est de disposer de bons outils d'administration. Dans ESP 5.0, Fast propose enfin une console simplifiée pour mesurer l'état du trafic, les requêtes émises, celles sans réponse... '

Contrepoint : François Bourdoncle, cofondateur et PDG d'Exalead

' Jusqu'à huit fois moins de machines avec notre solution '
' C'est, en tout cas, ce qui ressort de nos benchmarks internes, où nous avons opposé la solution de Fast à la nôtre. En mars, nous allons sortir la version 4 de notre moteur. En remaniant l'indexation, nous devrions multiplier ses performances par 2,5. Même si le Norvégien a amélioré les capacités de la version 5 d'ESP, nous conserverons notre avantage. '

' Un moteur de recherche est l'inverse d'un SGBD '
' Quand Fast Search & Transfer se mesure au SGBDR d'Oracle, cela n'a pas beaucoup dintérêt... Certes, moteur de recherche et base de données assurent des fonctions comparables. Mais, dès le départ, les SGBD sont optimisés pour les transactions, et non pour les recherches. Nos produits, eux, sont faits pour rechercher, mais ils sont plus lents dans les mises à jour. '