ES相关面试问题整理

索引模板了解么

索引模板，一种复用机制，就像一些项目的开发框架如 Laravel 一样，省去了大量的重复，体力劳动。当新建一个 Elasticsearch 索引时，自动匹配模板，完成索引的基础部分搭建。

模板定义，看似复杂，拆分来看，主要为如下几个部分：

{ "order": 0,                     // 模板优先级 "template": "sample_info*",     // 模板匹配的名称方式 "settings": {...},              // 索引设置 "mappings": {...},              // 索引中各字段的映射定义 "aliases": {...}                // 索引的别名
}

模板优先级

一个模板可能绝大部分符合新建索引的需求，但是局部需要微调，此时，如果复制旧的模板，修改该模板后，成为一个新的索引模板即可达到我们的需求，但是这操作略显重复。此时，可以采用模板叠加与覆盖来操作。模板的优先级是通过模板中的 order 字段定义的，数字越大，优先级越高。

索引模板的匹配

索引模板中的 "template" 字段定义的是该索引模板所应用的索引情况。如 "template": "tete*" 所表示的含义是，当新建索引时，所有以 tete 开头的索引都会自动匹配到该索引模板。利用该模板进行相应的设置和字段添加等。

setting 部分

索引模板中的 setting 部分一般定义的是索引的主分片、拷贝分片、刷新时间、自定义分析器等。

Elasticsearch 是如何实现 master 选举的

前提条件：

只有候选主节点（master：true）的节点才能成为主节点。

最小候选主节点数（min_master_nodes）的目的是防止脑裂。

实现步骤：

  • 第一步：确认候选主节点数达标，elasticsearch.yml 设置的值discovery.zen.minimum_master_nodes：作用是只有足够的master候选节点时，才可以选举出一个master。该参数必须设置为集群中master候选节点的quorum数量。quorum的算法=master候选节点数量/2+1(就是必须超过所有候选主节点一般以上，可以思考redis cluster、zk集群的脑裂问题，也有类似的参数设置)
  • 第二步：对所有候选主节点根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
  • 第三步：如果对某个节点的投票数达到一定的值（候选主节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。

【补充】master 节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data 节点可以关闭 http 功能。

如何解决ES集群的脑裂问题

【原因】

所谓集群脑裂，是指 Elasticsearch 集群中的节点（比如共 20 个），可能因为网络问题，其中的 10 个选了一个 master，另外 10 个选了另一个 master 的情况。

【解决】

当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes：最小候选主节点数）超过所有候选节点一半以上来解决脑裂问题；

对公司ES集群了解，ES集群架构，索引数据大小，分片数量

想了解应聘者之前公司接触的ES使用场景、规模，有没有做过比较大规模的索引设计、规划、调优

解答：

查看es集群状态：

curl -XGET http://localhost:9200/_cat/health?v返回结果：
{"cluster": "es-9pu872sa", #集群名称"status": "green", #集群状态 green代表健康；yellow代表分配了所有主分片，但至少缺少一个副本，此时集群数据仍旧完整；red代表部分主分片不可用，可能已经丢失数据"node.data": "8", #代表在线的数据节点的数量"node.total": "11", #代表在线的节点总数量"init": "0", #initializing_shards 初始化中的分片数量 正常情况为 0"relo": "0", #relocating_shards 迁移中的分片数量，正常情况为 0"pending_tasks": "0", #准备中的任务，任务指迁移分片等 正常情况为 0"unassign": "0", #unassigned_shards 未分配的分片 正常情况为 0"pri": "3699", #active_primary_shards 存活的主分片数量 正常情况下 shards的数量是pri的两倍"shards": "4343", #active_shards 存活的分片数量"active_shards_percent": "100.0%", #正常分片百分比 正常情况为 100%"max_task_wait_time": "-", #任务最长等待时间"epoch": "1696748727","timestamp": "07:05:27"
}

模块运营ES集群11个节点，6个hot节点16C64G配置，5个warm节点4C16G。集群因为有部门内其他项目也在用，跟我们业务相关主要索引在8+个以上，例如模块运营，

主要业务索引：

菜单访问记录按天 mcs_menu_user_access-yyyyMMdd，

菜单访问统计按月 mcs_menu_user_access_aggregation-yyyyMM，

菜单访问小时统计按月 mcs_menu_user_access_aggregation_hour-yyyyMM，

事件访问明细索引 mcs_menu_user_access_action-yyyyMM

