ES实用面试题

一、es是什么，为什么要用它？

ES通常是Elasticsearch的简称，它是一个基于Lucene构建的开源搜索引擎。Elasticsearch以其分布式、高扩展性和实时数据分析能力而闻名，广泛用于全文搜索、日志分析、实时监控等多种场景。

1. 基本特点：

   • 分布式：Elasticsearch支持分布式部署，能够在多个节点上运行，从而提供高可用性和可扩展性。
   • 高扩展性：Elasticsearch通过分片和副本机制实现高扩展性，可以根据需要动态增加或减少节点。
   • 实时数据分析能力：Elasticsearch支持实时数据分析，能够快速处理大规模数据并生成分析结果。

2. 数据模型：

   • Elasticsearch使用JSON作为文档序列化格式，支持结构化、半结构化甚至非结构化的数据，无需预定义严格的数据库模式。
   • 在Elasticsearch中，数据被存储在索引中，索引是其存储和搜索数据的基本单位。

3. 查询和分析API：

   • Elasticsearch提供了丰富的查询和分析API，支持全文搜索、结构化搜索和复合搜索等多种查询方式。
   • 通过这些API，用户可以实现复杂的数据查询和分析任务。

4. 应用场景：

   • 全文搜索：Elasticsearch适用于各种全文搜索场景，如网站搜索、文档搜索等。
   • 日志分析：Elasticsearch可以处理和分析大量日志数据，帮助开发人员和运维人员快速定位问题。
   • 实时监控：Elasticsearch支持实时监控功能，能够实时展示数据的变化趋势和异常情况。

二、es数据写入原理

1. 我们得知道es数据写入的原理，数据怎么流转的

（1）客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node （协调节点）

（2）coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）

（3）实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node

（4）coordinating node 等到 primary node 和所有 replica node 都执行成功之后，就返回响应结果给客户端。

1. 写数据的底层原理

（1）数据先写入 memory buffer，然后定时（默认每隔1s）将 memory buffer 中的数据写入一个新的 segment 文件中，并进入 Filesystem cache（同时清空 memory buffer），这个过程就叫做 refresh；

ES 的近实时性：数据存在 memory buffer 时是搜索不到的，只有数据被 refresh 到  Filesystem cache 之后才能被搜索到，而 refresh 是每秒一次， 所以称 es 是近实时的，可以通过手动调用 es 的 api 触发一次 refresh 操作，让数据马上可以被搜索到；

（2）由于 memory Buffer 和 Filesystem Cache 都是基于内存，假设服务器宕机，那么数据就会丢失，所以 ES 通过 translog 日志文件来保证数据的可靠性，在数据写入 memory buffer 的同时，将数据写入 translog 日志文件中，在机器宕机重启时，es 会自动读取 translog 日志文件中的数据，恢复到 memory buffer 和 Filesystem cache 中去。

ES 数据丢失的问题：translog 也是先写入 Filesystem cache，然后默认每隔 5 秒刷一次到磁盘中，所以默认情况下，可能有 5 秒的数据会仅仅停留在 memory buffer 或者 translog 文件的 Filesystem cache中，而不在磁盘上，如果此时机器宕机，会丢失 5 秒钟的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

（3）flush 操作：不断重复上面的步骤，translog 会变得越来越大，当 translog 文件默认每30分钟或者 阈值超过 512M 时，就会触发 commit 操作，即 flush操作。

将 buffer 中的数据 refresh 到 Filesystem Cache 中去，清空 buffer；
创建一个新的 commit point（提交点），同时强行将 Filesystem Cache 中目前所有的数据都 fsync 到磁盘文件中；
删除旧的 translog 日志文件并创建一个新的 translog 日志文件，此时 commit 操作完成

 三、平时遇到的问题

1. ES在高并发下如何保证读写一致性？

（1）对于更新操作：可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖

每个文档都有一个_version 版本号，这个版本号在文档被改变时加一。Elasticsearch使用这个 _version 保证所有修改都被正确排序。当一个旧版本出现在新版本之后，它会被简单的忽略。

利用_version的这一优点确保数据不会因为修改冲突而丢失。比如指定文档的version来做更改。如果那个版本号不是现在的，请求就失败了。

（2）对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

