ElasticSearcher索引

前言

1:查询的过程是怎样的(结合架构分析)

2:索引过程是怎样的(结合架构分析)

3:ES索引的存储结构是怎样的

 

本文只介绍索引

 

正文

 

1: 索引过程

文档只有在segment中才能被查询,建索引的时候是放在内存中,此内存不是一个segment。

refresh操作是生成新segment,fsync是将translog刷新到磁盘,flush相当于一次segment落盘。

a: 更新的doc,先会被放在mem-buffer中,即在建完的正倒排信息放在内存中,并且将此次id的操作追加到translog缓存中(内存)

b: 执行refresh,一个新segment生成,上述内存索引的数据会放入到此新segment中,此次新建的文档都可以查询 @hxx 类似esearch 3s段生成,ES默认refresh间隔是1s(可设置)。

c:执行完b的refresh后,正倒排的mem-buffer清空,而translog缓存还不会被清空

d:5s间隔执行一个fsync操作,将translog缓存写入translog文件(落盘了,但是segment还在内存中)

d: flush 操作,translog和新segment均落盘 @hxx 类似6h,ES是默认30m

相同点: 与esearch有很多相似的地方,更新的文档在老端中存在,也是被标记删除的,等到merge的时候会被真正的删除。

不同点: translog为了保证在30min内segment还未落盘宕机产生的丢数据风险,保证最多丢5s的文档。flush会有两个操作,将segment落盘和translog缓存中的数据落盘,translog缓存中的数据会5s自动落盘。

数据持久化步骤如下:write -> refresh -> flush -> merge

 

设置实时性:

PUT /my_logs { "settings": { "refresh_interval": "30s" ## 实时性是30s可见! } }

 

 

 

 

 

 

你可能感兴趣的:(云搜索进阶之路)