数据量计算：前提：公司菜单总数在2300个左右，公司员工访问总人数在5-6w左右

  • 菜单访问记录索引mcs_menu_user_access，6个分片，没有副本。每日数据增量在600w左右，一个月30天数据量在2亿左右。单索引大概4G，一个月所有该索引大概120G
  • 菜单访问统计按天索引mcs_menu_user_access_aggregation，6个分片，没有副本。一个月也在1300w左右，单索引一个月大概15G的数据量
  • 菜单访问小时统计按月索引mcs_menu_user_access_aggregation_hour ，6个分片，没有副本。一个月40002左右的数据。一个月所有该索引大概30G
  • 事件访问明细按月索引 mcs_menu_user_access_action ，12个分片，没有副本。一个月数据量大概在5亿作业，占用磁盘大概在400G

索引增量：根据日期，有的按月有的按天递增，每月递增33+索引以上。

菜单访问相关的数据量没那么大，索引分片在6个分片，为节省磁盘和性能没有副本

事件访问明细索引数据量笔记打，索引分片在12个，一样没有副本

保存近1年的数据，1年以前的数据删除。

这一年的数据做采取了冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储；近6个月的数据在hot节点，前6个月的数据移到warm节点

冷热数据分离了解么

ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储数据。若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。为了解决控制成本的前提下读写性能问题，Elasticsearch冷热分离架构应运而生。

冷数据索引：查询频率低，基本无写入，一般为当天或最近2天以前的数据索引

热数据索引：查询频率高，写入压力大，一般为当天数据索引

实现原理

Hot节点设置：索引节点（写节点），同时保持近期频繁使用的索引。 属于IO和CPU密集型操作，建议使用SSD的磁盘类型，保持良好的写性能；节点的数量设置一般是大于等于3个。将节点设置为hot类型：node.attr.box_type: hot

Warm节点设置： 用于不经常访问的read-only索引。由于不经常访问，一般使用普通的磁盘即可。内存、CPU的配置跟Hot节点保持一致即可；节点数量一般也是大于等于3个。将节点设置为warm类型：node.attr.box_type: warm

可以通过两种方式对数据进行冷热的那种处理

1、针对索引设置冷热属性：指定某个索引为热索引，另一个索引为冷索引。通过索引的分布来实现控制数据分布的目的。业务上根据实际情况对索引设置冷热属性，如果按照时间定期处理。

  • index.routing.allocation.include.{attribute}表示索引可以分配在包含多个值中其中一个的节点上。
  • index.routing.allocation.require.{attribute}表示索引要分配在包含索引指定值的节点上（通常一般设置一个值）。
  • index.routing.allocation.exclude.{attribute}表示索引只能分配在不包含所有指定值的节点上。

2、通过索引生命周期管理，ES (版本>=6.6) 提供了索引生命周期管理功能。索引生命周期管理可以通过 API 或者 kibana 界面配置，详情可参考 index-lifecycle-management。使用索引生命周期管理，可以实现索引数据的自动滚动跟过期，并结合冷热分离架构进行数据的降冷跟删除。 一般通过kibana界面去创建代理任务进行配置，实现索引的动态管理，索引的生命周期被分为：Hot phrase,Warm phase, Cold phase,Delete phrase四个阶段

  • Hot phrase: 该阶段可以根据索引的文档数，大小，时长决定是否调用rollover API来滚动索引
  • Warm phrase: 当一个索引在Hot phrase被roll over后便会进入Warm phrase，进入该阶段的索引会被设置为read-only, 用户可以为这个索引设置要使用的attribute， 如对于冷热分离策略，这里可以选择temperature: warm属性。另外还可以对索引进行forceMerge, shrink等操作
  • Cold phrase: 可以设置当索引rollover一段时间后进入cold阶段，这个阶段也可以设置一个属性。从冷热分离架构可以看出冷热属性是具备扩展性的，不仅可以指定hot, warm, 也可以扩展增加hot, warm, cold, freeze等多个冷热属性。如果想使用三层的冷热分离的话这里可以指定为temperature: cold, 此处还支持对索引的freeze操作
  • Delete phrase: 可以设置索引rollover一段时间后进入delete阶段，进入该阶段的索引会自动被删除。

分片不均衡原因&解决方案

