在Ruby on Rails中搜索的最佳选择是什么？
有几个插件选项可用于在Ruby on Rails应用程序中构建搜索引擎。 哪个最好？
- 思考狮身人面像
- UltraSphinx
- 括约肌
- acts_as_sphinx
- acts_as_ferret
- 鼬
- acts_as_xapian
- acts_as_solr
- Hyper Estraier
思考Sphinx有更简洁的语法来定义哪些字段和哪些模型被索引。
UltraSphinx和Thinking Sphinx（最近）都具有超酷的function，可以考虑物体的地理位置。
UltraSphinx在加载模型方面存在令人烦恼的问题（它不会加载整个Rails堆栈，因此您可能会出现奇怪且难以诊断的错误，这些错误通过添加显式的require语句来处理）。
我们在新项目上使用Thinking Sphinx，在使用地理内容的项目上使用UltraSphinx。
这个问题之前已经在这里提出了更详细的答案。
我的一个朋友使用的一个可靠选项是Solr ，一个使用原始基于Java的Lucene的搜索引擎。 要将它与Rails一起使用，当然还有一个acts_as插件， acts_as_solr 。
他最近在Montreal on Rails上展示了这个组合，并对如何在他的博客上使用acts_as_solr给出了一个很好的全面概述。
它显然也很好地支持法国口音。
我现在正在经历这个过程，所以虽然我没有实际经验，但我花了很多时间研究所有选项。 这是我到目前为止所学到的：
- * Sphinx – 速度和function的良好声誉，但Sphinx需要整数键，我的模型使用GUID; ThinkingSphinx最近宣布支持GeoSpatial
- Acts_As_Solr – 由拥有高容量网站的朋友推荐; 原始创作者已停止工作，文档很难找到; 需要一个Java servlet
- Acts_As_Ferret – 看起来很容易使用，但很多批评者认为它不稳定
- 另外两个信息有限的是Acts_As_Indexed和Acts_As_Searchable
我有一个电子表格，试图记录所有这些的优点和缺点。 如果有人有兴趣看到它和/或帮我纠正它，请联系我。 一旦我知道它的准确性，我会把它贴在某处。
如果您有正常的主键，我的建议是尝试UltraSphinx或Thinking Sphinx。 我将根据良好的文档，function集以及项目的活跃程度来尝试Acts_As_Xapian。
我只在客户端项目中使用了Ferret / acts_as_ferret组合（遗留决策）。 我强烈建议先看看其他选项。
aaf是非常脆弱的，如果您在配置中出错或者由于某种原因您遇到了aaf中的错误，可能会使您的Rails应用程序戛然而止。
在这种情况下，触摸索引模型的任何控制器操作都将完全失败并引发exception，而不是简单地使搜索function崩溃。 这是baaad，hmkay？
我使用acts_as_xapian插件。 我按照本教程：
http://locomotivation.com/2008/07/23/simple-ruby-on-rails-full-text-search-using-xapian
效果很好。
我正在使用acts_as_ferret。 它配置简单，速度快。 内置的活动记录查找function非常有用：您可以在搜索找到匹配的记录后应用任何条件或加入其他模型。
与sphinx不同，您在添加新数据时不必重新索引所有记录。 有post_save和after_update挂钩会将你的新记录插入到ferret db中。 这对我来说是最大的卖点之一。
当你必须对数据进行质量索引时，雪貂肯定比acts_as_sphinx要慢（减少3倍）。 我最终编写了自己的方法来重新索引模型，其工作速度与sphinx一样快 – 它基本上预加载来自DB的所有数据，而不是按记录记录来创建新索引。
ferret文档对于基础知识是有用的，但是一旦你进入更复杂的搜索，排序并使用dRb服务器来托管远程索引，它就会有点稀疏。 话虽这么说，感觉比acts_as_sphinx更成熟，尽管我对sphinx的经验有限。
如果您使用像我这样的共享托管服务（Bluehost），您的选项可能仅限于提供商提供的内容。 就我而言，我找不到一个好的，可靠的方法来启动并保持单独的服务器运行，例如Lucene或Solr。
因此，我选择了Xapian，它一直很适合我。 我研究过有2个用于rails的插件：acts_as_xapian和xapian_fu。 第一个会让你快速前进，但它似乎不再维持。 我刚刚开始使用xapian_fu。
如果有人仍然感兴趣，现在使用的最新内容是elasticsearch 。 它有gem可供选择，如轮胎或弹力搜索导轨 。 它也基于Lucene，就像基于Java的Solr一样。 Solr现在实际上已与该项目集成……
我使用过Thinking Sphinx，看起来还不错，但我没有时间评估所有选项。
我推荐Thinking Sphinx。 在我看来，这是最快的选择。
我使用过Ferret，它的用途很好，但我没有评估其他选项。
我没有尝试的选项是基于C ++的Xapian
我们使用的是http://hyperestraier.sourceforge.net/ ，它是inheritance的。 没有看过其他引擎，但hyperestraier提供了所有必要的钩子。 但是设置搜索索引很复杂。 可能更容易的选择。
这取决于您使用的数据库。 我建议使用Solr，因为它为模糊搜索提供了很多不错的选项，并且有一个很棒的查询解析器。 缺点是你必须为它运行一个单独的过程。 我也使用过Ferret，但发现它在multithreading访问索引方面不太稳定。 我没有尝试过Sphinx，因为它只适用于MySQL和Postgres。
我正在使用一个非常好的解决方案。 我正在使用jruby并直接与lucene交谈。
我过去曾使用过acts_as_solr并遇到了一些问题。 主要是为每个AR保存进行同步调用。 这不是太糟糕，但在我的情况下，保存有时会导致许多同步调用solr，并且偶尔需要比mongrel允许更长的时间，并且我会得到一个mongrel超时exception（或类似的东西）
思考Sphinx是一个比Ultrasphinx更好的选择，它似乎已经被放弃了，但是，一般来说，Xapian比Sphinx具有更强大的引擎，并且更容易实现实时搜索。
我推荐acts_as_ferret。 但是，虽然困难的部分是在服务器中成功运行，但一旦完成，您几乎没有任何问题，因为每次有任何新的更新时，ferret服务器将作为单独的后台进程运行以更新索引。 此外，它与我们的apache一起使用apache。
我一直在寻找完美的解决方案。 起初我和Thinking Sphinx一起去了，它工作得很好。 但由于我打算在Heroku上托管我的webapp，唯一的选择是使用Solr 。 然而，最大的缺点是主要的acts_as_solr gem的开发似乎已经在2008年5月之后停止了。所以这对我来说太老了。 我刚刚发现太阳黑子作为一种先进的替代方案，并且最近有更新，所以这是我要考虑的问题。
Heroku提供的另一个选择是使用基于Solr的托管索引服务器，名为Websolr 。 所需的gem websolr-acts_as_solr也很幸运，是最新的。