one：
 要求我们这个写操作，只要有一个primary shard是active活跃可用的，就可以执行

all：
 要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作

quorum：
 默认的值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作

（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。

12、ES如何选举Master节点
12.1、Elasticsearch 的分布式原理
Elasticsearch 会对存储的数据进行切分，将数据划分到不同的分片上，同时每一个分片会保存多个副本，主要是为了保证分布式环境的高可用。在 Elasticsearch 中，节点是对等的，节点间会选取集群的 Master，由 Master 负责集群状态信息的改变，并同步给其他节点。

12.2、Elasticsearch 的写入性能会不会很低？
只有建立索引和类型需要经过 Master，数据的写入有一个简单的 Routing 规则，可以路由到集群中的任意节点，所以数据写入压力是分散在整个集群的。

1. Elasticsearch 如何选举 Master？

Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和 Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；

确认候选主节点的最少投票通过数量，elasticsearch.yml 设置的值 
        discovery.zen.minimum_master_nodes;

对所有候选 master 的节点（node.master: true）根据 nodeId 字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
如果对某个节点的投票数达到阈值，并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

Elasticsearch是如何避免脑裂现象？

（1）当集群中 master 候选节点数量不小于3个时（node.master: true），可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes），设置超过所有候选节点一半以上来解决脑裂问题，即设置为 (N/2)+1；

（2）当集群 master 候选节点 只有两个时，这种情况是不合理的，最好把另外一个node.master改成false。如果我们不改节点设置，还是套上面的(N/2)+1公式，此时discovery.zen.minimum_master_nodes应该设置为2。这就出现一个问题，两个master备选节点，只要有一个挂，就选不出master了

建立索引阶段性能提升方法

（1）使用 SSD 存储介质

（2）使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。

（3）如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0 关闭副本

（4）如果你的搜索结果不需要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到30s

（5）段和合并：Elasticsearch 默认值是 20 MB/s。但如果用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。

（6）增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB

ES的深度分页与滚动搜索scroll

（1）深度分页：

深度分页其实就是搜索的深浅度，比如第1页，第2页，第10页，第20页，是比较浅的；第10000页，第20000页就是很深了。搜索得太深，就会造成性能问题，会耗费内存和占用cpu。而且es为了性能，他不支持超过一万条数据以上的分页查询。

那么如何解决深度分页带来的问题，我们应该避免深度分页操作（限制分页页数），比如最多只能提供100页的展示，从第101页开始就没了，毕竟用户也不会搜的那么深。

（2）滚动搜索：

一次性查询1万+数据，往往会造成性能影响，因为数据量太多了。这个时候可以使用滚动搜索，也就是 scroll。滚动搜索可以先查询出一些数据，然后再紧接着依次往下查询。

在第一次查询的时候会有一个滚动id，相当于一个锚标记 ，随后再次滚动搜索会需要上一次搜索滚动id，根据这个进行下一次的搜索请求。每次搜索都是基于一个历史的数据快照，查询数据的期间，如果有数据变更，那么和搜索是没有关系的。

你能否列出与 Elasticsearch 有关的主要可用字段数据类型？
字符串数据类型，包括支持全文检索的 text 类型 和 精准匹配的 keyword 类型。
数值数据类型，例如字节，短整数，长整数，浮点数，双精度数，half_float，scaled_float。
日期类型，日期纳秒Date nanoseconds，布尔值，二进制（Base64编码的字符串）等。
范围（整数范围 integer_range，长范围 long_range，双精度范围 double_range，浮动范围 float_range，日期范围 date_range）。
包含对象的复杂数据类型，nested 、Object。
GEO 地理位置相关类型。
特定类型如：数组（数组中的值应具有相同的数据类型）

请解释有关 Elasticsearch的 NRT？

从文档索引（写入）到可搜索到之间的延迟默认一秒钟，因此Elasticsearch是近实时（NRT）搜索平台。

也就是说：文档写入，最快一秒钟被索引到，不能再快了。

写入调优的时候，我们通常会动态调整：refresh_interval = 30s 或者更达值，以使得写入数据更晚一点时间被搜索到。

Elasticsearch Analyzer 中的字符过滤器如何利用？

字符过滤器将原始文本作为字符流接收，并可以通过添加，删除或更改字符来转换字符流。

