Solr对比ElasticSearch [关闭]

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

另外，哪种用例通常更适合每种用例？

更新资料

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

Apache Solr和ElasticSearch之间有很多比较，因此，我将引用我自己发现最有用的那些，即涵盖最重要的方面：

• Bob Yoplait已经将kimchy的答案与ElasticSearch，Sphinx，Lucene，Solr和Xapian关联。哪种适合哪种用法？，总结了他继续并创建ElasticSearch的原因，他认为，与Solr相比，它提供了更出色的分布式模型和易用性。

• 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 2的），分布式的，宁静，搜索引擎建立在Apache Lucene之上。

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

该Solr的和ElasticSearch产品听起来一见钟情惊人地相似，都使用同样的后端搜索引擎，即Apache的Lucene的。

当Solr变得更老，相当通用且成熟并且被相应地广泛使用时，ElasticSearch是专门为解决Solr缺点而提出的，以解决现代云环境中具有可伸缩性要求的缺点，而这些缺点很难用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创始人）
• 可扩展性：两者都可以扩展到非常大的集群。与Solr 4.0之前的Solr版本相比，ES易于扩展，但对于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的五倍，快五倍。

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

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

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

参考文章：企业搜索

我已经创建了一张Elasticsearch与Solr和splunk之间的主要差异表，您可以将其用作2016更新：

我一直在为.Net应用程序进行Solr和弹性搜索。我面临的主要区别是

弹性搜寻：

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

Solr：

• 更少的代码和更多的配置，从而减少了维护
• 用于在查询过程中对结果进行分组（总的来说，在弹性搜索中要做的工作总之没有直接的方法）

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

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

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

想象一下用例：

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

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

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

为什么？

第一。

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

重大更改非常酷！（注意：想象一下SQL服务器，它要求您在所有SQL语句中做一些小的更改，升级后……无法想象。但是对于ES来说，这是正常的）

在下一个主要版本中将弃用的弃用是如此性感！（注意：您知道，Java包含一些已弃用的特性，已有20多年的历史了，但仍然可以在实际的Java版本中使用。）

不仅如此，有时您甚至还可以找到任何地方都没有记载的内容（个人只遇到过一次，但是...）

所以。如果您想升级ES（因为某些应用程序需要新功能或想要修复错误），那么您将陷入困境。特别是关于主要版本升级时。

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

但是您必须不时这样做。没有其他办法了。

现有索引是否自动升级？-是的 但是，当您需要更改某些旧索引设置时，它无济于事。

要实现这一目标，您需要不断投入大量精力，以使您的应用程序/服务与ES的未来版本保持向前兼容性。或者，您需要在您的应用程序/服务与ES之间构建（并始终支持）某种中间件，从而为您提供兼容的客户端API。（并且，您不能使用Transport Client（因为每次次要版本的ES升级都需要jar升级），并且这一事实并不能使您的生活更轻松）

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

第二。简单的API？好吧...不。当您真正使用复杂的条件和聚合时。...具有5个嵌套级别的JSON请求就可以了，但并不简单。

不幸的是，我没有SOLR的经验，对此无能为力。

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

注意：Sphinxsearch / Manticore确实很有趣。它不是基于Lucine的，因此存在很大的不同。包含一些ES所没有的独特功能，并通过中小尺寸索引快速抓狂。

如果您已经在使用SOLR，请继续坚持下去。如果您正在启动，请进行弹性搜索。

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

我已经使用Elasticsearch三年了，而Solr已经使用了大约一个月，与Solr安装相比，我觉得Elasticsearch集群的安装非常容易。Elasticsearch拥有大量的说明性文档。我用过一种直方图聚合的用例之一，直方图聚合在ES中可用，但在Solr中找不到。

我只使用弹性搜索。由于我发现solr很难启动。Elastic-search的功能：

1. 易于启动，设置很少。即使是新手也可以逐步设置群集。
2. 简单的Restful API，使用NoSQL查询。还有许多语言库，可轻松访问。
3. 好的文件，您可以阅读本书：。官方网站上有一个网络版本。

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