Solr与ElasticSearch的比较

Question

这些技术的核心架构差异是什么？

另外，每种技术通常适用于哪些使用案例？

- Ben ODay

---

你可能想要看一下这个链接：https://dev59.com/fXE95IYBdhLWcg3wi-Uc - Bob Yoplait

这篇文章我认为还不错，链接如下：http://www.datanami.com/2015/01/22/solr-elasticsearch-question/。 - Eric

另一个2015年的比较：https://www.quora.com/What-are-the-main-differences-between-ElasticSearch-Apache-Solr-and-SolrCloud - rleir

请查看http://solr-vs-elasticsearch.com/。 - Philip Bergström

截至2021年，Elasticsearch是专有软件。Apache Solr仍然是免费软件。 - Flux

Answer 1

更新

现在问题范围已经得到纠正，我可能也会在这方面加些内容：

有很多关于Apache Solr和ElasticSearch的比较可供参考，因此我将引用我自己发现最有用的资料，即涵盖最重要方面的资料：

• Bob Yoplait已经链接了kimchy的回答ElasticSearch，Sphinx，Lucene，Solr，Xapian。哪一个适合哪种用途？，他总结了他为什么要创建ElasticSearch的原因，他认为与Solr相比，ElasticSearch提供了更优秀的分布式模型和易用性。

• Ryan Sonnek的Realtime Search：Solr vs Elasticsearch提供了深入的分析/比较，并解释了为什么他从Solr转到ElasticSeach，尽管他已经是一个快乐的Solr用户 - 他总结如下：

  Solr可能是构建标准搜索应用程序的选择武器，但Elasticsearch通过为创建现代实时搜索应用程序提供架构将其提升到了一个新的水平。 Percolation是一个令人兴奋和创新的功能，它单独地让Solr无法匹敌。 Elasticsearch可扩展，速度快，易于集成。再见，Solr，我很高兴认识你。[强调我]

• 维基百科上关于ElasticSearch的文章引用了一篇comparison来自德国著名的iX杂志，列出了优缺点，这几乎概括了上面已经说过的：

  优点：

  • ElasticSearch是分布式的。不需要单独的项目。副本也是近实时的，称为“Push复制”。
  • Elasticsearch完全支持Apache Lucene的近实时搜索。
  • 处理多租户不是特殊配置，在Solr中需要更高级的设置。
  • ElasticSearch引入了网关的概念，使完全备份更容易。

  缺点：

  • 只有一个主要开发人员 [根据当前elasticsearch GitHub organization，除了一开始就有相当活跃的提交者基础外，不再适用]
  • 没有自动预热功能 [根据新的Index Warmup API不再适用]

---

初始回答

它们是完全不同的技术，解决完全不同的用例，因此无法以任何有意义的方式进行比较：

• Apache Solr - Apache Solr在易于使用、快速的搜索服务器中提供了Lucene的功能，并具有分面、可扩展性等其他功能。

• Amazon ElastiCache - Amazon ElastiCache是一个Web服务，可轻松部署、操作和扩展云中的内存缓存。

  • 请注意，Amazon ElastiCache符合Memcached协议，这是一种广泛采用的内存对象缓存系统，因此您今天与现有Memcached环境一起使用的代码、应用程序和流行工具将与该服务无缝配合使用（有关详细信息，请参见Memcached）。

[重点标记为我的]

也许这与以下两个相关技术之一有所混淆：

• ElasticSearch - 它是一个基于Apache Lucene构建的开源（Apache 2），分布式，RESTful搜索引擎。

• Amazon CloudSearch - Amazon CloudSearch是云中的全托管搜索服务，允许客户轻松地将快速且高度可伸缩的搜索功能集成到其应用程序中。

Solr和ElasticSearch在第一眼看起来非常相似，并且两者都使用相同的后端搜索引擎，即Apache Lucene。

虽然Solr更加老练、多才多艺和成熟，因此被广泛使用，但ElasticSearch是专门为解决现代云环境中的可扩展性要求而开发的，这些要求很难通过Solr来解决。

