Je profite du billet de Nicolas Morin à propos du moteur Terrier de l'Université de Glasgow pour signaler l’intéressante étude A Comparison of Open Source Search Engines (format PDF) de Christian Middleton et Ricardo Baeza-Yates.
Après avoir envisagé que leur étude puisse porter sur 29 moteurs open source, les auteurs en ont éliminés plusieurs parce qu'ils étaient visiblement non suivis; ils n'ont pas retenu non plus Nutch basé sur Lucene, ni Datapark, mnoGoSearch, Namazu, OpenFTS, et Glimpse dont les temps d'indexation étaient 3 à 6 fois supérieurs aux autres.
Les moteurs effectivement analysés sont donc: ht://Dig, Indri, IXE, Lucene, MG4J, IBM OmniFind Yahoo! Edition, Omega, SWISH-E, SWISH++, Terrier, XMLSearch, Zettair.
- les meilleurs temps d'indexation sont réalisés par: ht://Dig, Indri, IXE, Lucene, MG4J, Swish-E, Swish++, Terrier, XMLSearch, Zettair.
- taille des index, trois groupes peuvent être distingués:
-
- IXE, Lucene, MG4J, Swish-E, Swish++, XMLSearch, Zettair: taille d'index égale 25% à 35% celle de la collection
- Terrier: 50% à 55% de la taille de la collection
- ht://Dig, Omega, OmniFind: supérieure à 100% à 55% de la taille de la collection
- utilisation de la mémoire RAM:
-
- usage constant: ht://Dig, Lucene, XMLSearch
- usage croît linéairement avec la taille de la collection: IXE, MG4J, Swish-E, Swish++, Terrier
- meilleurs temps de réponse: Indri, IXE, Lucene, XMLSearch.
- tests sur une collection de 10 GB divisée en sous-collections:
-
- Indri, IXE, MG4J, Terrier, Zettair seuls capables d'indexer correctement la collection.
- meilleure performance d'indexation: Zettair
"There are some considerations to make, based on the programming language (e.g. to be able to modify the sources) and/or the characteristics of the server (e.g. RAM memory available). For example, if the size of the collection to index is very large and it tends to change (i.e. needs to be indexed frequently), maybe it can be wise to focus the attention on Zettair, MG4J or Swish++, since they are fast in the indexing and searching stages. Swish-E will also be a good alternative. On the other hand, if one of the constraints is the amount of disk space, then Lucene would be a good alternative, since it uses few space and has low retrieval time. The drawback is the time it takes to index the collection. Finally, if the collection does not change frequently, and since all the search engines had similar searching times, you can make a decision based on the programming language used by the other applications in the website, so the customization time is minimized. For Java you can choose MG4J, Terrier or Lucene, and for C/C++ you can choose Swish-E, Swish++, ht://Dig, XMLSearch, or Zettair."