Il est loin le temps ou les internautes, en arrivant sur un site, parcouraient patiemment les divers menu jusqu’à trouver le contenu qui les intéresse. Qui procède encore comme ça aujourd’hui ? On s’imagine mal naviguer dans une arborescence pour trouver un article sur des sites comme wikipedia ou ebay. L’usage, de nos jours, est à la rapidité, que dis-je, à l’immédiateté : une petite recherche et hop ! Le contenu désiré nous tombe tout cru dans le bec.
D’où l’importance cruciale du moteur du recherche, sans lequel un site digne de ce nom ne peut se prétendre utilisable. Et qui dit moteur de recherche, dit prise de tête pour les SI, car les solutions sont nombreuses et hétérogènes. Je vous propose donc un petit tour d’horizon de quelques technologies destinées à intégrer des moteurs de recherches sur vos sites.
Google Search
Bon, commençons par la solution bête et méchante. Tout le monde connait Google ? Et bien Google fournit la possibilité d’intégrer son fameux moteur de recherche sur (presque) n’importe quel site. On copie-colle un petit bout de code sur sa page, et hop !
L’avantage ? C’est la solution la plus simple. Vous n’avez à vous occuper de rien. Les inconvéniants ? Ils sont nombreux ! Vous n’avez aucun contrôle sur les retours, une emprise limitée sur la mise en page des résultats, et puis, vous n’avez bien entendu aucun moyen de contrôler l’indexation du site. À réserver aux « sites persos » des webmasters fainéants ou pressés.
Recherche full text MySQL
Retour aux fondamentaux. La plupart des SGBD majeurs fournissent des index pour la recherche full text, c’est à dire qu’il est possible, via une requête spécifique, d’effectuer une recherche dans un ensemble de champs de types textes.
Avantage : la solution est pratique, lorsque le besoin est simple et très spécifique. En revanche, il faudra mettre les mains dans le camboui, et la solution peut devenir difficile à mettre en œuvre et maintenir lorsque le besoin est un peu plus complexe. Et puis, selon la volumétrie, les perfs ne sont pas au top. Au final, les possibilités restent un peu limitées.
Doctrine Search Behavior
Je mentionne la solution qui me semble injustement peu connue. L’ORM Doctrine, embarqué avec symfony, propose un behavior qui permet de générer automatiquement un index full text.
Une solution pratique et rapide pour gérer un moteur de recherche sur des sites batis avec ce framework.
# schema.yml
Product:
actAs:
Searchable:
fields: [title, description]
# ...$products = Doctrine::getTable('product')->search('clavier pour blonde');
C’est facile, c’est rapide, que demande le peuple ?
MNoGoSearch
mnoGoSearch est un moteur de recherche écrit en C et composé de deux parties : d’une part, un crawler (indexeur) capable de naviguer sur des pages html ou en texte pur, et une interface de requête pour effectuer les recherches.
MnogoSearch fonctionne « à la Google », le robot explore régulièrement votre contenu, et construit son index ainsi. L’avantage, c’est que vous détenez la main sur la configuration de l’indexeur. MnogoSearch est capable d’indexer des sites en plusieurs langues, des groupes de sites, supporte plusieurs bases de données, et il vous sera possible d’effectuer vos requêtes via des fonctions PHP.
En bref, MnogoSearch est parfait si vous souhaitez mettre en place un moteur de recherche basique sur vos pages de contenu, tout en contrôlant la teneur de votre index.
Sphinx
Sphinx est un autre moteur de recherche full text, écrit en C++. Sa particularité ? Sphinx a été spécialement conçu avec la performances à l’esprit. Si l’on en croit les benchmarks (j’avoue ne jamais l’avoir testé en personne), il poutre tout simplement les performances d’une recherche full text basique de mysql, et l’enlève honorablement sur mnogosearch.
Sphinx est donc capable d’indexer une énorme quantité de documents (plusieurs gigas) à une grande rapidité, et d’effectuer des recherches en un temps record. Il est capable d’indexer des données provenant de plusieurs sources (c’est à dire, ce n’est pas qu’un crawler de pages web), et fournit des apis dans la plupart des langages majeurs.
Il est de plus relativement facile à mettre en place, ce qui en fait un bon choix de moteur de recherche. D’ailleurs, Sphinx est utilisé par des gros projets, tels que thepiratebay, mininova, craigslist, ou dailymotion.
Lucène / Solr
Alors là, c’est la Rolls-Royce des moteurs de recherche. Lucène / Solr, écrit en Java, est sans doute le moteur de recherche libre le plus puissant du moment, fournissant toutes les fonctionnalités dont vous aviez rêvé (requêtes booléennes, recherche par facette, réplication, recherche distribuée, etc.).
Pour être exact, Lucène est la bibliothèque d’indexation et de récupération de données. Solr, qui encapsule Lucène, est un moteur de recherche complet qui fournit une interface sous forme d’API XML / JSON.
Si vous souhaitez avoir une idée de la manière dont on installe, configure et utilise Solr, je vous laisse consulter mon tutoriel sur l’intégration de Solr à Symfony.
Dans la plupart des cas, si votre besoin présente un minimum de complexité, Solr est la technologie à employer. L’inconvéniant ? La configuration de la bête requiert certaines compétences, et les ressources nécessaires à faire tourner le servlet java ne sont pas négligeables. Solr / Lucène reste, dans tous les cas, une excellente solution de moteur de recherche.
Zend Lucène
Pour terminer notre tour d’horizon, j’aimerais introduire pour ceux qui ne connaissent pas le projet Zend Lucène. Zend Lucène, qui fait partie du Zend Framework, est une réimplémentation de Lucène en php. Le moteur de recherche fonctionne via une api php, et l’index généré est compatible avec Solr.
Cette solution est d’une extrème simplicité, il devient possible de mettre en place un moteur de recherche full php puissant avec une simplicité et une rapidité déconcertante. La documentation de Symfony fournit d’ailleurs un exemple d’implémentation.
En revanche, les performances ne sont pas au rendez-vous, et si le nombre d’objets indexés devient trop important (plusieurs dizaines de milliers), Zend Lucène deviendra vite inutilisable. À réserver pour les besoins spécifiques, mais à la volumétrie limitée.
Conclusions
J’espère que ce petit tour d’horizon, volontairement synthétique, vous aura présenté quelques informations utiles. Il reste très incomplet, j’ai omis certaines technos qui me paraissaient peu fiables ou plus mises à jour, ou tout simplement parce que je ne les connais pas. Je me suis également limité aux technologies libres.
Et vous, vous utilisez quoi pour votre moteur de recherche ?



