Solr vs. ElasticSearch

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

此外，哪些用例通常更适合每个用例？

272058 次浏览
小开
最佳答案

更新

既然问题范围已经纠正，我也可以在这方面补充一些东西：

apachesolr和弹性搜索之间有很多比较，所以我将参考那些我发现自己最有用的比较，即涵盖最重要的方面：

  • 鲍勃·约普莱特已经将kimchy的答案链接到ElasticSearch，Sphinx，Lucene，Solr，Xapian。哪些适合哪种用法？，这总结了他继续创建ElasticSearch的原因，在他看来，与Solr相比，ElasticSearch提供了一个优越的分布式模型和易用性。

  • Ryan Sonnek的实时搜索：Solr vs Elasticsearch提供了一个有见地的分析/比较，并解释了为什么他从Solr切换到ElasticSeach，尽管他已经是一个快乐的Solr用户-他总结如下：

    Solr可能是构建标准搜索时的首选武器 应用程序，但是Elasticsearch将它带到了一个新的水平 用于创建现代实时搜索应用程序的架构。 渗流是一个令人兴奋和创新的特征，单枪匹马 Elasticsearch是可扩展的，快速的 和一个与融合的梦想。再见，索尔，很高兴认识你。[强调我的]

  • 维基百科关于ElasticSearch的文章引用了来自著名的德国iX杂志的比较，列出了优点和缺点，几乎总结了上面已经说过的内容：

    优势：

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

    缺点：

初步答复

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

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

  • 亚马逊ElastiCache-Amazon ElastiCache是一种Web服务，可让您轻松在云中部署、操作和扩展内存缓存。

    • 请注意Amazon ElastiCache与Memcach（一种广泛采用的内存对象缓存系统）协议兼容，因此您今天与现有Memcache环境一起使用的代码、应用程序和流行工具将与该服务无缝协作（详见Memcache）。

[强调我的]

也许这与以下两种相关技术相混淆：

乍一看，Solr和弹性搜索产品听起来非常相似，并且都使用相同的后端搜索引擎，即ApacheLucene。

虽然Solr较旧，功能广泛且成熟，因此被广泛使用，但弹性搜索是专门为解决Solr在现代云环境中具有可扩展性要求的缺点而开发的，这些缺点很难用Solr来解决。

因此，将弹性搜索与最近推出的亚马逊云搜索进行比较可能是最有用的（请参阅介绍性文章开始搜索一小时不到100美元/月），因为两者都声称原则上涵盖相同的用例。

小开

我看到上面的一些答案现在有点过时了。从我的角度来看，我每天都使用Solr（云端和非云端）和ElasticSearch，这里有一些有趣的区别：

  • 社区：Solr有一个更大、更成熟的用户、开发人员和贡献者社区。ES有一个较小但活跃的用户社区和一个不断增长的贡献者社区
  • 成熟度：Solr比较成熟，但是ES增长很快，我认为比较稳定
  • 性能：难以判断。我/我们没有做过直接的性能基准测试。LinkedIn的一个人确实比较过Solr vs. ES vs. Sensei一次，但最初的结果应该被忽略，因为他们对Solr和ES都使用了非专业的设置。
  • 设计：人们喜欢Solr。JavaAPI有点冗长，但人们喜欢它的组合方式。不幸的是，Solr代码并不总是很漂亮。此外，ES内置了分片、实时复制、文档和路由。虽然Solr中也存在一些这些，但感觉有点像事后的想法。
  • 支持：有公司为Solr和ElasticSearch提供技术和咨询支持。我认为唯一一家同时为两者提供支持的公司是Semattext（披露：我是Semattext创始人）
  • 可扩展性：两者都可以扩展到非常大的集群。ES比Solr 4.0之前版本的Solr更容易扩展，但在Solr 4.0中不再是这种情况。

有关Solr vs. ElasticSearch主题的更全面的报道，请查看https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/。这是Semattext系列文章中的第一篇文章，用于直接和中性的Solr vs. ElasticSearch比较。披露：我在Semattext工作。

小开

虽然上述所有链接都有优点，并且在过去让我受益匪浅，作为一名语言学家，在过去的15年里“接触”了各种Lucene搜索引擎，我不得不说Python中弹性搜索的开发非常快。话虽如此，有些代码对我来说并不直观。因此，我从开源的角度接触了ELK堆栈的一个组件Kibana，发现我可以在Kibana非常容易地生成elasticsearch的有点神秘的代码。此外，我也可以将ChromeSense es查询拉入Kibana。如果你使用Kibana来评估es，它会进一步加快你的评估速度。在其他平台上运行需要几个小时的东西在elasticsearch（RESTful接口）之上的JSON in Sense中启动并运行最坏的几分钟（最大的数据集）；充其量在几秒钟内。elasticsearch的留档虽然有700多页，但没有回答我遇到的通常会在SOLR或其他Lucene留档中解决的问题，这显然需要更多的时间来分析。此外，你可能想看看弹性搜索中的聚合，它将Facet提升到了一个新的水平。

