IT评测·应用市场-qidao123.com

标题: 2023最新整理的 Elasticsearch 21道口试题 [打印本页]

---

作者: 慢吞云雾缓吐愁    时间: 2024-7-31 03:08
标题: 2023最新整理的 Elasticsearch 21道口试题
1、为什么要使用 Elasticsearch?

   系统中的数据， 随着业务的发展， 时间的推移， 将会非常多，而业务中每每采用模糊查询进行数据的 搜刮，而模糊查询会导致查询引擎放弃索引， 导致系统查询数据时都是全表扫描，在百万级别的数据库中， 查询服从黑白常低下的，而我们使用 ES 做一个全文索引， 将经常查询的系统功能的某些字段，比如说电 商系统的商品表中商品名，形貌、价格另有 id 这些字段我们放入 ES 索引库里，可以进步查询速度。
  2、Elasticsearch 的 master 推举流程？

   

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

  3、Elasticsearch 集群脑裂题目？

   所谓脑裂题目（类似于精神分裂），就是同一个集群中的不同节点，对于集群的状态有了不一样的明白。
  由于某些节点的失效，部门节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况成为集群脑裂（split-brain）现象。这个题目非常伤害，因为两个新形成的集群会同时索引和修改集群的数据。
  “脑裂”题目大概的成因：

• 网络题目：集群间的网络延迟导致一些节点访问不到 master，认为 master 挂掉了从而推举出新的master，并对 master 上的分片和副本标红，分配新的主分片
  
• 节点负载：主节点的脚色既为 master 又为 data，访问量较大时大概会导致 ES 制止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
  
• 内存回收：data 节点上的 ES 进程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 进程失去响应
  

脑裂题目解决方案：

• 减少误判： discovery.zen.ping_timeout 节点状态的响应时间， 默认为 3s，可以得当调大，假如 master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数(如 6s ， discovery.zen.ping_timeout:6 ) ，可得当减少误判。
  
• 推举触发: discovery.zen.minimum_master_nodes:1，该参数是用于控制推举行为发生的最小集群主节点数量。当备选主节点的个数大于即是该参数的值， 且备选主节点中有该参数个节点认为主节点挂了， 进行推举。官方建议为(n/2) +1，n 为主节点个数 (即有资格成为主节点的节点个数)
  
• 脚色分离：即 master 节点与data 节点分离，限制脚色
  
  
  
  • 主节点配置为： node.master: true node.data: false
    
  • 从节点配置为： node.master: false node.data: true
    
  
  

4、文档索引步调次序是什么？

   新建单个文档所必要的步调次序：
  

  客户端向 Node 1 发送新建、索引或者删除请求。
  节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的主分片现在被分配在 Node 3 上。
  Node 3 在主分片上面实行请求。假如成功了，它将请求并行转发到 Node 1 和 Node 2 的副天职片上。一旦所有的副天职片都报告成功, Node 3 将向和谐节点报告成功，和谐节点向客户端报告成功。
  5、Elasticsearch 索引文档的流程？

• 和谐节点默认使用文档ID参与盘算（也支持通过routing），以便为路由提供符合的分片。
  

1. 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）时。
  

6、 Elasticsearch 更新和删除文档的流程？

   

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

  7、Elasticsearch 搜刮的流程？

   

• 搜刮被实行成一个两阶段过程，我们称之为 Query Then Fetch；
  
• 在初始查询阶段时，查询会广播到索引中每一个分片拷贝(主分片或者副天职片) 。 每个分片在本地实行搜刮并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜刮的时间是会查询 Filesystem Cache 的，但是有部门数据还在 Memory Buffer，所以搜刮是近及时的。
  
• 每个分片返回各自优先队列中 所有文档的 ID 和排序值 给和谐节点， 它归并这些值到自己的优先队列中来产生一个全局排序后的效果列表。
  
• 接下来就是取回阶段， 和谐节点辨别出哪些文档必要被取回并向相干的分片提交多个 GET 请求。每个分片加载并丰富文档，假如有必要的话，接着返回文档给和谐节点。一旦所有的文档都被取回了， 和谐节点返回效果给客户端。
  
• Query Then Fetch 的搜刮范例在文档相干性打分的时间参考的是天职片的数据，如许在文档数量较少的时间大概不敷精确， DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更精确， 但是性能会变差。
  

  8、GC 方面，在使用 Elasticsearch 时要留意什么？

   

• 倒排辞书的索引必要常驻内存，无法 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 在部署时，对 Linux 的设置有哪些优化方法？

   

