Comparaison des moteurs de recherche plein texte - Lucene, Sphinx, Postgresql, MySQL ?

Question

Je suis en train de construire un site Django et je cherche un moteur de recherche.

Quelques candidats :

• Lucene/Lucene avec Compass/Solr

• Sphinx

• Recherche plein texte intégrée à Postgresql

• Recherche plein texte intégrée MySQl

Critères de sélection :

• pertinence et classement des résultats
• vitesse de recherche et d'indexation
• la facilité d'utilisation et d'intégration avec Django
• ressources nécessaires - le site sera hébergé sur un VPS donc, idéalement, le moteur de recherche ne devrait pas nécessiter beaucoup de RAM et de CPU.
• évolutivité
• des fonctions supplémentaires telles que "Vous voulez dire ?", des recherches connexes, etc.

Si vous avez eu une expérience avec les moteurs de recherche ci-dessus, ou d'autres moteurs ne figurant pas dans la liste, j'aimerais connaître votre avis.

EDIT : En ce qui concerne les besoins d'indexation, comme les utilisateurs continuent à entrer des données dans le site, ces données doivent être indexées en permanence. Il n'est pas nécessaire que ce soit en temps réel, mais idéalement, les nouvelles données devraient apparaître dans l'index avec un retard de 15 à 30 minutes maximum.

Answer 1

Je suis heureux de voir que quelqu'un a parlé de Lucene, car je n'en ai aucune idée.

Sphinx, par contre, je le connais assez bien, alors voyons si je peux vous aider.

• Le classement par pertinence des résultats est la valeur par défaut. Vous pouvez définir votre propre classement si vous le souhaitez, et donner à des champs spécifiques une pondération plus élevée.
• La vitesse d'indexation est très rapide, car elle communique directement avec la base de données. Toute lenteur proviendra de requêtes SQL complexes, de clés étrangères non indexées et d'autres problèmes de ce type. Je n'ai jamais remarqué de lenteur dans la recherche non plus.
• Je suis un spécialiste de Rails, donc je n'ai aucune idée de la facilité d'implémentation avec Django. Il existe cependant une API Python fournie avec les sources de Sphinx.
• Le démon du service de recherche (searchd) utilise très peu de mémoire et vous pouvez fixer des limites à l'utilisation de la mémoire. combien de mémoire que le processus d'indexation utilise aussi.
• L'extensibilité est le domaine où mes connaissances sont plus sommaires - mais il est assez facile de copier les fichiers d'index sur plusieurs machines et d'exécuter plusieurs démons searchd. L'impression générale que j'ai eue des autres est qu'il est plutôt bon sous une charge élevée, donc le mettre à l'échelle sur plusieurs machines n'est pas quelque chose qui doit être traité.
• Il n'y a pas de support pour le "did-you-mean", etc - bien que cela puisse être fait avec d'autres outils assez facilement. Sphinx permet d'étayer les mots à l'aide de dictionnaires. Ainsi, "driving" et "drive" (par exemple) seront considérés comme identiques dans les recherches.
• Sphinx ne permet pas les mises à jour partielles d'index pour les données de champ. L'approche commune à ce sujet est de maintenir un index delta avec tous les changements récents, et de le réindexer après chaque changement (et ces nouveaux résultats apparaissent en une seconde ou deux). En raison de la faible quantité de données, cela peut prendre quelques secondes. Vous devrez néanmoins réindexer l'ensemble de données principal régulièrement (la fréquence dépend de la volatilité de vos données : tous les jours, toutes les heures). Grâce à la rapidité de l'indexation, tout cela reste cependant assez simple.

Je ne sais pas si cela s'applique à votre situation, mais Evan Weaver a comparé quelques-unes des options de recherche courantes dans Rails. (Sphinx, Ferret (un portage de Lucene pour Ruby) et Solr), en effectuant quelques tests de référence. Cela pourrait être utile, je suppose.

Je n'ai pas exploré les profondeurs de la recherche en texte intégral de MySQL, mais je sais qu'elle ne rivalise ni en termes de vitesse ni en termes de fonctionnalités avec Sphinx, Lucene ou Solr.

Answer 2

Je ne connais pas Sphinx, mais pour ce qui est de Lucene par rapport à une recherche plein texte dans une base de données, je pense que les performances de Lucene sont inégalées. Vous devriez être capable de faire presque tout en moins de 10 ms, quel que soit le nombre d'enregistrements à rechercher, à condition que vous ayez correctement configuré votre index Lucene.

Mais voici le plus gros obstacle : personnellement, je pense que l'intégration de Lucene dans votre projet n'est pas facile . Bien sûr, il n'est pas trop difficile de le configurer pour pouvoir effectuer des recherches de base, mais si vous voulez en tirer le meilleur parti, avec des performances optimales, il vous faut absolument un bon livre sur Lucene.

En ce qui concerne les exigences en matière de CPU et de RAM, l'exécution d'une recherche dans Lucene ne sollicite pas trop votre CPU, mais l'indexation de vos données l'est, bien que vous ne le fassiez pas trop souvent (peut-être une ou deux fois par jour), donc ce n'est pas un gros problème.

