L’article suivant se penche sur mon utilisation du moteur de recherche open source SphinxSearch, mais le fond de ma pensée philosophique peut s’appliquer à tout autre moteur.
Il y a quelques temps, je vous vantais les mérites de ce moteur utilisé sur un projet personnel. Je terminais en disant que j’avais utilisé le moteur un peu en dehors de son champ d’application initial : comme l’avaient déjà fait certains clients de la boite pour laquelle je travaille avec le moteur propriétaire, j’avais utilisé les résultats renvoyés par une requête vide (sans mot clé spécifié) pour lister mes données. Depuis, j’ai utilisé cette méthode sur tout le reste du site pour obtenir un gain de performances non négligeable.
Avant tout, une remise en contexte : on travaille sur un site de contenu adulte, qui liste plus de 300 000 vidéos. On peut présenter les vidéos en triant par date de mise en ligne, nombre de vues, nombre de commentaires, note moyenne. On peut aussi filtrer les vidéos par catégorie et par site de provenance. Les résultats renvoyés sont paginés. Le site est développé sous Symfony.
Tout ça, ça nous donne pas mal de requêtes SQL qui posent problème : l’utilisation des clauses order by et limit peut faire mal. Et dans mon cas, difficile de créer les bon index pour contenter toutes les requêtes. Au bout d’un moment, à force de trifouiller les index à droit à gauche pour essayer de ne pas crouler sous la charge provoquée par mes nouvelles fonctionnalités sans trouver de compromis satisfaisant, j’ai disjoncté et passé la totalité de mes requêtes sous Sphinx.
Seulement, comme je l’ai dit dans un précédent article, Sphinx dans sa version stable actuelle (0.9.9), ne retourne que des entiers dans les flux de résultats. Ainsi, on doit quand même faire une requête MySQL de cette forme pour récupérer les infos qui nous intéressent :
SELECT champ1, champ2 FROM table WHERE id IN (id1, id2, id3…)
Où les idn sont fournis par le retour du moteur de recherche. Pour information, la beta actuelle de Sphinx gère les string. Apparemment, il serait donc dans un futur proche possible de se passer de cette requête MySQL particulière. Mais même actuellement, on gagne grandement en performance car le filtrage des enregistrements sur la clé primaire se fait très rapidement en SQL.
L’autre avantage de cette méthode est qu’il n’y a aucune limite au nombre de tris que l’on voudrait appliquer. J’ai pu me lâcher en effectuant des tris par note, puis nombre de votes, puis pertinence, sans avoir peur d’une baisse de performances, les index de sphinx étant optimisés pour la chose. A cela s’ajoute la possibilité de filtrer facilement les données.
Bref, pour conclure, je n’ai trouvé que des bénéfices à cette façon de faire. Il y a bien des points de vigilance dont il faut être conscients : En passant par sphinx, on complexifie l’application et son code. La maintenance et la reprise du code par un autre développeur peuvent être plus ardues. De plus, en rendant la couche recherche indispensable à la navigation sur notre site, on risque l’indisponibilité totale du service en cas de plantage de Sphinx. Il est ainsi indispensable de déployer des solutions de surveillance du bon fonctionnement du moteur.