前言#

首先我们要明确一点，elasticsearch 和 solr 没有好坏之分，只有适合不适合。这是通用的道理。我们需要根据我们的实际情况来选择最适合我们的搜索引擎。

所以我们对 elasticsearch 和 solr 的优缺点、适用场景进行一下对比，以及我们的未来需求，来找到最合适的方案。

名词解释#

大部分认知中，ES 代表 elasticsearch，还有部分理解中 ES 代表 elastic Stack，本文中使用 ES 表示 elasticsearch。

Solr 优缺点#

solr 优点#

1. Solr 有一个更大、更成熟的用户、开发和贡献者社区。

2. 支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。

3. Solr 比较成熟、稳定。

4. 不考虑建索引的同时进行搜索，速度更快。

solr 缺点#

1. 建立索引时，搜索效率下降，实时索引搜索消息不高。

elasticsearch 优缺点#

elasticsearch 优点#

1. Elasticsearch 是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。

2. Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。

3. 处理多租户（multitenancy）不需要特殊配置，而 Solr 则需要更多的高级设置。

4. Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。

5. 各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

elasticsearch 缺点#

1. 还不够自动（不适合当前新的 Index Warmup API）

solr 和 elasticsearch 比较#

然而从上面的优缺点对比来看，我们很难发现哪一个搜索引擎更适合我们。甚至我们对于他们的优缺点的确切概念还有些难以理解。

我们可以对 solr 和 ES 部分特性做一些对比，分析他们之间的差异性，来找到更适合我们的搜索引擎。

流行趋势#

毫无疑问，ES 已经成为全文索引的事实霸主，名气在国内赶超 Solr。

通过 Google 搜索趋势对比发现，ES 比 Solr 更加有吸引力，Solr 反而有下降的趋势，但这并不意味着 Solr 已经没落，相反，Solr 仍然是最受欢迎的搜索引擎之一。这一点我们可以从搜索引擎排名中可以看出，当前最受欢迎的前三个搜索引擎：Elasticsearch、Splunk 和 Solr 中仍然包含 Solr。

检索速度#

当单纯的对已有数据进行搜索时，Solr 更快。

当实时建立索引时，Solr 会产生 io 阻塞，查询性能较差，Elasticsearch 具有明显的优势。

随着数据量的增加，Solr 的搜索效率会变得更低，而 Elasticsearch 却没有明显的变化。

大型互联网公司，实际生产环境测试，将搜索引擎从 Solr 转到 Elasticsearch 以后的平均查询速度有了 50 倍的提升。

elastic 和 solr 检索速度

从目前趋势来看，我们已经到了大数据时代，必然会面临着海量数据，相比于 Solr，ES 在海量数据检索速度方面有巨大优势。

Solr 是传统应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

近实时搜索#

近实时搜索一直是 ES 的优势之一。然而这么说其实没有什么道理，因为 Solr 也实现了近实时搜索，只不过因为 ES 先提起这个概念，所以大家在谈起近实时搜索的时候，总是优先想起来 ES。

而且实时性这个是 Lucene 的能力，而不是 ES 和 Solr 的。

社区#

• Solr 拥有更多、更成熟的用户、开发者和贡献社区。网上可以搜到大量文档，以及问题解决案例。

• ES 虽然发布时间较短，但是发展迅速，很多知名公司都在使用。社区虽然小，但是很活跃。所以完全不必担心。elasticsearch 中文社区

扩容（分布式）#

ES 为分布式而生，而且它的设计隐藏了分布式本身的复杂性。ES 默认是集群化的（即时是在单台服务器上运行，也称之为集群），并且总是可以添加更多的服务器用于增加容量或者容错性。类似的，如果负载较低的时候，可以很容易地从集群中移除服务器，降低成本。

SolrCloud 是 Solr 提供的分布式搜索方案。

当你需要大规模，容错，分布式索引和检索能力时使用 SolrCloud。

当索引量很大，搜索请求并发很高时，同样需要使用 SolrCloud 来满足这些需求。

不过当一个系统的索引数据量少的时候是不需要使用 SolrCloud 的。

