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可见！ } }