找不到任何与太阳黑子 (Solr) 和 Elastic Search (Lucene) 相关的比较问题 两个搜索引擎的优缺点是什么？
我看到了其他 VS 问题，以便在比较 2 颗宝石时获得更好的内部信息，因此希望这可以让新手（比如我）更好地了解这两种引擎。我已经看过太阳黑子了，但有一些问题。所以我搜索了
对
【问题讨论】：
标签： ruby-on-rails ruby-on-rails-3 ruby-on-rails-3.1 solr elasticsearch
我开始从事一个需要在 Ruby 中进行全文搜索的项目，所以我自然而然地从 Solr + Sunspot 开始，但我无法让它工作。只是让它们连接起来很痛苦，然后试图弄清楚文档是否正确索引，找出运行时类路径，这样我就可以添加额外的分析器/标记器类，编辑 config.xml/schema.xml 等。 Solr numDocs 清楚说它收到并索引了它们，但我无法得到任何查询结果。几天后我就放弃了，这有点像配置地狱。
ElasticSearch + Tire 很容易启动并运行，我在一小时内就搞定了。
Lucene 只是一个 Java 搜索库，因此 Solr 被开发为一个全方位服务的搜索应用程序，但 Solr 仍然具有典型 Java webapp 的所有陷阱：过度复杂的 XML 配置、模式繁重、需要 XML 文档进行索引，需要一个 Java servlet 容器（Jetty 或 Tomcat），这对我来说成为太多故障点。
ElasticSearch 也是基于 Lucene，它有一个内置的 servlet 容器，所以就像一个守护进程一样运行，使用非常直接的 JSON + REST API，所以它非常适合测试并且更自然地适合 Ruby。它是无模式的，甚至无需编辑配置文件即可为我工作。一切都很顺利。
我真正需要的是中文搜索，而 ElasticSearch 已经将 Luecene 的 SmartChineseAnalyzer 打包为一个插件。如果您需要该级别的自定义，不确定自定义分析器/标记器链会有多困难。 ElasticSearch 和 Tire 的文档都是一流的。
轮胎（ElasticSearch 的 Ruby 库）
你可以试试这个演示，它会安装一个 rails searchapp，下载 ElasticSearch 二进制文件并运行它，然后自动启动 Webrick。
$ rails new searchapp -m https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb
在我的系统上，它抱怨没有 Javascript 引擎（Rails 3.2？默认情况下不再包含 thereubyracer gem），所以我不得不：
$ wget https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb
$ nano rails-application-template.rb
在文件中添加 gem 'therubyracer'（查找 gem 'tire' 和 gem 'will_paginate'），然后...
$ rails new searchapp -m rails-application-template.rb
为了开发我自己的应用程序，我只是下载了 ElasticSearch tarball 并使用 -f 开关在前台运行（所以我可以通过 Ctrl-C 轻松停止它）
$ bin/elasticsearch -f
你可以安装 elelasticsearch-head 插件来获得一个 web 管理界面
https://github.com/mobz/elasticsearch-head
我还发现：如果您有一对多的关系模型，Tire 不会在搜索结果中为您解析它们，它只会返回一个平面集合。您的 has_many 和 belongs_to 关系将只是集合中的对象 ID，而不是完整的对象。
【讨论】：
我认为您应该搜索 Solr 和弹性搜索之间的比较。 其实 sunspot 是基于 Solr 的，Solr 和 elastic search 都是基于 Lucene 的。它们是两个具有相似目标的不同项目，都建立在 Lucene 之上。
这里有两个比较：
ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?
http://www.findbestopensource.com/article-detail/solr-vs-elasticsearch
【讨论】：
这是关于该主题的最完整的最新帖子：http://solr-vs-elasticsearch.com/
我截至 2018 年 5 月的建议
这里有一些简单的指导方针，如果疯狂的长网格功能 以上没有帮助。
如果以下任何一项为真，请选择 Solr...
- 您的团队主要由 Java 程序员组成
- 您已经在堆栈中使用 ZooKeeper
- 您已经在堆栈中使用 Java
- 您正在构建一个搜索应用程序，该应用程序具有特定且细微的相关性要求
- 您正在构建电子商务、工作或产品搜索引擎
- 搜索是您的产品和用户体验的核心部分，组织要求搜索成为核心优势
如果以下任何一项为真，请选择 Elasticsearch...
- 您的团队主要由 Ruby/PHP/Python/全栈程序员组成（并且您的应用程序没有特定和细微的相关性 要求）
- JSON 让你生生不息
- 您已经使用 Kibana/ELK 来管理您的日志
- 您的应用程序需要大量分析
如有疑问...
我从事过的每一个严肃的搜索应用程序都需要 搜索工作流程的深度定制和相关性调整， 在撰写本文时，这在 没有重大黑客攻击的 Elasticsearch。如有疑问，请使用 Solr。
【讨论】：