es | 易学教程

1、为什么要用es

我们的要求：（1）搜索解决方案要快（2）最好是有一个零配置和一个完全免费的搜索模式（3）我们希望能够简单地使用JSON/XML通过HTTP的索引数据

（4）我们希望我们的搜索服务器始终可用，并能够从一台开始并在需要扩容时方便地扩展到数百（5）我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案

2、es的优点（lucene的缺点es都已解决）

　　Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。但是，Lucene只是一个库，使用非常复杂。

　　lucene缺点：

　　 1）只能在JAVA项目中使用,并且要以jar包的方式直接集成项目中.

　　2）配置及使用非常复杂-创建索引和搜索索引代码多

　　 3）不支持集群环境-索引数据不同步（不支持大型项目）

　　 4）索引数据如果太多就不行。索引库和应用所在同一个服务器,共同占用硬盘.共用空间少.

3、es解决了lucene的那些缺点：

　　（1）优化Lucene的调用方式，通过简单的 RESTful API来隐藏Lucene的复杂性（调用简单）

　（2）并实现了高可用的分布式集群的搜索方案（高可用，分布式）

　　（3）分布式的实时分析搜索引擎（实时）

　　（4）可以扩展到上百台服务器，处理PB级结构化或非结构化数据（扩展性好）

　　（5）高度集成化的服务，支持各种语言

4、类似框架

①Solr（重量级对手） /SolrJ

　　Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，SolrJ 还增加了NoSQL支持。

　　Solr和ES比较：

Solr 利用 Zookeeper 进行分布式管理，支持更多格式的数据（HTML/PDF/CSV），官方提供的功能更多在传统的搜索应用中表现好于 ES，但实时搜索效率低。

ES自身带有分布式协调管理功能，但仅支持json文件格式，本身更注重于核心功能，高级功能多有第三方插件提供，在处理实时搜索应用时效率明显高于 Solr。

② Katta

　　基于 Lucene 的，支持分布式，可扩展，具有容错功能，准实时的搜索方案。

　　优点：开箱即用，可以与 Hadoop 配合实现分布式。具备扩展和容错机制。

　　缺点：只是搜索方案，建索引部分还是需要自己实现。在搜索功能上，只实现了最基本的需求。成功案例较少，项目的成熟度稍微差一些。

③ HadoopContrib

　　Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。

　　优点：分布式建索引，具备可扩展性。

　　缺点：只是建索引方案，不包括搜索实现。工作在批处理模式，对实时搜索的支持不佳。

5、传统数据库和ES的对应关系：

　　关系数据库（MYSQL） -> 数据库DB-> 表TABLE-> 行ROW-> 列Column

　　Elasticsearch -> 索引库Indices -> 类型Types -> 文档Documents -> 字段Fields

6、es支持的字段类型

　　① 基本字段类型

　　字符串（String）：text,keyword

　　 text默认为全文文本，keyword默认为非全文文本

　　数字：long,integer,short,double,float

　　日期：date

　　逻辑：boolean

　　② 复杂数据类型

　　对象类型：object

　　数组类型：array

　　地理位置：geo_point,geo_shape

7、Bulk（批量操作）一次最大处理多少数据量？

bulk会把将要处理的数据载入内存中，所以数据量是有限制的

最佳的数据量不是一个确定的数值，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载。

一般建议是1000-5000个文档，如果你的文档很大，可以适当减少队列,大小建议是5-15MB，默认不能超过100M

，可以在es的配置文件中修改这个值http.max_content_length: 100mb.

8、ES在高并发的情况下如何保证数据线程安全问题？

在读数据与写数据之间如果有其他线程进行写操作，就会出问题，es使用版本控制才避免这种问题。

在修改数据的时候指定版本号，操作一次版本号加1。

9、ES自动映射的规则

　　字段映射的常用属性配置列表

type	类型：基本数据类型，integer,long,date,boolean,keyword,text...
enable	是否启用：默认为true。 false：不能索引、不能搜索过滤，仅在_source中存储
boost	权重提升倍数：用于查询时加权计算最终的得分。
format	格式：一般用于指定日期格式，如 yyyy-MM-dd HH:mm:ss.SSS
ignore_above	长度限制：长度大于该值的字符串将不会被索引和存储。
ignore_malformed	转换错误忽略：true代表当格式转换错误时，忽略该值，被忽略后不会被存储和索引。
include_in_all	是否将该字段值组合到_all中。
null_value	默认控制替换值。如空字符串替换为”NULL”，空数字替换为-1
store	是否存储：默认为false。true意义不大，因为_source中已有数据
index	索引模式：analyzed (索引并分词，text默认模式), not_analyzed (索引不分词，keyword默认模式)，no（不索引）
analyzer	索引分词器：索引创建时使用的分词器，如ik_smart,ik_max_word,standard
search_analyzer	搜索分词器：搜索该字段的值时，传入的查询内容的分词器。
fields	多字段索引：当对该字段需要使用多种索引模式时使用。如：城市搜索New York "city": { "type": "text", "analyzer": "ik_smart", "fields": { "raw": { "type": "keyword" } } } 访问分词:city 访问不分词:city.raw 那么以后搜索过滤和排序就可以使用city.raw字段名

10、es如何保证高可用（对失败节点的数据进行复制）

对于分布式集群来说，当一个或多个节点down掉了，能够保证我们的数据不能丢，最通用的解放方案就是对失败节点的数据进行复制，通过控制复制的份数可以保证集群有很高的可用性，复制这个方案的精髓主要是保证操作的时候没有单点，对一个节点的操作会同步到其他的复制节点上去。
ES一个索引会拆分成多个碎片，每个碎片可以拥有一个或多个副本（创建索引的时候可以配置），这里有个例子，每个索引分成3个碎片，每个碎片有2个副本，如下：
```
$ curl -XPUT http://localhost:9200/twitter/ -d '
index :
    number_of_shards : 3
    number_of_replicas : 2
```

　　　默认是1个分片。不复制

11、es选举（和zk差不多，但是es支持1-N，zk的话必须是奇数）

节点启动后先ping（这里的ping是 Elasticsearch 的一个RPC命令。如果 discovery.zen.ping.unicast.hosts 有设置，则ping设置中的host，否则尝试ping localhost 的几个端口， Elasticsearch 支持同一个主机启动多个节点）
Ping的response会包含该节点的基本信息以及该节点认为的master节点
选举开始，先从各节点认为的master中选，规则很简单，按照id的字典序排序，取第一个
如果各节点都没有认为的master，则从所有节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举
最后选举结果是肯定能选举出一个master，如果只有一个local节点那就选出的是自己
如果当前节点是master，则开始等待节点数达到 minimum_master_nodes，然后提供服务, 如果当前节点不是master，则尝试加入master.
ES支持任意数目的集群（1-N）,所以不能像 Zookeeper/Etcd 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则，只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的. 但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题，大多数解决方案就是设置一个quorum值，要求可用节点必须大于quorum（一般是超过半数节点），才能对外提供服务。而 Elasticsearch 中，这个quorum的配置就是