Quelle est la meilleure option pour rechercher dans Ruby on Rails? [fermé]

Question

Il existe plusieurs options de plug-in permettant de créer un moteur de recherche dans votre application Ruby on Rails. Lequel est le meilleur?

• Penser le sphinx
• UltraSphinx
• Sphincter
• acts_as_sphinx
• acts_as_ferret
• Furet
• actes_as_xapian
• acts_as_solr
• Hyper Estraier

Answer 1

Penser Sphinx a une syntaxe plus concise pour définir quels champs et quels modèles sont indexés.

UltraSphinx et Thinking Sphinx (récemment) ont une fonctionnalité ultra-cool qui prend en compte la proximité géographique des objets.

UltraSphinx rencontre des problèmes gênants dans le chargement des modèles (il ne charge pas toute la pile de Rails, vous pouvez donc obtenir des erreurs étranges et difficiles à diagnostiquer, qui sont gérées en ajoutant des instructions require explicites). / p>

Nous utilisons Thinking Sphinx pour les nouveaux projets et UltraSphinx pour les projets utilisant un contenu géographique.

Answer 2

Cette question a été posée précédemment ici avec des réponses plus détaillées.

Answer 3

Solr , un moteur de recherche utilisant le langage Java d'origine, est l'un des choix utilisés par l'un de mes amis. à base de Lucene. Pour l'utiliser avec Rails, il existe bien sûr un plugin Act_sas, act_as_solr .

Il a récemment présenté le combo à l'adresse Montreal on Rails et donne un bon aperçu complet de comment utiliser actes_as_solr sur son blog .

Il supporte apparemment très bien les accents français aussi.

Answer 4

Je suis dans ce processus en ce moment, alors bien que je n’ai pas d’expérience, j’ai passé de nombreuses heures à rechercher toutes les options. Voici ce que j'ai appris jusqu'à présent:

• * Sphinx - bonne réputation de rapidité et de fonctionnalité, mais Sphinx a besoin de clés entières et mon modèle utilise un GUID; ThinkingSphinx a récemment annoncé son soutien à GeoSpatial
• Acts_As_Solr - recommandé par un ami ayant un site à volume élevé; les créateurs originaux ont cessé de travailler dessus et la documentation est difficile à trouver; nécessite un servlet Java
• Acts_As_Ferret - semble facile à utiliser, mais beaucoup de détracteurs disent que c'est instable
• Deux autres informations limitées sont Acts_As_Indexed et Acts_As_Searchable

Je tente de documenter les avantages et les inconvénients de chacun d’entre eux. Si quelqu'un est intéressé à le voir et / ou à m'aider à le corriger, contactez-moi. Je la posterai quelque part une fois que je saurai qu'elle est exacte.

Je vous conseillerais d'essayer UltraSphinx ou Thinking Sphinx si vous disposez de clés primaires normales. Je vais essayer Acts_As_Xapian en se basant sur la bonne documentation, le jeu de fonctionnalités et l’activité du projet.

Answer 5

Je n'ai utilisé le combo Ferret / acts_as_ferret (décision héritée) que dans un projet client. Je recommande fortement de commencer par examiner les autres options.

aaf est très fragile et peut bloquer brutalement votre application Rails si vous vous trompez dans la configuration ou si, pour une raison quelconque, vous rencontrez un bug dans aaf.

Dans un tel cas, au lieu de laisser simplement la fonctionnalité de recherche disparaître, toute action du contrôleur touchant un modèle indexé échouera complètement et lèvera une exception. Quel est baaad, hmkay?

Answer 6

J'utilise le plugin act_as_xapian . J'ai suivi ce tutoriel:

http: / /locomotivation.com/2008/07/23/simple-ruby-on-rails-full-text-search-using-xapian

Fonctionne très bien.

Answer 7

J'utilise Act_as_ferret. Il est facile à configurer et généralement rapide. La fonctionnalité intégrée de recherche d’enregistrement actif est très utile: vous pouvez appliquer n’importe quelles conditions ou joindre d’autres modèles une fois que votre recherche a trouvé les enregistrements correspondants.

Contrairement à sphinx, vous n'avez pas besoin de réindexer TOUS vos enregistrements lorsque vous ajoutez de nouvelles données. Il y a des hooks after_save et after_update qui vont insérer votre nouvel enregistrement dans la base de données ferret. C’était l’un des grands arguments de vente pour moi.

Lorsque vous devez indexer vos données en masse, le furet est nettement plus lent que l'acte_as_sphinx (facteur 3). J'ai fini par écrire ma propre méthode pour réindexer les modèles, qui fonctionne aussi vite que sphinx. Elle précharge en principe toutes les données de la base de données au lieu d'aller enregistrement par enregistrement pour créer le nouvel index.

