JAVA面试题--ES

ElasticSearch

Lucene创建索引原理

Lucene是基于倒排索引原理来实现的

首先，将原文档进行分词处理，形成一个个单独的单词，
然后取出标点符号以及停词，形成词元，
再将词元做一些语言相关的处理，比如变成小写，转换时态，单复数形式等等，
将得到的词创建一个字典，按照字母顺序排序，合并相同的词，最终生成一个倒排索引文档

ES的keyword和text区别

keyword：不分词，直接建立索引，支持模糊查询，精确查询，聚合查询

text：分词后建立索引，支持模糊查询，精确查询，不支持聚合查询

keyword通常用于通常用于存储年龄，性别，邮编，邮箱号码等等，直接将完整数据保存的场景

text通常存储全文搜索的数据，例如地址，文章内容的保存

ES的优势

ES是基于Lucene的开源搜索引擎，它解决了原生Lucene使用的不足，优化了Lucene的调用方式

分布式的实时文件存储，每个字段都被索引并可被搜索
支持实时分析搜索
可以扩展到上百台服务器，处理PB级结构化或非结构化数据
通过简单的 RESTful API、可以跟各种语言的客户端甚至命令行进行交互
上手非常容易，只需很少的学习就可以在生产环境中使用

Lucene/ES为什么那么快(ES用到什么数据结构)

传统搜索比如mysql的like关键字查询，它的搜索方式就是全文扫表，查询性能很低

ES是基于Lucene的全文检索引擎，它采用的是倒排索引结构，在存储时先对文档进行分词，再做一些标点符号去除，大小写时态转换等优化处理，最后按照字母顺序去重排序，形成一个倒排索引文档，我们在检索时，就可以通过二分查找的方式找到目标值

ES的分层结构，index下面是什么

Index：索引库，包含有一堆相似结构的文档数据，类比Mysql中的数据库

Type：类型，它是index中的一个逻辑数据分类，类比Mysql中的表

Document：文档：是ES中的最小数据单元，通常用json结构标识，类比Mysql中的一行数据

Field：字段：类比Mysql中的一个列

从ES7.0开始，Type被干掉了，从此库表合一即一个Index中只有一个默认的Type

讲几个ES中的查询对象：比如TermQuery

TermQuery：匹配关键字查询（关键词不分词）

MatchQuery：匹配关键字查询（关键字分词后）

BooleanQuery：按条件查询

matchAllQuery：匹配所有文档查询

rangeQuery：查询指定范围内的数据

你简单描述一下DSL语法

DSL是一种以json形式标识的，由ES提供的一种查询语言，它由两部分组成，DSL查询和DSL过滤。

DSL查询类似于模糊查询，DSL过滤类似于精确查询

你说一下 match和term的区别？

term：不会对搜索词进行分词处理，而是作为一个整体与目标字段进行匹配，若完全匹配，则可查询到

match：会将搜索词分词，再与目标查询字段进行匹配，若分词中的任意一个词与目标字段匹配上，则可查询到

你使用过ES的哪些聚合查询？

指标聚合，比如求和，求最大值，最小值，平均数

x，计算满足条件数据的总条数，相当于sql中的count

去重聚合，它会计算非重复的数据个数，相当于sql中的distinct

桶聚合，它会将某个field的每个唯一值当成一个桶，并计算每个桶内的文档个数，相当于sql中的group by

最高权值聚合，它会匹配每组前n条数据，相当于sql中的group by后取出前n条

ES高亮怎么做的？

使用HighlightBuilder对关键字作高亮处理，由于我们项目使用的是SpringBoot整合ES的jar包，结果没有进行高亮处理，我们使用ElasticsearchTemplate的queryForPage方法来获取结果，再手动进行分页封装返回前台

你们ES和数据库的数据一致性怎么做的

代码控制的，数据库做了写操作，直接更新ES中的数据，我知道可以通过 Logstash 中数据和ES的数据自动同步。

还可以通过可靠消息最终一致性

ES分片机制了解吗

ES的索引库由多个分片 shard组成，shard分为primary shard主shad和replica shard 副本,主shard承担写请求，replica副本的数据从primary复制而来，同时分担读请求，primary shard的数量设定了就不能修改，replica数量可以修改。

描述一下ES添加文档的过程

(1) 客户端请求一个协调节点coordinating node

(2) 协调节点根据算法选择一个primary shard: 算法 hash(document_id) % (num_of_primary_shards)

(3) 对应的primary shard 所在节点保存完数据后，将数据同步到replica node。

(4) 协调节点coordinating node 发现 primary node 和所有 replica node 都搞定之后返回结果给客户端

数据节点存储数据详细流程：

(1) 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh

(2) 当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；

(3)在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。 flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

详细描述一下Elasticsearch获取文档的过程

(1) 客户端请求一个协调节点coordinating node

(2) coordinate node 根据算法hash(document_id) % (num_of_primary_shards)，将请求转发到对应的 node，此时会使用 round-robin随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡

(3) 接收到请求的 node 返回 document 给调节点 coordinate node。

(4) coordinate node 返回 document 给客户端。

搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；

详细描述一下Elasticsearch搜索过程

(1) 在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。

(2) 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。

(3) 每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，协调节点它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

(4) 接下来就是取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

详细描述一下Elasticsearch更新和删除文档的过程

删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；　磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。

在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。