SolrCloud 是基于 Solr 和 Zookeeper 的分布式搜索方案。它的主要思想是使用 Zookeeper 作为 SolrCloud 集群的配置信息中心，统一管理 solrcloud 的配置，比如 solrconfig.xml 和 schema.xml。

对于大多数数据库来说，横向扩展（增加新机器）意味着你的程序将做很大改动才能利用这些新添加的设备。对比来说，ES 天生就是分布式的，它知道如何管理节点来提供高扩展和高可用，这意味着你的程序不必要关心这些。

数据量#

分布式的 ElasticSearch 支持的数据量确实更大，毫无疑问。但这是相对于单机版 Solr 来说的，分布式 Solr-cloud 数据量也是一样的支持。

在这一点上，Solr 和 ES 并没有什么区别。

数据聚合功能（aggregation） ☆☆☆☆☆☆☆☆#

这个打这么多☆，纯粹是因为这点真是太太太突出了。

无论选择哪个搜索引擎，我们都有一个重要的目的：组织数据为我们的目标所服务。

ES 为我们提供了一个超级棒的功能，数据聚合（aggregation）。聚合功能为 ES 注入了统计分析的血统，使用户在面对大数据提取统计指标时变得游刃有余。

而 Solr 中同样提供相似的功能 Analytics Component

这也反映出，其实 ES 和 Solr 并没有什么太大区别。

模式#

Solr 中的数据是结构化的，Solr 通过模式文件 schema.xml 文件来定义这种结构。

ES 中的文档是无模式的，也就是说并非所有的文档都需要拥有相同的字段，它们不是受限于同一种模式。

ES 会有一种自动检测的功能，检测一篇新近索引的文档是否拥有一个映射中尚未存在的字段，如果不存在，ES 会自动的将新字段加入映射。为了添加这个字段，ES 不得不确定它是什么类型，于是 ES 会进行猜测。例如：如果值是 7，ES 会假设字段是长整型。

这种做法的缺点是：ES 可能猜的不对。例如，在索引了值 7 之后，你可能再索引 hello world，这时由于它是 string 而不是 long，索引就会失败。

对于线上环境，最安全的方式是在索引数据之前，就定义好所需的映射。

配置管理 ☆#

ES 的一个强项是，它的默认配置对程序员非常友好，入门非常容容易。ElasticSearch 很多功能都是开箱即用，并不需要用户去配置。ElasticSearch 的设计哲学是尽量减少用户犯错的可能，ES 对运行环境还做了诸多限制，以避免运行过程中出现一些莫名其妙的错误，因为很多用户并不是这些领域的专家，他们没法从这些错误中找到原因。ES 帮助我们从复杂的配置中解脱出来，将更多的时间和精力放在其他事情上。

Solr 的配置太过于灵活，给了用户很多犯错误的可能。但 Solr 的定制能力更强，几乎什么都可以配置。对于开发者来说，要实现一个新的功能，可以不用动 Solr 核心代码，而给 Solr 增加一些 Processer 和 Component，然后通过 xml 配置服务器的行为。

适用场景#

网络上对两个搜索引擎的适用场景众说纷纭。

奈何个人才疏学浅，无法分辨真伪。

但是有一点，Solr 和 ES 作为当前两个最流行的搜索引擎，本来就是互相借鉴，共同进步，没有明显的差异性，没有明显的适用和不适用，只能说择其善者而从之。

如果真的有，我会总结在这里。

结论#

ES 和 Solr 本质上其实并没有什么太大的差别，毕竟都是基于 Lucene。而且这两个搜索引擎还在不断迭代，该有的功能都有，只不过实现方式不一致。Solr 实现了许多功能，而 ES 的许多功能都是通过插件的方式实现的。

但是，谁叫 ES 目前更流行呢，我投 ES 一票！！！！！！

参考#

• solr-vs-elasticsearch

• 全文搜索引擎选 ElasticSearch 还是 Solr？

• elastic 发展历程

• ElasticSearch 和 solr 的差别

• 择其善而从之 —— 我为什么开始学习 ElasticSearch

• [译] ElasticSearch vs. Solr

• 有赞搜索引擎实践 (工程篇)

• Solr vs ElasticSearch，搜索技术哪家强

本作品采用《CC 协议》，转载必须注明作者和本文链接