首页 > 其他 > 详细

ElasticSearch架构原理

时间:2021-01-20 17:29:57      阅读:53      评论:0      收藏:0      [点我收藏+]

ElasticStack数据流

技术分享图片

ElasticSearch

建立索引和类型

  • 在Elasticsearch集群中,节点是对等的,节点间会通过自己的一些规则选取集群的Master,Master节点会负责集群状态信息的改变,并同步给其他节点。
  • 建立索引和类型的请求先发送到Master节点,Master建立完索引后,将集群状态同步至Slave节点。
  • 只有建立索引和类型需要经过Master节点,数据的写入有一个简单的Routing规则,可以Route到集群中的任意节点,所以数据写入压力是分散在整个集群的。

分片内文档写入流程

技术分享图片
  • In-memory Buffer
    在主分片节点上,文档会先被写入到内存(In-memory Buffer)中,此时数据还不能被搜索到。

  • Refresh
    经过一段时间(refresh_interval)或者内存缓冲满了,Elasticsearch会将内存中的文档Refresh到文件系统缓存(Filesystem Cache)中,并清除内存中的对应文档。

  • Filesystem Cache
    文档在文件系统缓存中被解析为Lucene的底层文件Segment中,同时建立倒排索引。这个时候文档是可以被搜索到的,因此减少了后续写入磁盘的大量时间,体现了Elasticsearch搜索的实时性(下图中的绿色和灰色图标分别代表已写入磁盘和未写入磁盘的文档)。
    技术分享图片

  • Segment
    Lucene把每次生成的倒排索引,叫做一个段(Segment),它无法被修改,只能被合并和删除。另外使用一个Commit文件,记录索引内所有的Segment。由于每次打开一个Segment就会消耗一个文件句柄,随着Segment越来越多,将导致查询性能越来越差。这时,ElasticSearch后台会有一个单独线程专门合并Segment,将零碎的小的Segment合并成一个大的Segment。
    技术分享图片
    技术分享图片

  • Flush
    将Segment写入磁盘中,更新Commit文件并删除文档对应的Translog文件。

  • Translog
    Elasticsearch在把数据写入到Index Buffer的同时,其实还另外记录了一个Translog日志。它是以顺序写文件的形式写入到磁盘中的,速度较快。如果发生异常,Elasticsearch会从Commit位置开始,恢复整个Translog文件中的记录,保证数据一致性。

多个分片的文档写入

确定文档存储位置

计算方式:

shard = hash(routing) % number_of_primary_shards

每个文档都有一个routing参数,默认情况下就使用其 _id 值。将其 _id 值计算哈希后,对索引的主分片数取余,就得到了文档实际应该存储到的分片。因此索引的主分片数不可以随意修改,一旦主分片数改变,所有文档的存储位置计算结果都会发生改变,索引数据就完全不可读了。

同步副本

技术分享图片

  1. 客户端请求发送给Node 1节点,注意图中Node 1是Master节点,实际完全可以不是;
  2. Node 1用文档的 _id 取余计算得到应该将数据存储到shard 0上。通过Cluster State信息发现shard 0的主分片已经分配到了Node 3上。Node 1转发请求数据给Node 3;
  3. Node 3完成请求数据的索引过程,存入主分片 0。然后并行转发数据给分配有shard 0的副本分片的Node 1和Node 2。当收到任一节点汇报副本分片数据写入成功,Node 3即返回给初始的接收节点 Node 1,宣布数据写入成功。Node 1返回成功响应给客户端;
  4. 当集群中某个节点宕机,该节点上所有分片中的数据全部丢失(既有主分片,又有副分片)。丢失的副分片对数据的完整性没有影响,丢失的主分片在其他节点上的副分片会被选举成主分片;所以整个索引的数据完整性没有被破坏。

注:图中P代表主分片(Primary Shard),R代表副本(Replica Shard)。

根据_id查询文档

GET /[index]/_doc/[_id]
技术分享图片
  1. Elasticsearch集群中的任意节点都可以作为协调(Coordinating)节点接受请求,每个节点都知道集群中任一文档位置;
  2. 协调节点对文档的_id进行路由,从而判断该数据在哪个Shard,然后将请求转发给对应的节点,此时会使用随机轮询算法,在Primary Shard和Replica Shard中随机选择一个,从而对请求负载均衡;
  3. 处理请求的节点返回文档给协调节点;
  4. 协调节点返回文档给客户端。

根据字段值检索数据

GET /[index]/_search?q=[field]: [value]
技术分享图片
  1. Elasticsearch集群中的任意节点都可以作为协调(Coordinating)节点接受请求,每个节点都知道集群中任一文档位置;
  2. 协调节点进行分词等操作后,向所有的shard节点发送检索请求;
  3. ElasticSearch已建立字段的倒排索引,即可通过字段值检索到所在文档的_id。随后Shard将满足条件的数据(_id、排序字段等)信息返回给协调节点;
  4. 协调节点将数据重新进行排序,获取到真正需要返回的文档的_id。协调节点再次向对应的Shard发起请求(此时已经有_id 了,可以直接定位到对应的Shard);
  5. Shard将_id对应的文档的完整内容返回给协调节点;
  6. 协调节点获取到全部检索结果,返回给客户端。

上述流程和根据_id查询文档相比,只是多了一个从倒排索引中根据字段值寻找文档_id的过程,其中的4~6步完全相同。

ElasticSearch架构原理

原文:https://www.cnblogs.com/koktlzz/p/14303609.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!