• 64 GB 内存的呆板黑白常抱负的， 但是 32 GB 和 16 GB 呆板也是很常见的。少于 8 GB 会适得其反。
  
• 假如你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远赛过稍微快一点点的时钟频率。
  
• 假如你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点， 查询和索引性能都有提拔。假如你负担得起， SSD 是一个好的选择。
  
• 纵然数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理间隔。
  
• 请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在 Elasticsearch 的几个地方，使用 Java 的本地序列化。
  
• 通过设置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重启的时间避免过多的分片交换，这大概会让数据恢复从数个小时紧缩为几秒钟。
  
• Elasticsearch 默认被配置为使用单播发现，以防止节点偶然中到场集群。只有在同一台呆板上运行的节点才会自动组成集群。最好使用单播代替组播。
  
• 不要随意修改垃圾回收器(CMS)和各个线程池的大小。
  
• 你的内存的(少于) 一半给 Lucene (但不要超过 32 GB！) ，通过 ES_HEAP_SIZE 环境变量设置。
  
• 内存交换到磁盘对服务器性能来说是致命的。假如内存交换到磁盘上，一个 100 微秒的操作大概变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不丢脸出 swapping 对于性能是多么可怕。
  
• Lucene 使用了大量的文件。同时， Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这齐备都必要充足的文件形貌符。你应该增加你的文件形貌符， 设置一个很大的值，如 64,000。
  

  10、索引阶段性能提拔方法有哪些？

   

• 使用批量请求并调解其大小：每次批量数据 5 – 15 MB 大是个不错的起始点。
  
• 存储：使用 SSD
  
• 段和归并： Elasticsearch 默认值是 20 MB/s，对呆板磁盘应该是个不错的设置。假如你用的是 SSD，可以思量进步到 100 –200 MB/s。假如你在做批量导入， 完全不在意搜刮， 你可以彻底关掉归并限流。 别的还可以增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB ，这可以在一次清空触发的时间在事务日记里积聚出更大的段。
  
• 假如你的搜刮效果不必要近及时的精确度，思量把每个索引的 index.refresh_interval 改到 30s。
  
• 假如你在做大批量导入，思量通过设置 index.number_of_replicas: 0 关闭副本。
  

  11、elasticsearch 相识多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段 。

   口试官：想相识应聘者之前公司打仗的 ES 使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。
  解答：如实联合自己的实践场景回答即可。
  比如：ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，逐日递增 20+，索引：10分片，逐日递增 1 亿+数据，每个通道每天索引大小控制：150GB 之内。
  仅索引层面调优手段：
  设计阶段调优

• 根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
  
• 使用别名进行索引管理；
  
• 每天凌晨定时对索引做 force_merge 操作，以开释空间；
  
• 采取冷热分离机制，热数据存储到 SSD，进步检索服从；冷数据定期进行 shrink操作，以缩减存储；
  
• 采取 curator 进行索引的生命周期管理；
  
• 仅针对必要分词的字段，合理的设置分词器；
  
• Mapping 阶段充实联合各个字段的属性，是否必要检索、是否必要存储等。………
  

写入调优

• 写入前副本数设置为 0；
  
• 写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
  
• 写入过程中：采取 bulk 批量写入；
  
• 写入后恢复副本数和刷新间隔；
  
• 只管使用自动生成的 id。
  

查询调优

• 禁用 wildcard；
  
• 禁用批量 terms（成百上千的场景）；
  
• 充实利用倒排索引机制，能 keyword 范例只管 keyword；
  
• 数据量大时间，可以先基于时间敲定索引再检索；
  
• 设置合理的路由机制
  

12、Elasticsearch 对于大数据量(上亿量级) 的聚合怎样实现？

   Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数，即该字段的 distinct 或者 unique 值的数目。它是基于 HLL 算法的。 HLL 会先对我们的输入作哈希运算，然后根据哈希运算的 效果中的 bits 做概率估算从而得到基数。其特点是： 可配置的精度， 用来控制内存的使用(更精确 ＝ 更 多内存)；小的数据集精度黑白常高的；我们可以通过配置参数，来设置去重必要的固定内存使用量。无 论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相干
  13、在并发情况下，Elasticsearch 假如保证读写一致？

   

• 可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理详细的辩论；
  
• 对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但纵然大多数可用， 也大概存在因为网络等原因导致写入副本失败， 如许该副本被认为故 障，分片将会在一个不同的节点上重修。
  
• 对于读操作， 可以设置 replication 为 sync(默认)，这使得操作在主分片和副天职片都完成后才会返回；假如设置 replication 为 async 时，也可以通过设置搜刮请求参数_preference 为 primary 来查询主分片， 确保文档是最新版本。
  

  14、怎样监控 Elasticsearch 集群状态？

   elasticsearch-head 插件
