更新資料

現在，問題范圍已得到糾正，我也可以在這方面添加一些內容：

Apache Solr和ElasticSearch之間有很多比較，因此，我將引用我自己最有用的那些，即涵蓋最重要的方面：

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

Amazon CloudSearch - Amazon CloudSearch是云中的一項完全托管的搜索服務，使客戶可以輕松地將快速且高度可擴展的搜索功能集成到其應用程序中。

該Solr的和ElasticSearch產品聽起來一見鐘情驚人地相似，都使用同樣的后端搜索引擎，即Apache的Lucene的。

雖然Solr的是舊的，相當靈活和成熟，因此被廣泛使用，ElasticSearch已經開發專門解決Solr的與現代的云環境的可擴展性的要求，這是硬（ER）的缺點，以解決與Solr的。

因此，將ElasticSearch與最近推出的Amazon CloudSearch進行比較可能是最有用的（請參閱入門文章“ 在一小時內開始搜索，價格低于$ 100 /月”），因為兩者都聲稱原則上涵蓋相同的用例。

我看到這里的很多人已經就特性和功能回答了這個ElasticSearch vs Solr問題，但是我在這里（或其他地方）沒有看到太多關于他們如何比較性能的討論。

這就是為什么我決定進行自己的調查。我采用了一個已經編碼的異構數據源微服務，該服務已經使用Solr進行術語搜索。我關閉了Solr for ElasticSearch，然后使用已編碼的負載測試應用程序在AWS上運行了兩個版本，并捕獲了性能指標以進行后續分析。

這是我發現的。當對文檔建立索引時，ElasticSearch的吞吐量提高了13％，但是Solr的速度提高了十倍。在查詢文檔時，Solr的吞吐量是ElasticSearch的五倍，快五倍。