Elasticsearch 的 refresh
Index, Update, Delete, and Bulk APIs 支持通过设置 refresh 来该请求是否对查询可见;有如下值可以使用:
-
空字符串或者 true
当操作发生后,立即更新相关的主分片以及复制分片(并不是整个索引),更新的文档会立即出现在查询结果中。如果做此修改要仔细的思考和验证,不管从索引还是查询的角度,都不会导致性能变差。 -
wait for
在响应之前,等待请求所做的更改被刷新可见。这个并不会强制立即刷新,而是等待一次刷新发生。Elasticsearch 自动的在每个(index.refresh_interval)周期内刷新分片,该默认时间为 1s,可以动态修改。调用 Refresh API 或者设置支持refresh
为true
的API 也会造成刷新,从而导致已经运行refresh=wait_for
的请求返回。 -
false(默认)
不采取任何刷新相关操作。此请求所做的更改将在请求返回后的某个时间变得可见。
选择要使用的配置
除非你有充足的理由需要等待改变变为可见,否则就使用 refresh=false
,因为这个是默认的,所以 ULR 上也不需要保留这个参数。这个是最简单与便捷的选择。
如果你要求必须更改与请求同步可见,那么就需要在向 Elasticsearch 添加更多负载和等待更长时间的响应之间进行选择。以下几点有助于你作出决定:
-
设置为
wait_for
相比于设置为true
,索引上的更改越多,保留的工作也越多,如果索引每个周期内index.refresh_interval
更改一次,则不保存任何工作。 -
设置为
true
会创造低效的索引结构(小的 segment),然后必须将其合并为更大的索引结构(大的 segment)。意味着设置为true
的代价有创建小段的索引时间,查询小段的查询时间,以及合并为大段的合并时间。 -
永远不要连续启动多个
refresh=wait_for
的请求。而是将它们批处理为一个带refresh=wait_for
的 bulk 请求,Elasticsearch 会并行的启动它们,并在全部完成后返回。 -
如果刷新时间间隔设置为
-1
,将会禁止自动刷新,那么带refresh=wait_for
的请求将会无限等待,直到一些操作引起刷新。相反的,设置index.refresh_interval
值比默认值小,如 200ms ,会使refresh=wait_for
响应变快,但是依然会产生低效的段。 -
refresh=wait_for
仅影响其上的请求,但是,通过立即强制刷新,refresh=true
会影响其他正在进行的请求。通常来说,你有一个正常运行的系统,你并不希望去干扰它,那么refresh=wait_for
会是一个很小的修改。
refresh=wait_for
也可能强制刷新
如果一个 refresh=wait_for
请求进来,这个时候已经有 index.max_refresh_listeners
个请求(默认1000)等待那个分片刷新,那个这个请求就会表现为 true
: 它将会强制刷新。这保证了当 refresh=wait_for
请求返回时更改对于搜索可见,同时防止未检查的资源被阻塞的请求使用。如果一个请求因为监听 slog 不够而强制刷新,那么响应体中会包含 "forced_refresh": true
;
Bulk 请求仅仅会占用每个接触分片一个的 slot,无论对该分片修改多少次。