可能存在的部分原因有以下几种：

  • Shard设置不合理：大多数负载不均问题是由于shard设置不合理导致，建议优先排查。
  • Segment大小不均
  • 存在典型的冷热数据需求场景。说明：例如查询中添加了routing或查询频率较高的热点数据，则必然导致数据出现负载不均。
  • 没有释放长连接，导致流量不均。说明：该问题时常暴露于采用负载均衡及多可用区架构部署时。

解决方案

  • 方案一：手动移动分片

例如移动node-1的分片0到node-4

curl -XPOST 'http://localhost:9200/_cluster/reroute' -d '{"commands":[{"move":{"index":"indexName",  # 索引名"shard": 0,           # 需要移动的分片"from_node":"node-1", # 从哪个节点移出来"to_node":"node-4"    # 需要移到哪个节点
}}]}'

优点：操作简单，恢复时间短；不必修改master node的配置，master node长期负载后高

缺点：索引大，移动时有很高的IO，索引容易损坏，需要做备份，不能解决master node既是数据节点又是负载均衡转发器的问题

【注意】分片和副本无法移动到同一个节点

  • 方案二：重建索引，从另外一个集群导入

删除原来的索引，重新建立索引，；利用elasticsearch dump等工具从另一个集群中把数据导入到新的索引中

优点：可以重新配置master node和data node，主从负载均匀

缺点：费时间，容易数据丢失，需要验证数据的一致性

  • 方案三：配置平衡参数

使用命令恢复平衡

PUT_cluster/settings
{"persistent": {"cluster.routing.rebalance.enable": "all"}
}

解决Elasticsearch分片未分配的问题

原因

出现这个问题的原因是原有分片未正常关闭和清理，所以当分片要重新分配回出问题节点的时候没有办法获得分片锁。

这不会造成分片数据丢失，只需要重新触发一下分配。

unassigned 分片问题可能的原因如下:

  • INDEX_CREATED: 由于创建索引的API导致未分配。
  • CLUSTER_RECOVERED: 由于完全集群恢复导致未分配。
  • INDEX_REOPENED: 由于打开open或关闭close一个索引导致未分配。
  • DANGLING_INDEX_IMPORTED: 由于导入dangling索引的结果导致未分配。
  • NEW_INDEX_RESTORED: 由于恢复到新索引导致未分配。
  • EXISTING_INDEX_RESTORED: 由于恢复到已关闭的索引导致未分配。
  • REPLICA_ADDED: 由于显式添加副本分片导致未分配。
  • ALLOCATION_FAILED: 由于分片分配失败导致未分配。
  • NODE_LEFT: 由于承载该分片的节点离开集群导致未分配。
  • REINITIALIZED: 由于当分片从开始移动到初始化时导致未分配（例如，使用影子shadow副本分片）。
  • REROUTE_CANCELLED: 作为显式取消重新路由命令的结果取消分配。
  • REALLOCATED_REPLICA: 确定更好的副本位置被标定使用，导致现有的副本分配被取消，出现未分配。

解决方案如下：

执行修复命令: POST /_cluster/reroute?retry_failed

Elasticsearch 索引文档的过程

想了解ES的底层原理，不只是关注业务本身。

这里的索引文档应该理解为文档写入ES，创建索引的过程。这里说下单文档索引的过程

  1. 客户发送请求，向ES集群某节点写入数据。如果没有指定路由/协调节点，请求的节点作为协调节点
  2. 第1个节点（协调节点）接受到请求后，使用文档_id 来确定文档属于哪个分片，计算分片的算法是：shard = hash(routing) % number_of_primary_shards，routing默认是文档_id，也可以自定义routing。确定分片之后，请求会被转到另外的节点，假定节点 3。因此分片 0 的主分片分配到节点3上面
  3. 节点 3 在主分片上执行写操作，如果成功，则将请求并行转发到节点 1和节点 2 的副本分片上，等待结果返回。所有的副本分片都报告成功，节点 3 将向协调节点（节点 1）报告成功，节点 1 向请求客户端报告写入成功。

Elasticsearch 写入数据的过程

es的写入过程还是很复杂的，整个过程中还涉及到refresh刷新、强制flush一些操作，画个图可能更好理解一些

添加doc的流程：

  1. 将数据写入buffer缓冲区域，同步会将记录写入到translog日志文件中，之后返回结果。写到buffer缓冲区中的数据是还不能被search到的，可以通过get得到数据
  2. 之后buffer缓冲区中的数据，在空间被占用或者通过refresh近实时性的刷新操作，将数据刷到segment段中之后，这个时候才能被search
  3. 之后通过fsync操作将segment中的数据写入到磁盘
  4. 还会清空buffer缓冲区，等待接收新的数据