Il ne répond pas à toutes vos questions mais, en résumé, si vous avez beaucoup de données à rechercher et que vous voulez de bonnes performances, je pense que Lucene est définitivement la solution. Si vous n'avez pas beaucoup de données à rechercher, vous pouvez tout aussi bien opter pour une recherche en texte intégral dans une base de données. La mise en place d'une recherche en texte intégral MySQL est définitivement plus facile à mon avis.

Answer 3

Je suis surpris qu'il n'y ait pas plus d'informations publiées sur Solr. Solr est assez similaire à Sphinx mais possède des fonctionnalités plus avancées (AFAIK car je n'ai pas utilisé Sphinx - j'ai seulement lu à son sujet).

La réponse au lien ci-dessous détaille quelques éléments de Sphinx qui s'appliquent également à Solr. Comparaison des moteurs de recherche plein texte - Lucene, Sphinx, Postgresql, MySQL ?

Solr fournit également les fonctionnalités supplémentaires suivantes :

1. Prise en charge de la réplication
2. Cœurs multiples (considérez-les comme des bases de données distinctes avec leur propre configuration et leurs propres index).
3. Recherches booléennes
4. Mise en évidence des mots-clés (assez facile à faire dans le code de l'application si vous avez de l'expérience en matière d'expressions rationnelles ; cependant, pourquoi ne pas laisser un outil spécialisé faire un meilleur travail pour vous ?)
5. Mise à jour de l'index via un fichier XML ou délimité
6. Communiquer avec le serveur de recherche via HTTP (il peut même renvoyer du Json, natif de PHP/Ruby/Python)
7. Indexation des documents PDF et Word
8. Champs dynamiques
9. Facettes
10. Champs d'agrégats
11. Mots d'arrêt, synonymes, etc.
12. Plus comme cela...
13. Indexer directement à partir de la base de données avec des requêtes personnalisées
14. Suggestion automatique
15. Réchauffement automatique du cache
16. Indexation rapide (comparée aux temps d'indexation de la recherche plein texte MySQL) -- Lucene utilise un format d'index binaire inversé.
17. Boosting (règles personnalisées pour augmenter la pertinence d'un mot clé ou d'une expression particulière, etc.)
18. Recherches par champ (si un utilisateur connaît le champ qu'il souhaite rechercher, il peut réduire sa recherche en tapant le champ, puis la valeur, et SEUL ce champ est recherché plutôt que tout le reste - une bien meilleure expérience utilisateur).

BTW, il y a des tonnes d'autres fonctionnalités ; cependant, j'ai listé seulement les fonctionnalités que j'ai effectivement utilisées en production. Par ailleurs, MySQL supporte d'emblée les fonctionnalités 1, 3 et 11 (limitées) de la liste ci-dessus. Pour les fonctionnalités que vous recherchez, une base de données relationnelle ne fera pas l'affaire. Je les éliminerais directement.

De plus, un autre avantage est que Solr (et Lucene en fait) est une base de données de documents (par exemple, NoSQL), de sorte que de nombreux avantages de toute autre base de données de documents peuvent être réalisés avec Solr. En d'autres termes, vous pouvez l'utiliser pour autre chose que la recherche (c'est-à-dire la performance). Soyez créatif avec lui :)

Answer 4

J'étudie actuellement la recherche plein texte PostgreSQL, qui présente toutes les caractéristiques d'un moteur de recherche moderne, une très bonne prise en charge des caractères étendus et du multilinguisme, ainsi qu'une intégration étroite avec les champs de texte de la base de données.

Mais il ne dispose pas d'opérateurs de recherche conviviaux comme + ou AND (utilise & | !) et je ne suis pas emballé par la façon dont il fonctionne sur son site de documentation. Bien qu'il mette en gras les termes correspondants dans les extraits de résultats, l'algorithme par défaut pour déterminer les termes correspondants n'est pas génial. De plus, si vous voulez indexer rtf, PDF, MS Office, vous devez trouver et intégrer un convertisseur de format de fichier.

En revanche, elle est bien meilleure que la recherche de texte MySQL, qui n'indexe même pas les mots de trois lettres ou moins. C'est la recherche par défaut de MediaWiki, et je pense vraiment que ce n'est pas bon pour les utilisateurs finaux : http://www.searchtools.com/analysis/mediawiki-search/

Dans tous les cas que j'ai vus, Lucene/Solr et Sphinx sont vraiment excellents. . Il s'agit d'un code solide qui a évolué grâce à des améliorations significatives de la convivialité. Les outils sont donc tous là pour effectuer des recherches qui satisfont presque tout le monde.

SHAILI - SOLR inclut la bibliothèque de code de recherche Lucene et possède les composants pour être un bon moteur de recherche autonome.

Answer 5

Juste mes deux cents à cette très vieille question. Je vous recommande vivement de jeter un coup d'oeil à ElasticSearch .

Elasticsearch est un serveur de recherche basé sur Lucene. Il fournit un moteur de recherche plein texte distribué et multitenant avec une interface web RESTful et des documents JSON sans schéma. Elasticsearch est développé en Java et est publié en open source selon les termes de la licence Apache.

Les avantages par rapport aux autres moteurs de recherche de texte intégral sont les suivants :

• Interface RESTful
• Une meilleure évolutivité
• Grande communauté
• Construit par Lucene développeurs
• Une documentation complète
• Il existe de nombreux bibliothèques open source disponibles (y compris Django)

Nous utilisons ce moteur de recherche dans le cadre de notre projet et nous en sommes très satisfaits.