分布式搜索引擎ElasticSearch读写数据工作流程

本文涉及的产品
Elasticsearch Serverless通用抵扣包,测试体验金 200元
日志服务 SLS,月写入数据量 50GB 1个月
简介: 分布式搜索引擎ElasticSearch读写数据工作流程

基本概念

segment file

存储倒排索引的文件,每个segment本质上就是一个倒排索引,每秒都会生成一个segment文件,当文件过多时es会自动进行segment merge(合并文件),合并时会同时将已经标注删除的文档物理删除


commit point

记录当前所有可用的segment,每个commit point都会维护一个.del文件(es删除数据本质是不属于物理删除),当es做删改操作时首先会在.del文件中声明某个document已经被删除,文件内记录了在某个segment内某个文档已经被删除,当查询请求过来时在segment中被删除的文件是能够查出来的,但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉;


translog日志文件

为防止ES宕机造成数据丢失保证可靠存储,ES会将每次写入数据同时写到translog日志。

ES写数据

执行流程

  • 客户端选择一个node发请求过去,该node就是coordinating node(协调节点)
  • coordinating node路由document,将请求转发给对应node(有primary shard)
  • 实际node上的primary shard处理请求,然后将数据同步到replica node
  • coordinating node若发现primary node和所有replica node都响应完操作后,就返回结果给客户端

ES读数据

执行流程

查询GET某条数据,写入某个document,该document会自动给你分配一个全局唯一id-doc id,同时也是根据doc id进行hash路由到对应的primary shard。也可手动指定doc id,比如用订单id、用户id。


可通过doc id来查询,会根据doc id进行hash,判断出当时把doc id分配到了哪个shard,从那个shard去查询


  • 客户端发送请求到任意一个node,成为coordinate node
  • coordinate node对document路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard及其所有replica中随机选择,使读请求负载均衡
  • 接收请求的node返回document给coordinate node
  • coordinate node返回document给客户端

ES查询数据的执行流程

最强大的是做全文检索,比如有三条数据

JavaEdge公众号呀
Java学习者们建议关注哦
java就很好学了呢

注意这里的字母大小写哟~

根据Java关键词来搜索,将包含Java的document给搜索出来

ES就会给你返回:JavaEdge公众号呀,Java学习者们建议关注哦

  • 客户端发送请求到一个coordinate node
  • 协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard
  • query phase每个shard将自己的搜索结果(本质上就是一些doc id),返回给coordinate node,由coordinate node进行数据的合并、排序、分页等,以生成最终结果
  • fetch phase接着由coordinate node,根据doc id去各节点中拉取实际的document数据,最终返回给客户端

ES 写数据的执行流程

  • ES读写底层原理示意图

image.png

(1) 先写入buffer,在buffer里的时候数据是搜索不到的;同时将数据写入translog日志文件

(2) 如果buffer将满,或者定时,就会将buffer中的数据refresh到一个新的segment file中

但此时数据不是直接进入segment file磁盘文件的,而是先进入os cache,即refresh.


每1s,ES 将buffer中的数据写到一个新的segment file,segment file磁盘文件每 s 生成一个,其只存储最近1s内buffer中写入的数据

  • 如果buffer中此时无数据,自然不会执行refresh操作
  • 如果buffer中有数据,默认每1s执行一次refresh,刷入一个新的segment file中


在操作系统的磁盘文件中都有os cache(操作系统缓存),即数据写入磁盘文件前,会先进入os cache,即进入OS级别的一个内存缓存


只要buffer中的数据被refresh刷入os cache,该数据就可被搜索到

为什么称 ES 是准实时(NRT,near real-time)的?


默认每1 s refresh一次,所以 ES 是准实时的,写入的数据1s之后才能被观测到.

可以通过ES的RESRful API或者Java API,手动执行一次refresh,即手动将buffer中数据刷入os cache,让数据立马就可被搜索到.只要数据被输入os cache中,buffer就会被清空,因为不需要保留缓存了,数据在translog里面已经持久化到磁盘.


(3) 只要数据进入os cache,此时就可以让这个segment file的数据对外提供搜索服务了.


