elasticsearch常见面试题

1、为什么使用es？
因为数据非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引导致全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，将经常查询的字段放入我们索引库里，可以提高查询速度。
2、实现es的Master选举的？
(1)es的选主是ZenDiscovery模块负责的，主要包含Ping(节点之间通过这个RPC来发现彼此)和Unicast(单播模块包含一个主机列表以控制哪些节点需要ping通)这两部分；
配置文件elasticsearch.yml
discovery.zen.ping.unicast.hosts: [“Hadoop.master”, “Hadoop.slave1”, “Hadoop.slave2”]
(2) 对所有可以成为master的节点(node.master:true)根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个(第0位)节点，暂且认为它是master节点。
配置文件elasticsearch.yml node.master: true
(3)如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
3、解决es脑裂问题
(1) 当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；
配置文件elasticsearch.yml discovery.zen.minimum_master_nodes: 2
(2) 当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。
4、详述Elasticsearch索引文档的过程
(1) 协调节点默认使用文档ID参与计算(也支持通过routing),以便为路由提供合适的分片。
shard = hash(document_id) % (num_of_primary_shards)
(2) 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh；
(3) 当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；
(4) 在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。
(5) flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；
4、详述Elasticsearch更新和删除文档的过程
(1) 删除和更新都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更;
(2) 磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。
(3)新文档创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
5、详述Elasticsearch搜索的过程
(1)搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
(2) 在初始查询阶段时，查询会广播到索引中每一个分片拷贝(主分片或者副本分片). 每个分片在本地执行搜索并构建一个匹配文档的大小为from+size的优先队列。在搜索的时候是会查询Filesystem Cache的，但有部分数据还在Memory Buffer，所以搜索是近实时的。
(3) 每个分片返回各自优先队列中,所有文档的ID和排序值给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
(4) 接下来就是取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
(5) 补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。
7.Elasticsearch在部署时，对Linux的设置有哪些优化方法？
64GB内存的机器是非常理想的,但是32 GB和16GB机器也是很常见的。少于8 GB会适得其反。
如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
如果你负担得起SSD,它将远远超出任何旋转介质.基于SSD的节点，查询和索引性能都有提升。如果你负担得起，SSD是一个好的选择。
即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
请确保运行你应用程序的JVM和服务器的JVM是完全一样的. 在Elasticsearch的几个地方，使用 Java 的本地序列化。
通过设置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。
Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群.只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。
不要随意修改垃圾回收器（CMS）和各个线程池的大小。
把你的内存的(少于）一半给 Lucene(但不要超过32GB)，通过ES_HEAP_SIZE 环境变量设置。
内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成10毫秒.再想想那么多10微秒的操作时延累加起来. 不难看出 swapping 对于性能是多么可怕。
Lucene 使用了大量的文件。同时Elasticsearch在节点和HTTP客户端之间进行通信也使用了大量的套接字.所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。
补充：索引阶段性能提升方法
使用批量请求并调整其大小:每次批量数据5–15MB是个不错的起始点。
存储：使用 SSD
段和合并：Elasticsearch 默认值是20MB/s,对机械磁盘应该是个不错的设置.如果你用的是SSD,可以考虑提高到100–200MB/s.如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 index.translog.flush_threshold_size 设置，从默认的512MB到更大一些的值，比如1GB,这可以在一次清空触发的时候在事务日志里积累出更大的段。
如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval 改到30s。
如果你在做大批量导入,考虑通过设置index.number_of_replicas: 0关闭副本。
8.对于GC方面，在使用Elasticsearch时要注意什么？
SEE：https://elasticsearch.cn/article/32
倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。
各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。
避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api来实现。
cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。
想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。
9.Elasticsearch对于大数据量（上亿量级）的聚合如何实现？
Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关 .
10.在并发情况下，Elasticsearch如果保证读写一致？
可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。
11.如何监控Elasticsearch集群状态？
Marvel让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标
12.是否了解字典树？
常用字典数据结构如下所示：
Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质：
根节点不包含字符，除根节点外每一个节点都只包含一个字符。
从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
每个节点的所有子节点包含的字符都不相同。
可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。
实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树；
对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度O(1)。

13.ElasticSearch中的集群、节点、索引、文档、类型是什么？
集群是一个或多个节点(服务器)的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。集群由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入集群，则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
类型是索引的逻辑类别/分区，其语义完全取决于用户。
14.ElasticSearch中的分片是什么?
在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。
索引 - 在Elasticsearch中，索引是文档的集合。
分片 -因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素。

15、在 Elasticsearch 中，是怎么根据一个词找到对应的倒排索引的？
（1）Lucene的索引过程，就是按照全文检索的基本过程，将倒排表写成此文件格式的过程。
（2）Lucene的搜索过程，就是按照此文件格式将索引进去的信息读出来，然后计算每篇文档打分(score)的过程。
16、客户端在和集群连接时，如何选择特定的节点执行请求的？
TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址，并以 轮询 的方式与这些地址进行通信。
17、Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法
解答：
（1）关闭缓存 swap;
（2）堆内存设置为：Min（节点内存/2, 32GB）;
（3）设置最大文件句柄数；
（4）线程池+队列大小根据业务需要做调整；
（5）磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单节点存储故障。
18、lucence 内部结构是什么？

Lucene 是有索引和搜索的两个过程，包含索引创建，索引，搜索三个要点。可以基于这个脉络展开一些。
1、elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段 。
面试官：想了解应聘者之前公司接触的 ES 使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。
解答：如实结合自己的实践场景回答即可。
比如：ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，每日递增 20+，索引：10 分片，每日递增 1 亿+数据，每个通道每天索引大小控制：150GB 之内。
仅索引层面调优手段：
1.1、设计阶段调优
（1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
（2）使用别名进行索引管理；
（3）每天凌晨定时对索引做 force_merge 操作，以释放空间；
（4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；
（5）采取 curator 进行索引的生命周期管理；
（6）仅针对需要分词的字段，合理的设置分词器；
（7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。………
1.2、写入调优
（1）写入前副本数设置为 0；
（2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
（3）写入过程中：采取 bulk 批量写入；
（4）写入后恢复副本数和刷新间隔；
（5）尽量使用自动生成的 id。
1.3、查询调优
（1）禁用 wildcard；
（2）禁用批量 terms（成百上千的场景）；
（3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；
（4）数据量大时候，可以先基于时间敲定索引再检索；
（5）设置合理的路由机制。
1.4、其他调优
部署调优，业务调优等。
上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。
2、elasticsearch 的倒排索引是什么
解答：通俗解释一下就可以。
传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。
而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了倒排索引，就能实现 o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。

学术的解答方式：
倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。
加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。
lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：
（1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
（2）查询速度快。O(len(str))的查询时间复杂度。