字符过滤分类如下：

HTML Strip Character Filter.
用途：删除HTML元素，如，并解码HTML实体，如＆amp 。

Mapping Character Filter
用途：替换指定的字符。

Pattern Replace Character Filter
用途：基于正则表达式替换指定的字符。

精准匹配检索和全文检索匹配检索的不同？

两者的本质区别：

精确匹配用于：是否完全一致？
举例：邮编、身份证号的匹配往往是精准匹配。

全文检索用于：是否相关？
举例：类似B站搜索特定关键词如“马保国 视频”往往是模糊匹配，相关的都返回就可以。

请解释一下 Elasticsearch 中的聚合？

聚合有助于从搜索中使用的查询中收集数据，聚合为各种统计指标，便于统计信息或做其他分析。聚合可帮助回答以下问题：

我的网站平均加载时间是多少？
根据交易量，谁是我最有价值的客户？
什么会被视为我网络上的大文件？
每个产品类别中有多少个产品？
聚合的分三类：

主要查看7.10 的官方文档，早期是4个分类！

分桶 Bucket 聚合
根据字段值，范围或其他条件将文档分组为桶（也称为箱）。

指标 Metric 聚合
从字段值计算指标（例如总和或平均值）的指标聚合。

管道 Pipeline 聚合
子聚合，从其他聚合（而不是文档或字段）获取输入。

Elasticsearch 支持哪些类型的查询？

查询主要分为两种类型：精确匹配、全文检索匹配。

精确匹配，例如 term、exists、term set、 range、prefix、 ids、 wildcard、regexp、 fuzzy等。
全文检索，例如match、match_phrase、multi_match、match_phrase_prefix、query_string 等。

解释 Elasticsearch 中的相关性和得分？

当你在互联网上搜索有关 Apple 的信息时。它可以显示有关水果或苹果公司名称的搜索结果。

你可能要在线购买水果，检查水果中的食谱或食用水果，苹果对健康的好处。
你也可能要检查Apple.com，以查找该公司提供的最新产品范围，检查评估公司的股价以及最近6个月，1或5年内该公司在纳斯达克的表现。
同样，当我们从 Elasticsearch 中搜索文档（记录）时，你会对获取所需的相关信息感兴趣。基于相关性，通过Lucene评分算法计算获得相关信息的概率。

ES 会将相关的内容都返回给你，只是：计算得出的评分高的排在前面，评分低的排在后面。

计算评分相关的两个核心因素是：词频和逆向文档频率（文档的稀缺性）。

大体可以解释为：单篇文档词频越高、得分越高；多篇文档某词越稀缺，得分越高。

解释一下 Elasticsearch 的 分片？

当文档数量增加，硬盘容量和处理能力不足时，对客户端请求的响应将延迟。

在这种情况下，将索引数据分成小块的过程称为分片，可改善数据搜索结果的获取。

定义副本、创建副本的好处是什么？

副本是 分片的对应副本，用在极端负载条件下提高查询吞吐量或实现高可用性。

所谓高可用主要指：如果某主分片1出了问题，对应的副本分片1会提升为主分片，保证集群的高可用。

请解释在 Elasticsearch 集群中添加或创建索引的过程？

要添加新索引，应使用创建索引 API 选项。创建索引所需的参数是索引的配置Settings，索引中的字段 Mapping 以及索引别名 Alias。

也可以通过模板 Template 创建索引。

Elasticsearch各个版本特性

Elasticsearch 5

首先说明下，ES是从版本2直接跳到5的，主要是为了和Elastic Stack其他组件保持版本一致

ES5，在现在来说是比较老的版本了，就不多介绍了

建议大家使用ES7，或者直接使用ES8

Elasticsearch 6.0

移除type，在 6.0 里面，开始不支持一个 index 里面存在多个 type 了，所有的新的 index 都将只有一个虚拟的固定的 type： doc 来代替

稀疏性 Doc Values 的支持， es 的 doc values 是列式存储，文档的原始值都是存放在 doc values 里面的，优化了一个文档有的字段其他文档的持有开销

Index sorting，即在索引阶段的排序支持，索引的时候会要增加额外开销，适合不怎么变化的索引的场景。

已经关闭的索引将也支持 replica 的自动处理，确保数据可靠

