Projet IDAPA

Accueil > Bases de données relationnelles et indexation du contenu > Rapport - Partie 4

Rapport - Partie 4

Conclusion, la solution choisie

vendredi 6 février 2009, par Yoann Moreau

6. La solution retenue

Le choix d’une des solutions est complexe car on ne peut estimer avec beaucoup de précision les performance en terme de temps de calcul de chacune, on ne peut se baser que sur des complexités théoriques dépendant fortement de l’implémentation des outils utilisés. Plusieurs articles débattent sur la gestion de données de taille importante, mais ces solutions ne sont pas comparées entre elles et les résultats ne sont pas généralisés mais basés sur des exemples précis. Les critères de choix ont donc aussi été l’avenir possible du projet et le côté pratique d’utilisation.

La solution sans MySQL a été écartée en premier car elle suppose la recherche par index moins efficace qu’un parcours total des données, or plusieurs articles s’accordent à dire qu’un parcours total est plus rapide lorsque les résultats dépassent une certaine proportion de l’ensemble des données. Selon les avis ce seuil varie entre 5 et 20% de la base. On suppose que la taille de l’entrepôt est si grande que les informations recherchées seront toujours très rares par rapport à l’ensemble. De plus l’utilisation de MySQL offre de nombreuses fonctionnalités qui pourraient s’avérer utiles si les besoins de l’entrepôt venaient à évoluer.

L’efficacité des solutions de Sphinx et de Indri semble comparable et aucune étude ne les compare avec précision. Le choix a donc été fait dans l’optique de permettre une meilleure évolution du projet. Indri Search Engine fait partie du projet Lemur mené par un laboratoire d’université et est donc développé par une équipe de chercheurs, alors que le projet Sphinx est développé par une unique personne. Indri a remporté de nombreux concours et est sûrement amené à être amélioré à l’avenir. La solution de Indri sépare le stockage des données et l’indexation fulltext, ce qui pourrait permettre des modifications et évolutions sans devoir tout changer.

C’est donc la solution MySQL + Indri qui a été retenue, ces deux outils seront paramétrés pour être adaptés au projet et utilisés et synchronisés au travers d’un programme de script programmé en Ruby. La partie scoring exécutera les opérations au travers de ce programme (utilisé directement en tant qu’exécutable), et lira les données directement dans le serveur MySQL. Les opérations créeront donc des tables temporaires qui pourront être importées directement par la partie scoring.