translog 和 flush操作的作用

translog文件：为了保证数据安全而存在的机制，因为文档doc刚开始是写到内存中的，还没有入到磁盘。如果此时服务器宕机那么数据就丢失了。引入translog，文档写入buffer时是同时写入到translog文件中的，这个是落盘的。这样就能防止数据丢失，并且translog是追加的方式，因此性能比较好

flush操作：每隔30分钟或者translog日志文件达到一定大小（默认512M）的时候，就会触发一次flush操作，此时ES会执行一次flush操作先将segment刷到磁盘。原有translog文件已经落盘，会生成一份新的translog日志文件

近实时性-refresh操作

es接收数据请求时先存入buffer缓冲区中，默认每隔一秒会从buffer中将数据写入segment中，这个过程叫做refresh；

当一个文档写入Lucene后是不能被立即查询到的，Elasticsearch提供了一个refresh操作，会定时地为内存中新写入的数据生成一个新的segment，此时被处理的文档均可以被检索到。refresh操作的时间间隔由refresh_interval参数控制，默认为1s, 当然还可以在写入请求中带上refresh表示写入后立即refresh，另外还可以调用refresh API显式refresh。

产生的问题

于是这个过程中就产生了大量的segment，数量越多就会占用更多的内存，并且还会影响查询的效率，因为查询数据是要具体到分片上去的，其实就是遍历segment文件进行查询，segment越多就会影响性能

merge操作

由于refresh操作1秒钟执行一次，每次都会产生一个segment段，会产生大量的segment段。这对于查询性能来说影响很大，并且占用空间。因此ES会运行一个任务检测segment，对符合要求的segment段进行合并操作，提高查询速度。用户也可以手动调用_forcemerge API强制合并merge

常用基本调优思路有哪些

设计阶段调优

  • 根据业务增量需求，采取基于日期模板创建索引，常用的方式就是基于索引模板在索引数据的时候动态创建索引。获取也可以通过rollover API动态滚动创建索引。rollover API翻滚索引指的就是 对满足特定条件的拥有别名的索引，进行采用旧索引的配置创建新索引，并对将新索引别名下的is_write_index设为true
  • 使用别名进行索引管理；
  • 每天定时在业务量低的时间点，对索引做force_merge强制合并segment段操作，手动释放磁盘空间；force_merge强制合并是指ES索引文档会产生很多个小segment段，每一个段都会占用cpu资源、句柄、内存等，并且查询的时候要到段上面进行搜索，段越多效率越慢，所以需要进行合并段操作，对这些segment进行合并减少磁盘空间，优化查询效率
  • 采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink压缩操作，以缩减存储；
  • 采取curator进行索引的生命周期管理；
  • 仅针对需要分词的字段，合理的设置分词器；
  • Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等

写入调优思路

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

查询调优思路

  • 禁用 wildcard（wildcard 检索可以定义为：支持通配符的模糊检索。类似于mysql的like）；
  • 禁用批量 terms（成百上千的场景）；
  • 充分利用倒排索引机制，能 keyword 类型尽量 keyword；
  • 数据量大时候，可以先基于时间敲定索引再检索；
  • 设置合理的路由机制。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/133283.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

阿里云10M公网收费价格表（一年和1个月报价）

阿里云10M公网收费价格表（一年和1个月报价）

阿里云服务器10M带宽收费价格表，阿里云服务器上海地域10M带宽一年优惠价格5355元，10M带宽一个月525元，地域不同带宽价格不同，阿里云服务器网以华东1（上海）地域为例，5M及5M以下带宽按照23元一个月…
阅读更多...
C++：多态

C++：多态

本文主要介绍c中多态的概念、多态的定义及实现、抽象类、多态的原理、单继承和多继承关系中的虚函数表。 目录 一、多态的概念 二、多态的定义及实现 1.多态的构成条件 2.虚函数 3.虚函数的重写 4.C11 override 和 final 5.重载、覆盖(重写)、隐藏(重定义)的对比 三、…
阅读更多...
并发、并行、同步、异步、阻塞、非阻塞

并发、并行、同步、异步、阻塞、非阻塞

