弹性搜索与太阳黑子特征的比较

时间:2012-02-06 12:44:51

标签: ruby-on-rails ruby-on-rails-3 ruby-on-rails-3.1 solr elasticsearch

找不到任何与太阳黑子(Solr)相关的问题与弹性搜索(Lucene) 两个搜索引擎上的专业人士和骗子会是什么?

我看到了其他VS问题,以便在2个宝石的比较中获得更好的内部,所以希望这可以更好地了解新手的两个引擎(像我一样)。我已经看过太阳黑子但是有一些问题。所以我搜索了

VS

3 个答案:

答案 0 :(得分:10)

我开始研究一个需要在Ruby中进行全文搜索的项目,所以很自然地我开始使用Solr + Sunspot,但我无法让它工作。只是让它们连接起来很痛苦,然后试图弄清楚文档是否正确索引,找出运行时类路径,这样我就可以添加额外的分析器/标记器类,编辑config.xml / schema.xml等等.Solr numDocs清楚说收到并索引了他们,但我无法得到任何查询结果。几天之后我就放弃了,这是一种配置地狱。

ElasticSearch + Tire轻松上手,让它在一小时内完成。

Lucene只是一个Java搜索库,因此Solr被开发成为一个完整的服务搜索应用程序,但Solr仍然拥有典型Java Web应用程序的所有陷阱:过于复杂的XML配置,架构密集,期望用于索引的XML文档,需要一个Java servlet容器(Jetty或Tomcat),这对我来说只是失败了。

ElasticSearch也基于Lucene,它有一个内置的servlet容器,所以只需像守护进程一样运行,使用非常简单的JSON + REST API,因此它非常适合测试,更适合Ruby。它是无模式的,它甚至没有编辑配置文件也适用于我。一切都很美妙。

我真正需要的是中文搜索和ElasticSearch已经将Luecene的SmartChineseAnalyzer打包为插件。如果您需要这种级别的自定义,不确定自定义分析器/标记器链是多么困难。 ElasticSearch和Tire的Docmentation都是一流的。

轮胎(ElasticSearch的Ruby库)

https://github.com/karmi/tire

您可以试用该演示,它将安装rails searchapp,下载ElasticSearch二进制文件并运行它,然后自动启动Webrick。

$ rails new searchapp -m https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb

在我的系统上,它抱怨没有Javascript引擎(Rails 3.2?默认情况下不再包含theubyracer gem),所以我不得不:

$ wget https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb
$ nano rails-application-template.rb

在文件中添加gem'therubyracer'(寻找宝石'轮胎'和宝石'will_paginate'),然后......

$ rails new searchapp -m rails-application-template.rb

为了开发我自己的应用程序,我只是将ElasticSearch tarball下载并使用-f开关在前台运行(因此我可以通过Ctrl-C轻松阻止它)

$ bin/elasticsearch -f

您可以安装eleasticsearch-head插件以获取Web管理界面

https://github.com/mobz/elasticsearch-head

我也发现了一些事情:如果你有一对多的关系模型,Tire将不会在搜索结果中为你解决它们,它只会返回一个扁平的集合。你的has_many和belongs_to关系只是集合中的对象id而不是完整的对象。

答案 1 :(得分:8)

我认为你应该搜索Solr和弹性搜索之间的比较。 事实上,太阳黑子基于Solr,Solr和弹性搜索都基于Lucene。它们是两个具有相似目标的不同项目,都建立在Lucene之上。

以下是两个比较:

ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?

http://www.findbestopensource.com/article-detail/solr-vs-elasticsearch

答案 2 :(得分:2)

这是有关以下主题的最完整的最新信息:http://solr-vs-elasticsearch.com/

  

截至2018年5月的我的建议

     

这里有一些简单的准则,如果功能疯狂的长网格   上面没有帮助。

     

如果满足以下任一条件,请选择Solr ...

     
      
  • 您的团队主要由Java程序员组成
  •   
  • 您已经在堆栈中使用ZooKeeper
  •   
  • 您已经在堆栈中使用Java
  •   
  • 您正在构建具有特定且细微相关性要求的搜索应用程序
  •   
  • 您正在构建电子商务,职位或产品搜索引擎
  •   
  • 搜索是您的产品和用户体验的核心部分,并且要使搜索成为核心优势,这是组织的要求
  •   
     

如果满足以下任何条件,请选择Elasticsearch ...

     
      
  • 您的团队主要由Ruby / PHP / Python /全栈程序员组成(并且您的应用程序没有特定且细微的相关性   要求)
  •   
  • 您生活和呼吸JSON
  •   
  • 您已经使用Kibana / ELK来管理日志
  •   
  • 您的应用程序分析量很大
  •   
     

如有疑问...

     

我从事过的每个认真的搜索应用程序都需要   深入定制搜索工作流程和相关性调整,   在撰写本文时,这根本不可能   无需重大黑客攻击的Elasticsearch。如有疑问,请去Solr。