Elasticsearch面试题

ElasticSearch中的集群、节点、索引、文档、类型是什么？
群集是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
搜索相关性
Elasticsearch 的相似度算法被定义为检索词频率/反向文档频率， TF/IDF ，包括以下内容：

检索词频率：检索词在该字段出现的频率？出现频率越高，相关性也越高。 字段中出现过 5 次要比只出现过 1 次的相关性高。
反向文档频率：每个检索词在索引中出现的频率？频率越高，相关性越低。检索词出现在多数文档中会比出现在少数文档中的权重更低。
字段长度准则：字段的长度是多少？长度越长，相关性越低。 检索词出现在一个短的 title 要比同样的词出现在一个长的 content 字段权重更大。
从ES 5开始，默认算法改为BM 25，和经典的TF-IDF相比，当TF无限增加时，BM 25算分会趋于一个数值

es分页查询
使用 from / size 分页
通过设置 index.max_result_window 可以修改分页限制，默认10000

原理：
Query阶段：
当一个请求发送到某个ES节点时，该节点（Node1）会根据from和size，建立一个结果集窗口，窗口大小为from+size。假如from=10000,size=100，则窗口大小为10100。
此节点将请求广播到其他相关节点上，从每个Shards中取Top 10100条的score和id。
所有Shards获取的结果汇聚到Node1，假如有5个Shards，则一共会取到5 * 10100 = 50500条数据。
Node1进行归并排序，并选择Top 10100条，存入结果集窗口。

Fetch阶段：
根据Query阶段得到的排序结果，从 from 位置取 size 条数据，抓取文档详细内容返回。

从此过程中可以看出，翻页越靠后，需要参与排序的文档就越多，效率也就越低。所以，如果结果集很大，不建议用这种分页方式。

使用 scroll 分页

相对于from和size的分页来说，使用scroll可以模拟一个传统数据的游标，记录当前读取的文档信息位置。这个分页的用法，不是为了实时查询数据，而是为了一次性查询大量的数据（甚至是全部的数据）。

因为这个scroll相当于维护了一份当前索引段的快照信息，这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到。但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取。
与 from/size 分页方式不同，使用 scroll 分页只能单向顺序翻页，不能随机翻页，适用于遍历结果集的场景。

scroll 翻页能够深度翻页，但是翻页期间需要维护“search context”，这是需要占用一定资源的。

所以对于用户高并发访问的场景，不推荐用这种方式，scroll 更适用于批处理类的后台任务。

使用 search after 分页
这种方式同样可以深度翻页，但是弥补了 scroll 方式的不足。其思想是：用前一次的查询结果作为下一次的查询条件。

总结：
如果数据量小（10000条内），或者只关注结果集的TopN数据，可以使用from / size 分页，简单粗暴
数据量大，深度翻页，后台批处理任务（数据迁移）之类的任务，使用 scroll 方式
数据量大，深度翻页，用户实时、高并发查询需求，使用 search after 方式

elasticsearch 怎么做数据建模
mapping 设计非常重要，需要从两个维度进行考虑：

功能：搜索、排序、聚合
性能：存储的开锁、内存的开销、搜索的性能

mapping 注意事项：

加入新字段很容易（必要时需要 update_by_query）
更新删除字段不允许（需要 reindex 重建数据）

最佳实践
1、不允许自动新增字段，将 dynamic 设置成 strict。默认为 true；
2、不需要分词的字段，将 type 设置成 keyword。默认使用了多字段特性，text、keyword这2种类型都有；
3、不需要检查的字段，将 index 设置成 false。默认为 true；
4、不需要排序和聚合的字段，将 doc_values 设置成false。默认为 true；
5、不需要检查、排序、聚合的字段，将 enable 设置成 false，仅做存储；
6、type = text 的字段，默认不可以排序，如需要排序，将 fielddata 设置成 true，默认为 false；
7、单个索引避免过多字段，默认最大值为1000；
8、避免空值引起的聚合不准确的问题；
9、避免使用正则查询；
10、尽量不要设计成索引关联，可冗余多一些字段，以空间换时间，如实在无法避免，按以下方式处理：

elasticsearch关联关系
nested parent/child join
优点 读取性能高 父子文档可以独立更新
缺点 每次更新需要更新整个文档 关联关系，需要额外的内存，查询效率相对较差
场景 频繁查询 频繁更新
1
2
3
4
elasticsearch 索引的副本和分片怎么设置
Elasticsearch 提供了优化好的默认配置。 除非你理解这些配置的作用并且知道为什么要去修改，否则不要随意修改。

number_of_shards
每个索引的主分片数，默认值是 5 。这个配置在索引创建后不能修改。

number_of_replicas
每个主分片的副本数，默认值是 1 。对于活动的索引库，这个配置可以随时修改。

elasticsearch的倒排索引是什么
会对每个文件分词，建立的是分词（Term）和文档（Document）之间的映射关系，在倒排索引中，数据是面向词（Term）而不是面向文档的

elasticsearch 索引数据多了怎么办，如何调优，部署
动态索引层面
基于模板+时间+rollover api滚动创建索引，举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳的形式，每天递增数据。

存储层面
冷热数据分离存储，热数据（比如最近3天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率。

elasticsearch是如何实现master选举的，脑裂问题
Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；
　　对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
　　如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

详细描述一下Elasticsearch索引文档的过程
第一步：客户写集群某节点写入数据，发送请求。
第二步：节点1接受到请求后，使用文档_id来确定文档属于分片0
第三步：节点3在主分片上执行写操作，如果成功，则将请求并行转发到节点1和节点2的副本分片上，等待结果返回
借助路由算法获取，路由算法就是根据路由和文档id计算目标的分片id的过程。
协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。
　　shard = hash(document_id) % (num_of_primary_shards)
　　当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem 　　Cache的过程就叫做refresh；
　　当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；
　　在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。
　　flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

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

详细描述一下Elasticsearch搜索的过程？
搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
　　在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。
　　每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
　　接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
　　补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。

在并发情况下，Elasticsearch 如果保证读写一致？
ES 数据并发冲突控制是基于的乐观锁和版本号的机制
es节点更新之后会向副本节点同步更新数据(同步写入)，直到所有副本都更新了才返回成功。
可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
　　另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
　　对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。