一、多核、多cpu （一）多核 Multicore 核是CPU最重要的部分。负责运算。核包括控制单元、运算单元、寄存器等单元。 多核就是指单个CPU中有多个核。 （二）多cpu Multiprocessor 多cpu就是一个系统拥有多个CPU。每个CPU可能有单个核…
阅读更多...
vue项目打包，使用externals抽离公共的第三方库

vue项目打包，使用externals抽离公共的第三方库

封装了一个插件，用来vue打包抽离公共的第三方库，使用unplugin进行插件开发，vite对应的功能使用了vite-plugin-externals进行二次开发 github地址 npm地址 hfex-auto-externals-plugin 自动注入插件,使用 unplugin 和 html-webpack-plugin进…
阅读更多...
UE4和C++ 开发-C++与UMG的交互2（C++获取UMG的属性）

UE4和C++ 开发-C++与UMG的交互2（C++获取UMG的属性）

1、...C获取UMG的属性 1.1、第一种方法&#xff1a;通过名称获取控件。 void UMyUserWidget::NativeConstruct() {Super::NativeConstruct();//通过名字&#xff0c;获取蓝图控件中的按钮引用。CtnClic Cast<UButton>(GetWidgetFromName(TEXT("Button_44"))…
阅读更多...
一文读懂flutter线程： 深入了解Flutter中的多线程编程

一文读懂flutter线程： 深入了解Flutter中的多线程编程

深入了解Flutter中的多线程编程 前言一、为什么需要多线程&#xff1f;二、在Flutter中创建线程三、多线程的最佳实践四、Flutter中的多线程示例五、Flutter中的多线程错误处理六、Flutter中的多线程性能优化七、安全性和隐私考虑八、跨平台性考虑 总结 前言 在移动应用开发领域…
阅读更多...
2023软件测试面试题（亲身经历）

2023软件测试面试题（亲身经历）

在职&#xff0c;5年测试经验&#xff0c;坐标广州&#xff0c;有点想666。于是进行了几场线上面试… 1、python有哪些数据类型 数字型&#xff1a;int/float/bool/complex 字符串&#xff1a;str 列表&#xff1a;list 元组&#xff1a;tuple 字典&#xff1a;dict 集合&…
阅读更多...
conda 创建虚拟环境

conda 创建虚拟环境

1.为什么要创建虚拟环境 我们在做开发或者跑论文实验可能会同时进行多个任务&#xff0c;这些任务可能会依赖于不同的python环境&#xff0c;比如有的用到3.6有的用到3.7&#xff0c;这时我们创建不同版本的python&#xff0c;放到虚拟环境中给不同的任务分别提供其所需要的版本…
阅读更多...
媒体基础：打开多模态大模型的新思路

媒体基础：打开多模态大模型的新思路

编者按&#xff1a;2023年是微软亚洲研究院建院25周年。25年来&#xff0c;微软亚洲研究院探索并实践了一种独特且有效的企业研究院的新模式&#xff0c;并以此为基础产出了诸多对微软公司和全球社会都有积极影响的创新成果。一直以来&#xff0c;微软亚洲研究院致力于创造具有…
阅读更多...
深度学习之微调

深度学习之微调

在现代深度学习领域&#xff0c;精细调整&#xff08;Fine-tune&#xff09;已经成为一种非常重要的技术手段。 预训练模型 在介绍finetune之前&#xff0c;先了解一下什么是预训练模型。在搭建一个网络模型来完成一个特定的图像分类的任务时&#xff0c;首先&#xff0c;需要…
阅读更多...
HSN：微调预训练ViT用于目标检测和语义分割，华南理工和阿里巴巴联合提出

HSN：微调预训练ViT用于目标检测和语义分割，华南理工和阿里巴巴联合提出

今天跟大家分享华南理工大学和阿里巴巴联合提出的将ViT模型用于下游任务的高效微调方法HSN&#xff0c;该方法在迁移学习、目标检测、实例分割、语义分割等多个下游任务中表现优秀&#xff0c;性能接近甚至在某些任务上超越全参数微调。 论文标题&#xff1a;Hierarchical Side…
阅读更多...
培训考试系统如何满足个性化学习需求？

培训考试系统如何满足个性化学习需求？

随着科技的不断发展&#xff0c;培训考试系统逐渐成为满足个性化学习需求的重要工具。个性化学习强调根据每个学员的特点和需求&#xff0c;量身定制学习内容和方式&#xff0c;提高学习效果和学习兴趣。 培训考试系统通过个性化内容推荐满足学员的学习需求。系统会根据学员的…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023