Elasticsearch refresh

「爱情、让人受尽委屈。」 2023-06-11 14:26 12阅读 0赞

#### 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，无论对该分片修改多少次。