因此，将 ElasticSearch 与最近推出的 Amazon CloudSearch 进行比较可能是最有用的（请参阅介绍性文章 在一个小时内以每月不到100美元的价格开始搜索），因为两者原则上都声称涵盖相同的用例。

- Steffen Opel

---

现在有了一个支持 elasticsearch 的公司，那么主要的开发者劣势应该已经消除了。 - javanna

现在ElasticSearch好像已经解决了autowarming的问题。请查看https://github.com/elasticsearch/elasticsearch/issues/1913 - unludo

在iX杂志上列出的ElasticSearch的所有优点现在都是错误的。1）SolrCloud不再是一个独立的项目。事实上，Solr和Lucene现在是同一个项目的一部分。2）Solr支持NRT。3）Solr可以处理单个集群中的多个集合。4）Solr还添加了复制功能，使备份更加容易。 - MattMcKnight

不要忘记 ElasticSearch 提供的聚合功能，适用于需要 OLAP 类似功能的用户。Solr Cloud 仅提供有限的 faceting。如果您需要对聚合数据进行警报，则可以使用 ES percolation。 - Mark Giaconia

所以，现在 Elastic Search 只有优点，没有缺点了吗？或者您没有提到任何值得一提的缺点吗？ - forsberg

Answer 2

我注意到以上一些答案现在有点过时了。从我的角度来看，我每天都与Solr（云和非云）和ElasticSearch一起工作，以下是一些有趣的区别：

• 社区：Solr有一个更大、更成熟的用户、开发和贡献者社区。ES有一个较小但活跃的用户社区和不断增长的贡献者社区
• 成熟度：Solr更加成熟，但ES迅速增长，我认为它很稳定
• 性能：难以判断。我们没有进行直接的性能基准测试。LinkedIn的一个人曾经比较过Solr vs. ES vs. Sensei，但最初的结果应该被忽略，因为他们对Solr和ES都使用了非专家设置。
• 设计：人们喜欢Solr。Java API有些冗长，但人们喜欢它的组合方式。Solr代码很不美观。此外，ES具有分片、实时复制、文档和路由等内置功能。虽然Solr也有一些类似的功能，但感觉有点像事后想法。
• 支持：有公司为Solr和ElasticSearch提供技术和咨询支持。我认为唯一同时提供支持的公司是Sematext（声明：我是Sematext的创始人）
• 可扩展性：两者都可以扩展到非常大的集群。ES比Solr 4.0之前的版本更容易扩展，但通过Solr 4.0就不再是这种情况了。

要了解更全面的Solr vs. ElasticSearch主题，请查看https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/。这是来自Sematext的系列文章中的第一篇，直接、中立地对Solr和ElasticSearch进行比较。声明：我在Sematext工作。

- Otis Gospodnetic

---

@Rubytastic - 你可能想在帖子下面发表评论，以引起作者的注意并获得一些内存消耗覆盖率。但是http://blog.sematext.com/2012/05/17/elasticsearch-cache-usage/这篇文章可能已经有你要找的内容了。 - Otis Gospodnetic

感谢您分享如此精彩的一手观点和博客文章。这篇文章已经发表了两年。如果您能分享更多沿途获得的见解，我认为社区将会受益匪浅。可以帮助人们决定Solr/ ElasticSearch哪个更适合他们的一些内容。 - user

我想补充一下，使用DataStax和Solr可以获得接近实时的复制。 - KingOfHypocrites

Answer 3

我看到很多人在回答ElasticSearch与Solr的问题时都从功能和特性方面进行了解答，但我并没有看到太多关于它们在性能方面的比较讨论（无论是在这里还是其他地方）。

因此，我决定进行自己的调查。我使用一个已经编码好的异构数据源微服务，该服务已经使用Solr进行术语搜索。我将Solr替换为ElasticSearch，然后在AWS上运行两个版本，并使用已编码的负载测试应用程序捕获性能指标以供后续分析。

以下是我的发现。在索引文档方面，ElasticSearch的吞吐量高出13％，但Solr的速度快了十倍。在查询文档方面，Solr的吞吐量是ElasticSearch的五倍，速度也比ElasticSearch快五倍。

- Glenn

---

