Elasticsearch01： 快速了解Elasticsearch

一、为什么要学Elasticsearch？

针对海量数据计算分析，前面我们学习了MapReduce、Hive、Spark、Flink这些计算引擎和分析工具，但是它们侧重的都是对数据的清洗、聚合之类的需求。
如果想要在海量数据里面快速查询出一批满足条件的数据，这些计算引擎都需要生成一个任务，提交到集群中去执行，这样中间消耗的时间就长了。

并且针对多条件组合查询需求，这些计算引擎在查询的时候基本上都要实现全表扫描了，这样查询效率也是比较低的。

所以，为了解决海量数据下的快速检索，以及多条件组合查询需求，Elasticsearch就应运而生了。

二、Elasticsearch简介

Elasticsearch是一个分布式的全文检索引擎，它是对lucene的功能做了封装，能够达到实时搜索，稳定，可靠，快速等特点。

如果大家对Lucene有所了解的话，那么针对Elasticsearch其实就好理解了。

三、常见的全文检索引擎

1、Lucene

Lucene是Java家族中最为出名的一个开源搜索引擎，在Java世界中属于标准的全文检索程序，它提供了完整的查询引擎和索引引擎。
但是它也存在一些缺点
1：不支持分布式，无法扩展，海量数据下会存在瓶颈。
2：提供的都是低级API，使用繁琐。
3：没有提供web界面，不便于管理。

2、Solr

Solr是一个用java开发的独立的企业级搜索应用服务器，它是基于Lucene的。
它解决了Lucene的一些痛点，提供了web界面，以及高级API接口。
并且从Solr4.0版本开始，Solr开始支持分布式，称之为Solrcloud。

3、Elasticsearch

Elasticsearch是一个采用Java语言开发的，基于Lucene的开源、分布式的搜索引擎,能够实现实时搜索。
它最重要的一个特点是天生支持分布式，可以这样说，Elasticsearch就是为了分布式而生的。
它对外提供REST API接口，便于使用，通过外部插件实现web界面支持，便于管理集群。

Elasticsearch一般我们会简称为ES。

从这里可以看出来，Solr和ES的功能基本是类似的，那在工作中该如何选择呢？

四、Solr vs Elasticsearch

Solr从2007年就出现了，在传统企业中应用的还是比较广泛的，并且在2013年的时候，Solr推出了4.0版本，提供了Solrcloud，开始正式支持分布式集群。

ES在2014年的时候才正式推出1.0版本，所以它的出现要比Solr晚很多年。

但是ES从一开始就是为了解决海量数据下的全文检索，所以在分布式集群相关特性层面，ES会优于Solrcloud。
建议：

如果之前公司里面已经深度使用了Solr，现在为了解决海量数据检索问题，建议优先考虑使用Solrcloud。
如果之前没有使用过Solr，那么在海量数据的场景下，建议优先考虑使用ES。

五、MySQL VS Elasticsearch

为了便于理解ES，在这里我们拿MySQL和ES做一个对比分析：

解释：
1： MySQL中有Database（数据库）的概念，对应的在ES中有Index（索引库）的概念。
2：MySQL中有Table（表）的概念，对应的在ES中有Type（类型）的概念，不过需要注意，ES在1.x~5.x版本中是正常支持Type的，每一个Index下面可以有多个Type。

从6.0版本开始，每一个Index中只支持1个Type，属于过渡阶段。
从7.0版本开始，取消了Type，也就意味着每一个Index中存储的数据类型可以认为都是同一种，不再区分类型了。

为何要取消Type？

主要还是基于性能方面的考虑。
因为ES设计初期，是直接参考了关系型数据库的设计模型，存在了 Type（表）的概念。
但是，ES的搜索引擎是基于 Lucene 的，这种基因决定了 Type 是多余的。

在关系型数据库中Table是独立的，但是在ES中同一个Index中不同Type的数据在底层是存储在同一个Lucene的索引文件中的。

如果在同一个Index中的不同Type中都有一个id字段，那么ES会认为这两个id字段是同一个字段，你必须在不同的Type中给这个id字段定义相同的字段类型，否则，不同Type中的相同字段名称就会在处理的时候出现冲突，导致Lucene处理效率下降。

除此之外，在同一个Index的不同Type下，存储字段个数不一样的数据，会导致存储中出现稀疏数据，影响Lucene压缩文档的能力，最终导致ES查询效率降低。

3：MySQL中有Row（行）的概念，表示一条数据，在ES中对应的有Document（文档）。

4：MySQL中有Column（列）的概念，表示一条数据中的某个列，在ES中对应的有Field（字段）。

六、Elasticsearch核心概念

ES中几个比较核心的概念：
Cluster：集群
Shard：分片
Replica：副本
Recovery：数据恢复

接下来具体分析一下这几个概念：

1、Cluster

代表ES集群，集群中有多个节点，其中有一个为主节点，这个主节点是通过选举产生的。

主从节点是对于集群内部来说的，ES的一个核心特性就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看ES集群，在逻辑上是一个整体，我们与任何一个节点的通信和与整个ES集群通信是等价的。

主节点的职责是负责管理集群状态，包括管理分片的状态和副本的状态，以及节点的发现和删除。

2、Shard

代表索引库分片，ES集群可以把一个索引库分成多个分片。

这样的好处是可以把一个大的索引库水平拆分成多个分片，分布到不同的节点上，构成分布式搜索，进而提高性能和吞吐量。

注意：分片的数量只能在创建索引库的时候指定，索引库创建后不能更改。

默认情况下一个索引库有1个分片。

每个分片中最多存储2,147,483,519条数据，其实就是Integer.MAX_VALUE-128。
因为每一个ES的分片底层对应的都是Lucene索引文件，单个Lucene索引文件最多存储Integer.MAX_VALUE-128个文档（数据）。
注意：在ES7.0版本之前，每一个索引库默认是有5个分片的。

3、Replica

代表分片的副本，ES集群可以给分片设置副本。

副本的第一个作用是提高系统的容错性，当某个分片损坏或丢失时可以从副本中恢复。第二个作用是提高ES的查询效率，ES会自动对搜索请求进行负载均衡。

注意：分片的副本数量可以随时修改。
默认情况下，每一个索引库只有1个主分片和1个副本分片（前提是ES集群有2个及以上节点，如果ES集群只有1个节点，那么索引库就只有1个主分片，不会产生副本分片，因为主分片和副本分片在一个节点里面是没有意义的）。
为了保证数据安全，以及提高查询效率，建议副本数量设置为2或者3。

4、Recovery

代表数据恢复或者数据重新分布。

ES集群在有节点加入或退出时会根据机器的负载对分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复