Solr对比ElasticSearch

Question

这些技术之间的核心架构差异是什么？另外，哪种用例通常更适合每个用例？

Answer 1

更新资料

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

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 /月”），因为两者都声称原则上涵盖相同的用例。

Answer 2

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

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

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