为什么我们要选用 Elasticsearch 而不用 Solr
132 / 0 / 创建于 3年前
DRose 的个人博客
前言
首先我们要明确一点，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倍的提升。
从目前趋势来看，我们已经到了大数据时代，必然会面临着海量数据，相比于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一票！！！！！！
参考
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号