我们为什么在这里?我存在的目的是什么?我应该锻炼还是休息以节省精力?早起上班还是开始工作到很晚?我吃薯条要加蕃茄酱还是蛋黄酱?

这些都是古老的问题，可能有也可能没有答案。其中一些非常难，或者非常主观。但我还是要花点时间来回答其中一个问题:我应该用Elasticsearch还是Solr?

这是一个场景。您的组织希望实现您的第一个搜索引擎，切换到另一个搜索引擎-呼叫所有谷歌搜索设备(GSA)用户寻找替代品!——或者尝试通过开源来节省资金。您，作为一个熟练和有能力的开发人员，被要求解决一个难题。您的问题有许多业务需求，但其核心是一个“大数据和搜索”问题。

您需要从多个数据源提取大量内容，并从这些数据中获得洞察力，以帮助您的公司增长并实现今年的目标。

管中窥豹

这里有很多利害关系。你不会错过的，你只有一次机会。您需要合适的搜索引擎，您考虑的是开源，您有两个流行的选择:Elasticsearch或Solr，根据db - engine的说法，这两个搜索引擎在开源和商业搜索引擎中稳居前两名。

你会选择哪个开源搜索引擎?

这不是掷硬币或简单的选择。这两个搜索引擎都很棒，但没有一个“正确”的选择。这完全取决于你的需求。

因此，第一步是理解必须构建的应用程序。然后，下一步是看看每个搜索引擎都能提供什么。顺便说一句，如果你还处在开源和商业解决方案的交叉点，请阅读我们的免费电子书，深入了解在选择搜索引擎时要考虑的10个关键标准。

功能纲要

几年前，我们写了一个关于Elasticsearch与Solr的高级概览博客，其中讨论了总体趋势和非技术见解。现在，随着Elasticsearch和已发展成为开源搜索引擎市场的主导玩家，让我们重新审视一下它们，看看它将带给我们什么。

年龄和成熟

在这种情况下，我们可以说Solr有更长的历史，因为它是由CNET Networks的Yonik Seely在2004年创建的，然后在2006年将其贡献给Apache。2007年，它最终成为一个顶级项目。另一方面，我们有Elasticsearch，它是在2010年正式创建的，虽然它实际上是在2001年由其创始人Shay Bannon以Compass的名义创建的。从那时起，Kibana、Logstash和Beats的创建者加入了Elasticsearch，创建了Elastic Stack产品家族，成为搜索和日志分析领域的强大玩家。也就是说，Solr的优势在于能够更早地出现在市场中。

社区和开源

两者都有非常活跃的社区。如果你查看Github，你会发现它们是非常流行的开源项目，发布了很多版本。

一个非常重要的细节是，虽然两者都是在Apache许可下发布的，而且都是开源的，但它们的工作方式略有不同。Solr确实是开源的——任何人都可以提供帮助和贡献。有了Elasticsearch，虽然人们仍然可以提供他们的贡献，但只有Elastic的员工(创建Elasticsearch和Elastic Stack的公司)可以接受这些贡献。

这是好事还是坏事?这取决于你怎么看它。这意味着，如果您需要一种特性并将其贡献给社区，并且具有足够的质量，那么Solr可以接受它。在Elasticsearch中，由Elastic决定某个贡献是否被接受。所以Solr上可能有更多的特性选项。另一方面，对于Elasticsearch的贡献，通过更多级别的质量检查，可以提供更高的一致性和质量。

文档

Elasticsearch和Solr都有非常完善的参考指南。Elasticsearch运行在Github之上，Solr使用Atlassian Confluence。你可以通过下面的链接找到它们。

• Elasticsearch Reference Guide
• Solr Reference Guide 

核心技术

让我们更专业一点。Elasticsearch和Solr是两种不同的搜索引擎。但在底层，它们都使用Lucene，这意味着它们都构建在“巨人的肩膀上”。

对于那些想知道为什么我认为Lucene是一个“巨人”的人，它实际上是许多搜索引擎背后的信息检索软件库。它非常快，稳定，可能没有比这更好的了。Lucene是由Hadoop的创始人之一Doug Cutting在1999年创建的。所以，Lucene是用于搜索引擎核心的完美选择。