(4) 重复1~3步骤,新数据不断进入buffer和translog,不断将buffer数据写入一个个segment file,每次refresh完,清空buffer,保留translog.

随着该过程不断推进,translog会变臃肿,当translog达到一定大小时,就会触发commit操作.


buffer中的数据,倒是好,每隔1秒就被刷到os cache中去,然后这个buffer就被清空了。所以说这个buffer的数据始终是可以保持住不会填满es进程的内存的。

每次一条数据写入buffer,同时会写入一条日志到translog日志文件中去,所以这个translog日志文件是不断变大的,当translog日志文件大到一定程度的时候,就会执行commit操作。


(5) commit操作第一步,就是将buffer中现有数据refresh到os cache,清空buffer


(6)将一个commit point写到磁盘,以标识该commit point对应的所有segment file


(7)强行将os cache中所有数据都fsync到磁盘


(5) commit操作第一步,就是将buffer中现有数据refresh到os cache,清空buffer


(6)将一个commit point写到磁盘,以标识该commit point对应的所有segment file


(7)强行将os cache中所有数据都fsync到磁盘


commit操作

  • 写commit point
  • 将os cache数据fsync强刷到磁盘上去
  • 清空translog日志文件


(8) 将现有的translog清空,接着重启启用一个translog,此时commit操作完成。默认每隔30分钟会自动执行一次commit,但是如果translog过大,也会触发commit。整个commit的过程,叫做flush操作。我们可以手动执行flush操作,就是将所有os cache数据刷到磁盘文件中去。


不叫做commit操作,flush操作。es中的flush操作,就对应着commit的全过程。我们也可以通过es api,手动执行flush操作,手动将os cache中的数据fsync强刷到磁盘上去,记录一个commit point,清空translog日志文件。


9)translog其实也是先写入os cache,默认每5s刷到磁盘

所以默认情况下,可能有5秒的数据仅仅驻存在buffer或者translog文件的os cache中,若此时机器宕机,会丢失5s的数据.

但是这样性能比较好,最多丢5s的数据.也可将translog设置成每次写操作必须是直接fsync到磁盘,但是性能会差很多.


实际上在这里,若面试官没有问你ES丢数据的问题,就可在这里给面试官炫一把:

其实ES第一是准实时性的,数据写入1s后可以搜索到;

可能会丢失数据,你的数据有5s会停留在buffer/translog os cache/segment file os cache中,有5s的数据不在磁盘上,此时如果宕机,会导致这5s的数据丢失.


如果你希望一定不能丢失数据的话,你可以设置个参数,官方文档,百度一下.

每次写入一条数据,都是写入buffer,同时写入磁盘上的translog,但是这会导致写性能、写入吞吐量会下降一个数量级.

本来一秒钟可以写2000条,现在你一秒钟只能写200条,都有可能.

小结

数据先写入内存 buffer,然后每隔 1s,将数据 refresh 到 os cache,到了 os cache 数据就能被搜索到(所以我们才说 es 从写入到能被搜索到,中间有 1s 的延迟).

每隔 5s,将数据写入 translog 文件(这样如果机器宕机,内存数据全没,最多会有 5s 的数据丢失),translog 大到一定程度,或者默认每隔 30mins,会触发 commit 操作,将缓冲区的数据都 flush 到 segment file 磁盘文件中.


数据写入 segment file 之后,同时就建立好了倒排索引。


3.6 ES 删除数据的执行流程

(1) commit时会生成一个.del文件,将某个doc标识为deleted态,那么搜索的时候根据.del文件就知道该doc已被删除

3.7 ES 更新数据的执行流程

(1) 将原来的doc标识为deleted状态,然后新写入一条数据


(2) buffer每refresh一次,就会产生一个segment file,所以默认情况下是1s一个segment file,segment file会越来越多,此时会定期执行merge


(3) 每次merge时,会将多个segment file合并成一个,同时这里会将标识为deleted的doc给物理删除掉,然后将新的segment file写入磁盘,这里会写一个commit point,标识所有新的segment file,然后打开segment file供搜索使用,同时删除旧的segment file.