有趣的是，我刚刚在评估Solr和Elasticsearch时发现，对于相同的100万个文档集合进行索引，Elasticsearch所需的时间是Solr的两倍。 - David Thomas

三年后，这仍然成立吗？10次似乎太多了，就像可以通过更好的定制来解决的那种问题？ - lucaswxp

我最近没有重新运行这些测试。一切都在 https://github.com/gengstrand/clojure-news-feed，所以请随意启动并自行测试。如果您这样做了，也许您可以在这里分享您的结果？ - Glenn

Answer 4

Apache Solr具有悠久的历史，我认为其一个优势就在于其生态系统。有许多Solr插件可用于不同类型和目的的数据。

搜索平台从底部到顶部分为以下层次：

• 数据
  • 目的：表示各种数据类型和来源
• 构建文档
  • 目的：构建索引的文档信息
• 索引和搜索
  • 目的：构建和查询文档索引
• 逻辑增强
  • 目的：为处理搜索查询和结果提供附加逻辑
• 搜索平台服务
  • 目的：添加额外的搜索引擎核心功能以提供服务平台。
• UI应用程序
  • 目的：终端用户搜索界面或应用程序

参考文章：企业搜索

- mingxue

Answer 5

我已经创建了一个表格，列出了elasticsearch、Solr和splunk之间的主要差异，你可以将其用作2016年的更新：

- Fardin Behboudi

---

数据模式行有点误导人... Elastic 有映射，它们本质上是一个模式（但默认情况下不需要）。Solr 发货时需要安装配置才能工作，有几个提供的示例配置可以立即选择，其中一个是无模式的，尽管在使用 Solr 时，仔细控制的模式可能更常见。 - Gus

Solr Streaming API 提供了 MapReduce 的功能。 - whomer

Mapreduce：http://lucene.apache.org/solr/6_0_0/solr-map-reduce/org/apache/solr/hadoop/SolrReducer.html - Ajax

Answer 6

我一直在为.Net应用程序工作的Solr和Elasticsearch中进行研究。我发现最大的区别是：

Elasticsearch：

• 更多的代码和较少的配置，尽管有API可以更改设置，但仍需要改变代码。
• 对于复杂类型，嵌套类型（在Solr中无法实现）。

Solr：

• 较少的代码和更多的配置，因此维护成本更低。
• 在查询期间对结果进行分组（在Elasticsearch中需要花费大量的工作来实现，没有直接的方式）。

- robert

Answer 7

虽然上述所有链接都有其价值，而且在过去的几年中对我都有很大帮助，但作为一个接触各种Lucene搜索引擎已有15年之久的语言学家，我必须说elastic-search在Python中的发展非常快速。话虽如此，其中一些代码对我来说感觉不太直观。因此，我从开源的角度联系了ELK堆栈的一个组件-Kibana，并发现我可以在Kibana中非常容易地生成elasticsearch的某些密文代码。此外，我还可以将Chrome Sense es查询导入到Kibana中。如果您使用Kibana来评估es，则会进一步加快您的评估。在其他平台上运行数小时的内容，在最差情况下（最大数据集）也能以JSON格式在elasticsearch（RESTful接口）和Sense的几分钟内运行；在最佳情况下只需几秒钟。虽然elasticsearch的文档超过700页，但它没有回答我所提出的问题，而这些问题在SOLR或其他Lucene文档中通常会得到解决，这显然需要更多时间进行分析。此外，您可能还想查看elastic-search中的聚合，这使Faceting提升到了新的水平。

更大的图景：如果您正在进行数据科学、文本分析或计算语言学，elasticsearch在信息检索领域有一些排名算法，似乎在这方面有所创新。如果您使用任何TF/IDF算法（文本频率/倒排文档频率），则elasticsearch将这个20世纪60年代的算法扩展到了一个新的水平，甚至使用BM25、最佳匹配25和其他相关性排名算法。因此，如果您对单词、短语或句子进行评分或排名，elasticsearch可以即时完成此评分，而无需像其他数据分析方法那样需要大量的计算时间-这是又一个节省时间的优点。通过es，将聚合中的桶操作与实时JSON数据相关度评分和排名相结合，您可能会找到一个获胜组合，具体取决于您的敏捷（用户故事）或架构（用例）方法。