Java API和REST

Elasticsearch有一个更“Web 2.0”的REST API，但是Solr有一个更好的Java API，使用SolrJ——或者使用Microsoft技术的SolrNet。Elasticsearch有Nest和Elasticsearch.Net。Solr的REST API可能感觉不太灵活，但它对于您所需要的:索引和查询非常有效。Elasticsearch使用的是JSON，所以如果您使用JSON，那么它是一个很好的选择。Solr也支持JSON，但它是在后期添加的，最初是为XML设计的。

内容处理

因为它们都公开API，所以很容易从自定义应用程序或现有的可配置应用程序索引内容。例如，我们的Aspire内容处理框架能够连接到多个数据源并post到Elasticsearch或Solr。

Solr还有一个特性，可以使用Apache Tika从二进制文件中提取文本。因此，您可以通过ExtractRequestHandler上传PDF文件，Solr将知道如何处理它。

另一方面，Elasticsearch与Logstash合作得很好，它可以处理来自任何来源的数据并为其建立索引。

可伸缩性

伸缩性是一个关键的考虑因素。在这种情况下，当Solr仍然被限制为主从关系时，Elasticsearch将赢得比赛。然而，SolrCloud最近加入了这个游戏。在Zookeeper的帮助下，现在可以以更简单、更快的方式扩展Solr集群—这是对旧版本的Solr的增强，它具有主从功能。它仍然需要大量的改进，但是从Solr中可摄取和搜索的数据集的大小来看，它的前景是光明的。

供应商支持

有几家公司已经到了必须决定哪种产品最适合自己的地步。例如，Cloudera选择Solr作为他们的搜索引擎，将其集成到开源的CDH(包括Hadoop的Cloudera发行版)中。另一方面，也有其他厂商选择Elasticsearch作为其解决方案的搜索引擎。我们在搜索技术帮助咨询，部署和支持这两个搜索引擎。

远景与生态系统

Solr更倾向于文本搜索。Elasticsearch迅速开拓了自己的小众市场，通过创建Elastic堆栈(以前称为ELK堆栈)来实现日志分析，Elastic Stack代表Elasticsearch、Logstash、Kibana和Beats。双方都有清晰的愿景，正在朝着各自的方向大步前进。

值得重申的一点是，这两个搜索引擎如何被用作许多领先的搜索和大数据平台的基础。例如，Elasticsearch是微软Azure搜索的一部分，而Solr已经集成到Cloudera搜索中。

性能

说到性能，根据我从许多开发人员那里听到的经验，我们可以说这两个引擎的性能都很好。因此，对于大多数用例，无论是内部的还是外部的搜索应用程序，如果开发人员正确地设计和配置它们，性能将不是什么大问题。

网络管理

Solr捆绑了web管理，而Elasticsearch有多个用于安全性、警报和监视的高级插件。这个列表展示了Elastic的整个产品系列。

可视化

在Elasticsearch和Solr中有许多可视化数据的方法——您可以构建自定义可视化仪表板，或者使用搜索引擎的标准可视化特性，可能需要做一些调整。但有一个区别值得一提。

Solr主要关注文本搜索。它在这方面做得很好，成为了搜索应用程序的标准。但是Elasticsearch已经向不同的方向发展，它已经超越了搜索，使用Elastic堆栈处理日志分析和可视化。下面是一些你可以用Kibana 5实现的可视化。

这并不意味着一个比另一个好。它只是表明，每个搜索引擎在不同的用例和需求中都有自己的优势，而您的选择将在很大程度上取决于您的组织想要实现什么。

长话短说，Elasticsearch和Solr都是优秀的开源选择，它们将帮助您从数据中获得更多信息。这完全取决于您的需求、预算、时间安排和项目的复杂性。

原文：https://www.searchtechnologies.com/blog/solr-vs-elasticsearch-top-open-source-search

本文：http://jiagoushi.pro/node/1152

讨论：请加入知识星球【首席架构师圈】或者微信【jiagoushi_pro】