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

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

以下是我的发现。在索引文档时，ElasticSearch的吞吐量要高13%，而Solr的速度要快10倍。在文档查询方面，Solr的吞吐量是ElasticSearch的5倍，速度也是ElasticSearch的5倍。

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

我一直致力于。net应用程序的solr和弹性搜索。 我所面临的主要不同是

弹性搜索:

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

Solr:

代码更少，配置更多，因此维护更少 用于在查询期间对结果进行分组(在 弹性搜索，简而言之，没有直接的方法)

想象一下用例:

大量(100+)小型(10Mb-100Mb, 1000-100000个文档)搜索索引。 它们被很多应用程序(微服务)使用 每个应用程序可以使用多个索引 小尺寸指数，是的。但是巨大的负载(每秒数百个搜索请求)和复杂的请求(多个聚合、条件等) 不允许停机 所有这些都是持续多年的工作，并不断增长。

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

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

Why?

第一。

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

突破性的改变太酷了! (注意:想象一下SQL-server需要你在所有sql语句中做小的改变，当升级时…真不敢想象。但对于ES来说是正常的)

将在下一个主要版本中删除的弃用是如此性感! (注意:你知道，Java包含一些过时的东西，已经有20多年的历史了，但在实际的Java版本中仍然可以工作…)

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

所以。如果你想升级ES(因为你需要一些应用程序的新功能或者你想修复错误)-你就在地狱里。尤其是关于重大版本升级的时候。

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

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

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

为了适应这一点，你需要不断地在……您的应用程序/服务与ES未来版本的向前兼容性。 或者，您需要在应用程序/服务和ES之间构建某种中间件(无论如何都要不断地支持)，从而为您提供兼容的客户机API。 (而且，您不能使用Transport Client(因为每次小版本ES升级都需要升级jar)，这并没有使您的生活更轻松)

它看起来简单便宜吗?不，不是。远非如此。 对基于ES的复杂基础设施的持续维护，无论如何都是昂贵的。

第二。 简单的API ?嗯…没有真的。 当你真的在使用复杂的条件和聚合....带有5个嵌套级别的JSON-request是什么，但并不简单。

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

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

注意: Sphinxsearch/Manticore确实很有趣。它不是基于Lucine的，结果严重不同。包含几个独特的功能，从盒子，ES没有和疯狂的快速与小/中等大小的索引。

我已经创建了elasticsearch和Solr和splunk之间的主要差异表，您可以使用它作为2016年的更新:

While all of the above links have merit, and have benefited me greatly in the past, as a linguist "exposed" to various Lucene search engines for the last 15 years, I have to say that elastic-search development is very fast in Python. That being said, some of the code felt non-intuitive to me. So, I reached out to one component of the ELK stack, Kibana, from an open source perspective, and found that I could generate the somewhat cryptic code of elasticsearch very easily in Kibana. Also, I could pull Chrome Sense es queries into Kibana as well. If you use Kibana to evaluate es, it will further speed up your evaluation. What took hours to run on other platforms was up and running in JSON in Sense on top of elasticsearch (RESTful interface) in a few minutes at worst (largest data sets); in seconds at best. The documentation for elasticsearch, while 700+ pages, didn't answer questions I had that normally would be resolved in SOLR or other Lucene documentation, which obviously took more time to analyze. Also, you may want to take a look at Aggregates in elastic-search, which have taken Faceting to a new level.

Bigger picture: if you're doing data science, text analytics, or computational linguistics, elasticsearch has some ranking algorithms that seem to innovate well in the information retrieval area. If you're using any TF/IDF algorithms, Text Frequency/Inverse Document Frequency, elasticsearch extends this 1960's algorithm to a new level, even using BM25, Best Match 25, and other Relevancy Ranking algorithms. So, if you are scoring or ranking words, phrases or sentences, elasticsearch does this scoring on the fly, without the large overhead of other data analytics approaches that take hours--another elasticsearch time savings. With es, combining some of the strengths of bucketing from aggregations with the real-time JSON data relevancy scoring and ranking, you could find a winning combination, depending on either your agile (stories) or architectural(use cases) approach.

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