ES提交操作与原理

根据官方文档+看源码+实验总结出来的ES各种提交的作用与原理(对应版本7.2.0).

我本地是用xmind做的, 附上xmind的截图.

ES提交.png

文字版如下:

ES提交

触发方式

给索引设置

• PUT /my-index-000001/_settings { "index" : { "refresh_interval" : "1s" } }

给文档增删改请求设置

• PUT /test/_doc/1?refresh {"test": "test"}

手动触发

• POST /my-index-000001/_refresh

效果

refresh

• tlog不截断
• 文档可见
• 不会触发段合并
• 不调用fsync, 不保证持久化
• 注意: 默认1s触发一次, 但有个特殊设定, 只有30s内接收到至少一个搜索请求的时候, 索引的refresh才会按照设置时间频率触发, 也就是说没有搜索请求的索引的refresh不会自动触发.

flush

• tlog截断
• 文档不可见
• 可能触发段合并
• 调用fsync, 保证持久化
• 没有类似于Solr的openSearcher=true选项, 不能让文档可见.

原理

refresh

• 触发lucene的reopen, 把in-memory buffer转化为in-memory segment.

flush

• 触发lucene的commit, 将in-memory buffer提交到新的段, 与已有的in-memory segments一起提交到硬盘.

lucene

• flush

- 1. 把内存段写到硬盘
- 2. 不调用fsync
- 3. 不更新segment_N文件

• commit

- 1. 把内存段写到硬盘
- 2. 调用fsync
- 3. 更新segment_N文件

建议

硬提交频率

• 参考tlog的硬盘大小, 使tlog的大小合理, 否则可能会使重启时间过长

软提交频率

• 在满足业务需求的情况下尽可能长一些

不要使用kill -9

• 正确的步骤

- 停止索引程序
- 手动硬提交或等待自动提交触发
- 停止ES服务

T-log

作用

• 异常恢复
• RealTime Get By ID

每个shard对应一个t-log