10 Commentaires
J’utilise la recherche full text MySQL, et je dois dire que pour le moment ça m’a toujours suffit….
En tous cas merci pour cet article vraiment très interressant !
Tu as des retours sur la volumétrie de l’index Doctrine ? Parce que ça crée des tables et des liaisons supplémentaires.
Et le fulltext avec Doctrine c’est galère. Obligé de passer par la méthode RawSQL à moins d’être avec Doctrine 1.2 … où un patch vieux de 10 mois a été implémenté.
Salut Oncle Tom, désolé, je n’ai pas d’infos sur la volumétrie, je n’ai jamais utilisé cette solution en production.
Voir aussi Xapian : http://xapian.org/
Bonjour a tous,
J’ai qq problemes avec Doctrine Search Behavior utilisant une table i18n.
schema.yml :
Event :
actAs :
Timestampable : ~
I18n :
fields : [title, content, tags, city]
Searchable :
fields : [title, tags]
Le snippet :
$events = Doctrine::getTable(’Event’)
->getTemplate(’Doctrine_Template_I18n’)
->getPlugin()
->getTable()
->getGenerator(’Doctrine_Search’)
->search($s) ;
Erreur : « Generator Doctrine_Search not loaded »
Need Help !
Merci
j’ai une petite question,
est ce que solr peut se substituer à une base de données ?
Par exemple pour un site d’annonces ou autre, où le contenu ne changent pas de façon trop soutenu, est ce que solr peut contenir les informations où il faut utiliser une base de données et solr vient en secours …
Hola Malheureux ! Ne mélangeons pas les torchons et les serviettes ! Une base de donnée, c’est fait pour … stocker des données. Solr sert à effectuer des recherches sur des données. Solr ne vient pas en secours, ce sont deux outils aux rôles parfaitement distincts.
Dans le cas où les données ne sont pas faites pour durer, dans le temps qu’elles sont utilisé elles sont stockés dans des fichiers XML, pas très super niveau perf c’est pas ce qu’on demande vu qu’il y a solr.
Du coup le XML sert à stocker et solr a chercher, c’est pas bon comme schéma ?
heu si non pourquoi
Ben si, c’est parfait si tu aimes plomber les perfs de ton appli et te complexifier la vie