La documentation de furet est bonne pour les bases, mais elle est un peu clairsemée lorsque vous effectuez des recherches plus complexes, que vous effectuez un tri et que vous utilisez un serveur dRb pour héberger un index distant. Cela dit, le produit est beaucoup plus mature que le_actions_s_sphinx, bien que mon expérience avec le sphinx soit limitée.

Answer 8

Si vous utilisez un service d'hébergement partagé comme moi (Bluehost), vos options peuvent être limitées à celles proposées par le fournisseur. Dans mon cas, je ne trouvais pas de moyen fiable et efficace pour démarrer et faire fonctionner un serveur séparé, tel que Lucene ou Solr.

Par conséquent, je suis allé avec Xapian et cela a bien fonctionné pour moi. J'ai étudié 2 plugins pour les rails que j'ai recherchés: act_as_xapian et xapian_fu. Le premier vous permettra d’aller vite, mais cela ne semble plus être maintenu. Je viens de commencer à travailler avec xapian_fu.

Answer 9

Si vous êtes toujours intéressé, la dernière nouveauté à utiliser est elasticsearch . Pour cela, il existe des pierres précieuses telles que pneu ou elasticsearch-rails . Il est également basé sur Lucene comme Solr, basé sur Java. Solr est actuellement intégré à ce projet ...

Answer 10

J'ai utilisé Thinking Sphinx et cela semble assez bon, mais je n'ai pas eu le temps d'évaluer toutes les options.

Answer 11

Je recommande de penser au Sphinx. C’est l’option la plus rapide à mon avis.

Answer 12

J'ai utilisé Ferret et cela a bien fonctionné, mais je n'ai pas évalué les autres options.

Answer 13

Une option que je n'ai pas essayée est la Xapian basée sur C ++

.

Answer 14

Nous utilisons http://hyperestraier.sourceforge.net/ , qui a été hérité. Nous n'avons pas examiné d'autres moteurs, mais Hyperestraier fournit tous les crochets nécessaires. La mise en place de l'index de recherche est cependant compliquée. Probablement des options plus faciles disponibles.

Answer 15

Cela dépend de la base de données que vous utilisez. Je recommanderais d'utiliser Solr car il offre beaucoup d'options intéressantes pour la recherche floue et dispose d'un analyseur de requête génial. L'inconvénient est que vous devez exécuter un processus distinct pour cela. J'ai aussi utilisé Ferret, mais je l'ai trouvé moins stable en termes d'accès multi-thread à l'index. Je n'ai pas essayé Sphinx car cela ne fonctionne qu'avec MySQL et Postgres.

Answer 16

J'utilise une option différente qui a été incroyablement bien préparée. J'utilise jruby et je parle directement à Lucene.

J'ai déjà utilisé Actes_as_Solr et j'ai rencontré quelques problèmes. principalement, il effectue un appel synchrone pour chaque sauvegarde AR. Ce n’est pas si grave, mais dans ma situation, une sauvegarde entraînait parfois de nombreux appels synchrones à solr et prenait parfois plus de temps que ne le ferait un métis, et j’obtiendrais une exception de délai d’arrêt pour un métis (ou quelque chose du genre)

Answer 17

Penser Sphinx est une meilleure alternative à Ultrasphinx, qui semble abandonnée, mais en général, Xapian possède un moteur plus puissant que Sphinx et est plus facile à mettre en œuvre. La recherche en temps réel.

Answer 18

Je recommande act_as_ferret. Mais le plus difficile est de le rendre opérationnel sur votre serveur, mais vous ne rencontrerez plus aucun problème, car le serveur furet s'exécutera en tant que processus d'arrière-plan distinct pour mettre à jour votre index à chaque nouvelle mise à jour. En outre, cela fonctionne très bien en métis avec Apache pour nous.

Answer 19

J'ai également recherché la solution idéale. Au début, je suis allé avec Thinking Sphinx, qui a bien fonctionné. Mais comme je compte héberger ma webapp sur Heroku , la seule option consiste à utiliser Solr . Le plus gros inconvénient, cependant, est que le développement du principal joyau acts_as_solr semble s'être arrêté après mai 2008. Donc, c'est trop vieux à mon goût. Je viens de trouver Sunspot comme alternative avancée et avec les dernières mises à jour, c'est donc celle que je vais suivre. considérer.

Heroku propose une autre option: un serveur d’index hébergé basé sur Solr, nommé Websolr . Le joyau requis websolr-actes_as_solr est aussi heureusement très à jour.