大局：如果你正在做数据科学、文本分析或计算语言学，elasticsearch有一些排名算法，似乎在信息检索领域创新得很好。如果你正在使用任何TF/IDF算法、文本频率/逆文档频率，elasticsearch将1960年代的算法扩展到了一个新的水平，甚至使用了BM25、Best Match 25和其他相关性排名算法。所以，如果你正在对单词、短语或句子进行评分或排名，elasticsearch会即时进行评分，而不会像其他数据分析方法那样花费数小时的大量开销——这又节省了elasticsearch的时间。 使用es，将聚合的一些优势与实时JSON数据相关性评分和排名相结合，您可以找到一个成功的组合，具体取决于您的敏捷（故事）或架构（用例）方法。

注意：确实看到了上面关于聚合的类似讨论，但不是关于聚合和相关性评分-我对任何重叠表示歉意。 披露：我不为弹性工作，并且由于不同的架构路径，在不久的将来无法从他们的出色工作中受益，除非我用elasticsearch做一些慈善工作，这不是一个坏主意

小开

我使用Elasticsearch 3年，Solr大约一个月，我觉得Elasticsearch集群与Solr安装相比很容易安装。Elasticsearch有一个帮助文档池，有很好的解释。其中一个用例我坚持使用直方图聚合，它在ES中可用，但在Solr中找不到。

小开

如果您已经在使用SOLR，请继续坚持下去。如果您刚开始使用，请使用Elastic搜索。

SOLR中的最大主要问题已经修复，并且已经相当成熟。

小开

我一直在研究solr和弹性搜索。Net应用程序。 我遇到的最大问题是

弹性搜索：

  • 更多的代码和更少的配置，但是有API需要更改 但仍然是代码更改
  • 对于复杂类型，类型内的类型，即嵌套类型（在solr中无法实现）

Solr：

  • 更少的代码和更多的配置，因此更少的维护
  • 用于在查询期间对结果进行分组（在 弹性搜索简而言之，没有直路）
小开

我只使用弹性搜索。因为我发现solr很难开始。 弹性搜索的功能：

  1. 易于启动，很少设置。即使是新手也可以逐步设置集群。
  2. 简单的RESTful API，使用非关系型数据库查询。以及许多易于访问的语言库。
  3. 不错的文档，可以看书：。官网链接有网络版。
小开

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

solr堆栈

从下到上在以下图层中搜索平台：

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

参考文章：企业搜索

小开

我看到这里的很多人都在特性和功能方面回答了ElasticSearch与Solr的问题，但我在这里（或其他地方）没有看到太多关于它们在性能方面如何比较的讨论。

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

这是我发现的。ElasticSearch在索引文档方面的吞吐量高出13%，但Solr的速度要快十倍。在查询文档方面，Solr的吞吐量是ElasticSearch的五倍，速度是ElasticSearch的五倍。

小开

我创建了一个Elasticsearch与Solr和Splunk之间的主要差异表，您可以将其用作2016年更新：输入图片描述

小开

在solr中添加嵌套文档非常复杂，嵌套数据搜索也非常复杂。但Elastic Search易于添加嵌套文档和搜索

小开

想象一下用例：

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

在这种情况下，每个索引都有单独的ES实例的想法是巨大的开销。

根据我的经验，使用Elasticsearch支持这种用例非常复杂。

为啥？

首先。

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

改变太酷了！ （注意：想象一下SQL-server，它要求你在升级时对所有SQL语句做一些小的改变……无法想象。但对于ES来说这是正常的）

将在下一个主要版本中删除的弃用是如此性感！ （注：你知道，Java包含一些弃用，其中20+岁，但仍在实际Java版本工作…）

不仅如此，有时你甚至有一些无处记录的东西（个人只遇到过一次，但…）

所以。如果你想升级ES（因为你需要一些应用程序的新功能，或者你想得到bug修复）-你在地狱。特别是如果它是关于主要版本升级。

客户端API将无法返回兼容。索引设置将无法返回兼容。 与ES升级同时升级所有应用程序/服务是不现实的。

但你必须时不时地这样做。没有别的办法。

现有索引会自动升级吗？-是的。但当您需要更改一些旧索引设置时，它对您没有帮助。

要做到这一点，您需要不断投入大量精力……您的应用程序/服务与ES的未来版本的向前兼容性。 或者，您需要在应用程序/服务和ES之间构建（并且始终支持）某种中间件，它为您提供兼容的客户端API。 （而且，您不能使用传输客户端（因为它需要为每个次要版本ES升级进行jar升级），而这一事实并没有使您的生活更轻松）

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

秒。 简单的API？嗯……不是真的。 当你真正使用复杂的条件和聚合时……具有5个嵌套级别的JSON请求是什么，但并不简单。

不幸的是，我没有SOLR的经验，不能说什么。

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

备注： Sphinxsearch/Manticore确实很有趣。它不是基于Lucine的，因此有很大的不同。包含ES没有的盒子中的几个独特功能，并且使用中小型索引疯狂快速。


提交答案