协慌网

登录 贡献 社区

Solr 与 ElasticSearch

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

另外,哪种用例通常更适合每种用例?

答案

更新资料

现在,问题范围已得到纠正,我也可以在这方面添加一些内容:

Apache SolrElasticSearch之间有很多比较,因此,我将引用我自己最有用的那些,即涵盖最重要的方面:

  • 鲍勃 · 约普拉特(Bob Yoplait)已经将 kimchy 的答案与ElasticSearch,Sphinx,Lucene,Solr 和 Xapian 相关联。哪种适合哪种用法? ,总结了他继续并创建 ElasticSearch的原因,他认为,与 Solr 相比, ElasticSearch 提供了更为出色的分布式模型,并且易于使用

  • Ryan Sonnek 的实时搜索:Solr vs Elasticsearch提供了有见地的分析 / 比较,并解释了尽管他已经是 Solr 的用户,但为何从 Solr 切换到 ElasticSeach 的原因 - 他总结如下:

    在构建标准搜索应用程序时Solr可能是选择的武器,但是Elasticsearch通过用于创建现代实时搜索应用程序体系结构将其提升到一个新的水平。渗滤是一种令人兴奋的创新功能,可以单手将 Solr 吹出水面。 Elasticsearch 具有可伸缩性,快速性和与之集成的梦想 。 Adios Solr,很高兴认识您。 [强调我的]

  • Wikipedia 上有关 ElasticSearch 的文章引用了著名的德国 iX 杂志的比较 ,列出了优点和缺点,这些优点和缺点几乎可以总结出上面已经说过的内容:

    优点

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

    缺点

    • 只有一个主要开发人员 [根据当前的Elasticsearch GitHub 组织 ,该应用程序不再适用,除了首先具有相当活跃的提交者基础之外]
    • 没有自动预热功能 [根据新的索引预热 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 是云中的一项完全托管的搜索服务,使客户可以轻松地将快速且高度可扩展的搜索功能集成到其应用程序中。

乍一看, SolrElasticSearch产品听起来惊人地相似,并且都使用相同的后端搜索引擎,即Apache Lucene

虽然Solr 的是旧的,相当具有通用性和成熟,因此被广泛使用,ElasticSearch已经专门开发地址Solr 的缺点与现代云环境的可扩展性的要求,这是硬(ER),以解决与Solr 的

因此,将ElasticSearch与最近推出的Amazon CloudSearch进行比较可能是最有用的(请参阅入门文章 “ 在一小时内开始搜索,价格低于 $ 100 / 月” ),因为两者都声称原则上涵盖相同的用例。

我看到上面的一些答案现在有点过时了。从我的角度来看,我每天都与 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 版本更易于扩展,但是使用 Solr 4.0 不再如此。

要更全面地了解 Solr 与 ElasticSearch 主题,请访问https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ 。这是 Sematext 发表的系列文章中的第一篇,该文章进行了直接和中性的 Solr 与 ElasticSearch 比较。披露:我在 Sematext 工作。

我看到很多人在特性和功能方面已经回答了这个 ElasticSearch vs Solr 问题,但是在这里(或其他地方)我没有看到太多关于他们如何比较性能的讨论。

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

这是我发现的。当对文档建立索引时,ElasticSearch 的吞吐量提高了 13%,但 Solr 的速度提高了十倍。在查询文档时,Solr 的吞吐量是 ElasticSearch 的五倍,快五倍。