759

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

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

4

12 回答 12

572

更新

既然问题范围已经更正，我也可能会在这方面添加一些内容：

Apache Solr和ElasticSearch之间有很多比较可用的，所以我将参考那些我自己认为最有用的比较，即涵盖最重要的方面：

  • Bob Yoplait 已经将 kimchy 的答案与ElasticSearch、Sphinx、Lucene、Solr、Xapian 联系起来。哪个适合哪个用途？，其中总结了他继续创建 ElasticSearch的原因，在他看来，与 Solr 相比，ElasticSearch提供了更优越的分布式模型和易用性。

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

    在构建标准搜索应用程序时， Solr可能是首选武器，但Elasticsearch将其提升到一个新的水平，其 架构可用于创建现代实时搜索应用程序。渗透是一项令人兴奋的创新功能，可以单枪匹马地将 Solr 吹出水面。Elasticsearch 具有可扩展性、快速性和与. Adios Solr，很高兴认识你。[强调我的]

  • ElasticSearch 上的 Wikipedia 文章引用了著名的德国 iX 杂志的比较，列出了优缺点，几乎总结了上面已经说过的内容：

    优点：

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

    缺点：

初步答案

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

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

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

    • 请注意，Amazon ElastiCache 与 Memcached 协议兼容，Memcached 是一种广泛采用的内存对象缓存系统，因此您目前在现有 Memcached 环境中使用的代码、应用程序和流行工具将与该服务无缝协作（有关详细信息，请参阅Memcached）。

[强调我的]

也许这已经以一种或另一种方式与以下两种相关技术混淆了：

  • ElasticSearch -它是一个开源 (Apache 2)、分布式、RESTful、建立在 Apache Lucene 之上的搜索引擎。

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

Solr和ElasticSearch产品乍一看非常相似，并且都使用相同的后端搜索引擎，即Apache Lucene。

虽然Solr较老、用途广泛且成熟并因此被广泛使用，但 ElasticSearch是专门为解决Solr在现代云环境中具有可扩展性要求的缺点而开发的，而这些缺点很难（更）用Solr解决。

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

于 2012-04-18T16:15:50.433 回答
210

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

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

有关 Solr 与 ElasticSearch 主题的更全面介绍，请查看https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/。这是 Sematext 进行直接和中立的 Solr 与 ElasticSearch 比较的系列文章中的第一篇。披露：我在 Sematext 工作。

于 2012-08-26T15:02:22.173 回答
26

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

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

这是我发现的。在索引文档方面，ElasticSearch 的吞吐量提高了 13%，但 Solr 的速度提高了 10 倍。在查询文档时，Solr 的吞吐量是 ElasticSearch 的五倍，速度是 ElasticSearch 的五倍。

于 2017-02-26T19:15:42.090 回答
18

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

solr 堆栈

搜索平台从下到上分为以下几层：

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

参考文章：企业搜索

于 2016-11-11T16:23:24.520 回答
17

我一直致力于 .Net 应用程序的 solr 和弹性搜索。我面临的主要区别是

弹性搜索：

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

索尔：

  • 更少的代码和更多的配置，因此更少的维护
  • 用于在查询期间对结果进行分组（在弹性搜索中需要做很多工作，简而言之，没有直接的方法）
于 2016-09-07T14:35:20.163 回答
16

我创建了一个关于 elasticsearch 与 Solr 和 splunk 之间主要区别的表格，您可以将其用作 2016 更新：在此处输入图像描述

于 2017-05-03T21:51:56.177 回答
8

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

更大的图景：如果你从事数据科学、文本分析或计算语言学，elasticsearch 有一些排名算法，这些算法似乎在信息检索领域创新得很好。如果您使用任何 TF/IDF 算法、文本频率/逆文档频率，elasticsearch 将这个 1960 年的算法扩展到一个新的水平，甚至使用 BM25、Best Match 25 和其他相关性排名算法。因此，如果您要对单词、短语或句子进行评分或排名，elasticsearch 会即时进行评分，而无需花费数小时的其他数据分析方法的大量开销 - 另一个弹性搜索时间节省。使用 es，将聚合中的分桶的一些优势与实时 JSON 数据相关性评分和排名相结合，您可以找到一个成功的组合，

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

于 2016-02-03T00:04:48.177 回答
6

如果您已经在使用 SOLR，请坚持使用它。如果您正在启动，请选择弹性搜索。

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

于 2016-08-25T11:54:07.087 回答
6

想象一下用例：

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

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

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

为什么？

第一的。

主要问题是基本的向后兼容性无视。

突破性的变化太酷了！（注意：想象一下 SQL-server 需要你对所有 SQL 语句进行小改动，升级时......无法想象。但对于 ES 来说这是正常的）

将在下一个主要版本中删除的弃用是如此性感！（注意：你知道，Java 包含一些弃用，它们已有 20 多年的历史，但仍在实际的 Java 版本中工作......）

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

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

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

但是你必须时不时地这样做。别无退路。

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

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

是不是看起来简单又便宜？不，这不对。离得很远。基于 ES 的复杂基础设施的持续维护在所有可能的意义上都是昂贵的。

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

不幸的是，我没有使用 SOLR 的经验，对此无话可说。

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

注意：Sphinxsearch/Manticore 确实很有趣。它不是基于 Lucine 的，因此完全不同。包含 ES 所没有的几个独特功能，并且具有中小型索引的疯狂快速。

于 2017-11-27T19:33:18.590 回答
4

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

于 2016-02-26T06:45:59.300 回答
3

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

于 2017-07-12T08:43:10.190 回答
2

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

  1. 容易上手，很少设置。即使是新手也可以逐步建立集群。
  2. 使用 NoSQL 查询的简单 Restful API。以及许多易于访问的语言库。
  3. 好文档，可以看书：. 官网有网页版。
于 2016-09-27T01:03:14.760 回答