如果您已经在使用SOLR，请坚持使用。如果你正在创业，使用弹性搜索。

最大的主要问题已经在SOLR中得到了解决，它是相当成熟的。

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

弹性搜索:

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

Solr:

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

更新

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

Apache Solr和ElasticSearch之间有很多比较，所以我将引用我自己认为最有用的，即涵盖最重要的方面:

Bob Yoplait already linked kimchy's answer to ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?, which summarizes the reasons why he went ahead and created ElasticSearch, which in his opinion provides a much superior distributed model and ease of use in comparison to Solr. Ryan Sonnek's Realtime Search: Solr vs Elasticsearch provides an insightful analysis/comparison and explains why he switched from Solr to ElasticSeach, despite being a happy Solr user already - he summarizes this as follows: Solr may be the weapon of choice when building standard search applications, but Elasticsearch takes it to the next level with an architecture for creating modern realtime search applications. Percolation is an exciting and innovative feature that singlehandedly blows Solr right out of the water. Elasticsearch is scalable, speedy and a dream to integrate with. Adios Solr, it was nice knowing you. [emphasis mine] The Wikipedia article on ElasticSearch quotes a comparison from the reputed German iX magazine, listing advantages and disadvantages, which pretty much summarize what has been said above already: Advantages: ElasticSearch is distributed. No separate project required. Replicas are near real-time too, which is called "Push replication". ElasticSearch fully supports the near real-time search of Apache Lucene. Handling multitenancy is not a special configuration, where with Solr a more advanced setup is necessary. ElasticSearch introduces the concept of the Gateway, which makes full backups easier. Disadvantages: Only one main developer [not applicable anymore according to the current elasticsearch GitHub organization, besides having a pretty active committer base in the first place] No autowarming feature [not applicable anymore according to the new Index Warmup API]

最初的回答

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

Apache Solr - Apache Solr offers Lucene's capabilities in an easy to use, fast search server with additional features like faceting, scalability and much more Amazon ElastiCache - Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. Please note that Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and popular tools that you use today with existing Memcached environments will work seamlessly with the service (see Memcached for details).

(强调我的)

也许这已经与以下两种相关技术混淆了:

ElasticSearch -这是一个开源(Apache 2)、分布式、RESTful的搜索引擎，建立在Apache Lucene之上。 Amazon CloudSearch—Amazon CloudSearch是一个完全托管的云搜索服务，允许客户轻松地将快速和高度可扩展的搜索功能集成到他们的应用程序中。

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

虽然Solr更老，功能更全面，更成熟，因此被广泛使用，但ElasticSearch是专门为解决Solr在现代云环境中可伸缩性需求方面的缺点而开发的，这些缺点很难用Solr解决。

因此，将ElasticSearch与最近推出的Amazon CloudSearch进行比较可能是最有用的(参见介绍性文章Start Searching in One Hour for Less Than 100 $ / Month)，因为两者都声称在原则上涵盖相同的用例。

想象一下用例:

大量(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没有和疯狂的快速与小/中等大小的索引。

在solr中添加嵌套文档非常复杂，嵌套数据搜索也非常复杂。但弹性搜索容易添加嵌套文档和搜索

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

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

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

参考文章:企业搜索