ES 里的写流程,有4个底层的核心概念,refresh、flush、translog、merge

当segment file多到一定程度的时候,es就会自动触发merge操作,将多个segment file给merge成一个segment file。


相关实践学习
以电商场景为例搭建AI语义搜索应用
本实验旨在通过阿里云Elasticsearch结合阿里云搜索开发工作台AI模型服务,构建一个高效、精准的语义搜索系统,模拟电商场景,深入理解AI搜索技术原理并掌握其实现过程。
ElasticSearch 最新快速入门教程
本课程由千锋教育提供。全文搜索的需求非常大。而开源的解决办法Elasricsearch(Elastic)就是一个非常好的工具。目前是全文搜索引擎的首选。本系列教程由浅入深讲解了在CentOS7系统下如何搭建ElasticSearch,如何使用Kibana实现各种方式的搜索并详细分析了搜索的原理,最后讲解了在Java应用中如何集成ElasticSearch并实现搜索。  
目录
相关文章
|
23天前
|
缓存 监控 前端开发
顺企网 API 开发实战:搜索 / 详情接口从 0 到 1 落地(附 Elasticsearch 优化 + 错误速查)
企业API开发常陷参数、缓存、错误处理三大坑?本指南拆解顺企网双接口全流程,涵盖搜索优化、签名验证、限流应对,附可复用代码与错误速查表,助你2小时高效搞定开发,提升响应速度与稳定性。
|
24天前
|
消息中间件 分布式计算 资源调度
《聊聊分布式》ZooKeeper与ZAB协议:分布式协调的核心引擎
ZooKeeper是一个开源的分布式协调服务,基于ZAB协议实现数据一致性,提供分布式锁、配置管理、领导者选举等核心功能,具有高可用、强一致和简单易用的特点,广泛应用于Kafka、Hadoop等大型分布式系统中。
|
1月前
|
存储 监控 算法
117_LLM训练的高效分布式策略:从数据并行到ZeRO优化
在2025年,大型语言模型(LLM)的规模已经达到了数千亿甚至数万亿参数,训练这样的庞然大物需要先进的分布式训练技术支持。本文将深入探讨LLM训练中的高效分布式策略,从基础的数据并行到最先进的ZeRO优化技术,为读者提供全面且实用的技术指南。
|
1月前
|
存储 Linux iOS开发
Elasticsearch Enterprise 9.1.5 发布 - 分布式搜索和分析引擎
Elasticsearch Enterprise 9.1.5 (macOS, Linux, Windows) - 分布式搜索和分析引擎
216 0
|
2月前
|
JSON 监控 Java
Elasticsearch 分布式搜索与分析引擎技术详解与实践指南
本文档全面介绍 Elasticsearch 分布式搜索与分析引擎的核心概念、架构设计和实践应用。作为基于 Lucene 的分布式搜索引擎,Elasticsearch 提供了近实时的搜索能力、强大的数据分析功能和可扩展的分布式架构。本文将深入探讨其索引机制、查询 DSL、集群管理、性能优化以及与各种应用场景的集成,帮助开发者构建高性能的搜索和分析系统。
219 0
|
8月前
|
SQL
【YashanDB知识库】手工迁移Doris数据到崖山分布式
【YashanDB知识库】手工迁移Doris数据到崖山分布式
|
8月前
|
存储 分布式计算 负载均衡
数据分布式存储:在海量数据面前,我们如何站稳脚跟?
数据分布式存储:在海量数据面前,我们如何站稳脚跟?
1197 1
|
6月前
|
数据采集 存储 NoSQL
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
354 67
|
4月前
|
人工智能 分布式计算 DataWorks
分布式×多模态:当ODPS为AI装上“时空穿梭”引擎
本文深入探讨了多模态数据处理的技术挑战与解决方案,重点介绍了基于阿里云ODPS的多模态数据处理平台架构与实战经验。通过Object Table与MaxFrame的结合,实现了高效的非结构化数据管理与分布式计算,显著提升了AI模型训练效率,并在工业质检、多媒体理解等场景中展现出卓越性能。

热门文章

最新文章