通过 Kibana 监控 Elasticsearch。你可以及时检察你的集群健康状态和性能， 也可以分析过去的集群、 索引和节点指标
  15、是否相识字典树？

常用字典数据布局如下所示:

   字典树又称单词查找树， Trie 树，是一种树形布局，是一种哈希树的变种。典范应用是用于统计， 排序和保存大量的字符串 (但不仅限于字符串) ，所以经常被搜刮引擎系统用于文本词频统计。
  它的优点是：利用字符串的公共前缀来减少查询时间，最大限度地减少无谓的字符串比较，查询服从比哈希树高。
  Trie 的核心头脑是空间换时间，利用字符串的公共前缀来低落查询时间的开销以达到进步服从的目的。
  它有 3 个基天性质:
  

• 根节点不包罗字符，除根节点外每一个节点都只包罗一个字符
  
• 从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串
  
• 每个节点的所有子节点包罗的字符都不相同。
  

  对于中文的字典树，每个节点的子节点用一个哈希表存储， 如许就不用浪费太大的空间， 而且查询速度上 可以保留哈希的复杂度 O(1)。
  16、 Elasticsearch 中的集群、节点、索引、文档、范例是什么？

   

• 集群是一个或多个节点(服务器) 的聚集， 它们共同保存您的整个数据， 并提供跨所有节点的联合索引和搜刮功能。群集由唯一名称标识， 默认情况下为“elasticsearch”。此名称很紧张， 因为假如节点设 置为按名称到场群集，则该节点只能是群集的一部门。
  
• 节点是属于集群一部门的单个服务器。它存储数据并参与群集索引和搜刮功能。
  
• 索引就像关系数据库中的“数据库”。它有一个定义多种范例的映射。索引是逻辑名称空间， 映射到一个或多个主分片，并且可以有零个或多个副天职片。 MySQL =>数据库 Elasticsearch =>索引
  
• 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的布局(字段) ，但是对于通用字段应该具有相同的数据范例。 MySQL => Databases => Tables => Columns / Rows Elasticsearch => Indices => Types =>具有属性的文档.
  
• 范例是索引的逻辑种别/分区，其语义完全取决于用户。
  

  17、Elasticsearch 中的倒排索引是什么？

   倒排索引是搜刮引擎的核心。搜刮引擎的主要目标是在查找发生搜刮条件的文档时提供快速搜刮。 ES 中的倒排索引实在就是 lucene 的倒排索引，区别于传统的正向索引， 倒排索引会再存储数据时将关键词和数据进行关联，保存到倒排表中，然后查询时，将查询内容进行分词后在倒排表中进行查询，最后匹配数 据即可。
  18、Elasticsearch与数据库之间的对应关系是什么？

   Elasticsearch数据库索引index数据库文档表数据索引库(index)中的映射数据库(database)中的表布局(table)字段(Field)数据表的字段，对文档数据根据不同属性进行的分类标识反向索引索引查询DSLSQLget http://select * from tableput http://update table setdelete http://delete  19、数据库修改信息怎样同步ElasticSearch？

   

• 同步调用：直接在代码里写逻辑，数据在增删改查进数据库的同时，也往es里同步一份
  
• 使用官方的logstash，定时查询数据库，查询到数据有变革就发送到es中
  
• 利用数据库的binlog同步变革数据，然后将数据发送给es,固然也可以通过java代码监听拿到数据，再发送到es或做其他处理。
  
• MQ中心件，有数据变革的时间，就关照mq，然后监听mq实现数据同步到mq
  

  20、如安在保留不变性的前提下实现倒排索引的更新？

   用更多的索引。通过增加新的补充索引来反映新近的修改， 而不是直接重写整 个倒排索引。每一个倒排索引都会被轮番查询到，从最早的开始查询完后再对效果进行归并。
  21、ElasticSearch的主要功能及应用场景？

   

• 主要功能：
  

  1）海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展；
  2）近及时搜刮，性能杰出。对布局化、全文、地理位置等范例数据的处理；
  3）海量数据的近及时分析（聚合功能）
  

• 应用场景：
  

  1）网站搜刮、垂直搜刮、代码搜刮；
  2）日记管理与分析、安全指标监控、应用性能监控、Web抓取舆情分析
  好了，本文就到这里了！假如觉得内容不错的话，渴望各人可以帮助点赞转发一波，这是对我最大的鼓励，感谢

---

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)

Powered by Discuz! X3.4