Elasticsearch(ES)(版本7.x)数据更新后刷新策略RefreshPolicy
介绍
ES数据写入后,默认1s后才会被搜索到(refresh_interval为1);
这样可能是考虑到性能问题,毕竟实时IO 消耗较多资源
造成的问题
例如一个索引现在有100个文档,当新增一个文档时,立即查询,显示数量为100,并不为101
例如当修改一个文档数据后,立即查询的结果为上次文档的数据,并不为最新数据
刷新策略RefreshPolicy
1.NONE:(默认策略)
- 请求提交数据后,不等待数据刷新,直接结束请求
- 优点:操作延时短、资源消耗低
- 缺点: 实时可见性低,数据可能不会立即可见,直到下一个自动刷新周期。
- 适用场景: 对实时性要求不高但对性能敏感的应用。
2.WAIT_UNTIL:
- 索引操作完成后,Elasticsearch 会等待当前正在进行的刷新周期完成(1s)再返回客户端请求
- 优点:数据会在当前刷新周期内变得可搜索,通常比 None 策略具有更好的实时性
- 缺点:可能会有较高的延迟,尤其是在刷新周期较长时间的情况下
- 适用场景: 需要较快的数据可见性,但又不想强制立即刷新的情况
3.IMMEDIATE:
- 请求提交数据后,立即进行数据刷新,再结束请求返回客户端
- 优点:实时性高、操作延时短,数据几乎立即变得可搜索
- 缺点:强制刷新会消耗较多资源,并可能导致更高的延迟
- 适用场景:对数据实时性有极高要求的应用
支持的接口:
删除:DeleteRequestBuilder
新增:IndexRequestBuilder
更新:UpdateRequestBuilder
批量:BulkRequestBuilder
用法:(elasticsearch-rest-high-level-client)
// 设置为立即刷新
request.setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);
// 设置为等待当前刷新周期
request.setRefreshPolicy(WriteRequest.RefreshPolicy.WAIT_UNTIL);
// 使用默认策略(即不等待刷新)
request.setRefreshPolicy(WriteRequest.RefreshPolicy.NONE);
其中 WriteRequest.RefreshPolicy 是一个枚举类型,包含了以上提到的不同刷新策略选项。
需要注意的是,频繁的刷新可能会导致更多的磁盘I/O操作,增加CPU负载,并可能导致更多的段合并操作,从而影响整体性能。因此,在选择刷新策略时,需要根据实际应用场景来平衡实时性和性能之间的关系。
结束
标签:实时性,RefreshPolicy,WriteRequest,Elasticsearch,ES,刷新,数据,刷新周期 From: https://blog.csdn.net/zk_tww/article/details/140929804