注意：我看到上面有一个类似的聚合讨论，但没有涉及到聚合和相关性排名-如果有重叠，请见谅。 声明：我不为elastic工作，并且除非我做一些与elasticsearch的慈善工作（这也不是一个坏主意），否则在不久的将来无法从他们的优秀工作中获益，因为我们采用了不同的架构路径。

- MethodyM

Answer 8

如果您已经在使用SOLR，请继续使用。如果您正在开始使用，请选择Elasticsearch。

大部分主要问题已经在SOLR中得到解决，它已经相当成熟了。

- Behzad Qureshi

---

为什么您推荐新项目使用Elastic？ - forsberg

Elasticsearch是新的，因此它使用最新的技术/架构。 - Behzad Qureshi

我也可以创造出一些新的东西，但仅仅因为我使用了新技术或不同的架构，并不意味着它比市场上已有的更好。 - Jan Sommer

同意，但作为一名架构师，您肯定会选择比市场上已有的更好的方案。这是我的两分钱 :) - Behzad Qureshi

Answer 9

想象一下这种使用场景：

1. 大量的小型（10Mb-100Mb，1000-100000个文档）搜索索引。
2. 它们被许多应用程序（微服务）使用。
3. 每个应用程序可以使用多个索引。
4. 索引很小，但负载很大（每秒数百个搜索请求），而且请求非常复杂（包含多个聚合、条件等）。
5. 不允许停机。
6. 所有这些都已经运行多年，并且不断增长。

在这种情况下，每个索引拥有独立的ES实例是一个巨大的开销。

根据我的经验，这种用例对于Elasticsearch来说非常难以支持。

为什么？

首先。

主要问题是基本的后向兼容性忽略。

破坏性变更非常酷！ （注：想象一下SQL服务器，在升级时需要对所有SQL语句进行小的更改...无法想象。但对于ES来说，这是正常的）

下一个主要版本中将删除的弃用内容非常性感！ （注：你知道，Java中包含一些弃用内容，20多年了，但仍然在实际Java版本中使用...）

有时你甚至会遇到一些没有文档的东西（个人只遇到过一次，但是...）

所以。如果您想升级ES（因为您需要一些应用程序的新功能或想要获得错误修复），那么您就陷入了困境。特别是如果涉及主要版本升级。

客户端API将不再向后兼容。索引设置也不再向后兼容。 同时升级所有应用程序/服务与ES升级不现实。

但是你必须做到时时刻刻。没有其他方法。

现有索引会自动升级吗？-是的。但当您需要更改某些旧索引设置时，它不会为您提供帮助。

要生存下来，您需要不断地投入大量力量来...使您的应用程序/服务与ES未来版本保持前向兼容性。 或者您需要构建（并且无论如何都需要不断支持）某种中间件来提供向后兼容的客户端API。 （而且，您不能使用Transport Client（因为每次ES的次要版本升级都需要jar升级），这个事实并没有让您的生活变得更简单）

它看起来简单且便宜吗？不，不是。远非如此。 基于ES的复杂基础设施的持续维护在所有可能的方面都太昂贵了。

其次。

简单API？嗯...不是真的。 当您实际使用复杂的条件和聚合时...带有5个嵌套级别的JSON请求无论如何都不简单。

---

很遗憾，我没有SOLR的经验，不能对其进行评价。

但是，在这种情况下，Sphinxsearch要好得多，因为它具有完全向后兼容的SphinxQL。

注意： Sphinxsearch/Manticore确实很有趣。它不基于Lucene，因此与其非常不同。它内置了一些ES没有的独特功能，并且在小/中型索引下非常快。

- Gmugra

Answer 10

我使用Elasticsearch已经有三年了，而Solr只用了一个月。我觉得相比于Solr的安装，Elasticsearch集群的安装要容易得多。Elasticsearch有一大批帮助文档，并且这些文档都解释得非常好。在某个使用案例中，我遇到了直方图聚合（Histogram Aggregation）这个问题，在Elasticsearch中可以找到对应的功能，但是在Solr中并没有。

- Prakash Ghanshani