Load aware shard routing， 基于负载的请求路由，目前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现方式将基于队列的耗费时间自动调节队列长度，负载高的节点的队列长度将减少，让其他节点分摊更多的压力，搜索和索引都将基于这种机制。

顺序号的支持，每个 es 的操作都有一个顺序编号（类似增量设计）无缝滚动升级

Elasticsearch 7.0

ES 数据库的存储结构变化：去除了Type，包括API层面

默认配置变化：默认节点名称为主机名，默认分片数为1，不再是5

查询相关速度优化：Weak-AND算法。又称为Wand算法， 输入是n个倒排队列，输出top K个得分最高的文档doc，weak-and算法通过计算每个词的贡献上限来估计文档的相关性上限，从而建立一个阈值对倒排中的结果进行减枝，从而得到提速的效果。

彻底废除 _all 字段的支持，为提升性能默认不在支持全文检索

集群连接变化：TransportClient被废弃，对于java编程，建议采用 High-level-rest-client 的方式

ES程序包默认打包jdk：以至于7.x版本的程序包大小突然边300MB+

间隔查询(Intervals queries)，Elasticsearch 7.0中的间隔查询引入了一种构建“单词或短语彼此相距一定距离的记录查询”的需要的全新方式，与之前的方法（跨度查询span queries）相比，使用和定义更加简单。

函数分数 2.0，通过新的模块化结构，用户能够混合和匹配一组算术和距离函数，从而构建任意的函数分数计算方式，进而在更大程度上控制结果的评分和排名方式。

引入新的集群协调子系统，移除 minimum_master_nodes 参数，让 Elasticsearch 自己选择可以形成仲裁的节点。

典型的主节点选举现在只需要很短的时间就可以完成。集群的伸缩变得更安全、更容易，并且可能造成丢失数据的系统配置选项更少了。 节点更清楚地记录它们的状态，有助于诊断为什么它们不能加入集群或为什么无法选举出主节点。

不再内存溢出，新的 Circuit Breaker 在JVM 堆栈层面监测内存使用，Elasticsearch 比之前更加健壮。设置indices.breaker.fielddata.limit的默认值已从JVM堆大小的60％降低到40％。

支持达到纳秒级精度，强化时序型用例

Lucene9.0的支持

7.1开始，Security功能免费使用

Elasticsearch 8.0

lastic 8.0 版通过改进 Elasticsearch 的矢量搜索功能、对现代自然语言处理模型的原生支持、不断简化的数据上线过程，以及精简的安全防护体验，在速度、扩展幅度、相关性和简便性方面，迎来了一个全新的时代。需要 Java 17 才能运行 Elasticsearch。

Elastic 8.0 版是基于 Lucene 9.0 开发的，那些利用现代 NLP 的搜索体验，都可以借助（新增的）对近似最近邻搜索的原生支持，快速且大规模地实现。通过 ANN，可以快速并高效地将基于矢量的查询与基于矢量的文档语料库（无论是小语料库、大语料库还是巨型语料库）进行比较。

重要更新

Rest API相比较7.x而言做了比较大的改动（比如彻底删除_type），为了降低用户的升级成本，8.x会暂时的兼容7.x的请求。

默认开启安全配置（三层安全），并极大简化了开启安全需要的工作量，可以这么说：7.x开启安全需要10步复杂的步骤比如CA、证书签发、yml添加多个配置等等，8.x只需要一步即可）。

存储空间优化：更新了倒排索引，对倒排文件使用新的编码集，对于keyword、match_only_text、text类型字段有效，有3.5%的空间优化提升，对于新建索引和segment自动生效。

优化geo_point，geo_shape类型的索引（写入）效率：15%的提升。

新特性：支持上传pyTorch模型，在ingest的时候使用。比如在写入电影评论的时候，如果我们想要知道这个评论的感情正负得分，可以使用对应的AI感情模型对评论进行运算，将结果一并保存在ES中。

技术预览版KNN API发布，（K邻近算法），跟推荐系统、自然语言排名相关。之前的KNN是精确搜索，在大数据集合的情况会比较慢，新的KNN提供近似KNN搜索，以提高速度。

对ES内置索引的保护加强了：elastic用户默认只能读，如果需要写权限的时候，需有allow_restrict_access权限。