在Elasticsearch中,我们可以通过size和from来对我们的结果来进行分页。但是对于数据量很大的索引,这是有效的吗?Scroll API可用于从单个搜索请求中检索大量结果(甚至所有结果),这与在传统数据库上使用cursor的方式非常相似。Scroll不是用于实时用户请求,而是用于处理大量数据,例如,用于处理大量数据。 为了将一个索引的内容重新索引到具有不同配置的新索引中。
为了说明问题,我们今天先创建一个叫做twitter的Index:
1 | POST _bulk |
在上面,我们创建了6个文档。这些文档的数量虽然不是很多,但是我们想为了说明问题的方便。在实际的使用中,我们可能有成百上千的文档。
下面,我们通过size和from的方法来进行分页。假如我们把sizs设置为2,那么,我们可以通过如下写的方法来进行分页。
1 | GET twitter/_search?size=2&from=0 |
这样,我们每次可以得到2个文档,从而对我们的Index进行分页。我们可以得到这些数据并在自己的页面上或应用里进行展示。通常这样的每个请求返回的上线是10K。如果超过这个上限的话,这样的方法将不再适合。
上面的这种方法,对于小量的数据是可行的,但是对于大量的数据,而且我们需要进行sort时,这个有可能变得力不从心,比如:
1 | GET twitter/_search |
你可以想象当你更深入地进行分页时,它会变得多么低效。 例如,如果更改mapping并希望将所有现有数据重新索引到新索引中,您可能没有足够的内存来对所有结果进行排序以返回最后一页的数据。
对于这种应用场景,你可以使用scan搜索类型。我们可以这么做:
1. 使用scroll来返回一个初始的搜索,并返回一个scroll ID
1 | GET twitter/_search?scroll=1m |
这里的scroll=1m,表明Elasticsearch允许等待的时间是1分钟。如果在一分钟之内,接下来的scroll请求没有到达的话,那么当前的请求的上下文将会丢失。
返回的结果是:
1 | { |
在这里,我们可以看到一个返回的_scroll_id。这个_scroll_id将会被用于接下来的请求。
2. 使用_scroll_id,再次请求
利用上次请求返回来的_scroll_id,再次请求以获得下一个page的信息:
1 | GET _search/scroll |
在这里必须指出的是:
- 这里填写的scroll_id是上一个请求返回的值
- 这个scroll_id的有效期是我们在第一次搜索时定义的1m,也就是1分钟。如果超过了,这个就没有用
运行后返回的结果是:
1 | { |
显然这次返回的是2个文档。我们需要再次使用同样的办法来得到最后一个page的结果:
1 | { |
显然,这次返回的结果只有一个数值,比我们请求的page大小2要小。如果我们利用返回的_scroll_id再次请求时,我们可以看返回的结果是:
1 | { |
这次是一个结果都没有。
如果完成此过程,则需要清理上下文,因为上下文在超时之前仍会占用计算资源。 如下面的屏幕快照所示,您可以使用scroll_id参数在DELETE API中指定一个或多个上下文:
1 | DELTE_search/scroll |
参考:
【1】Elasticsearch Scroll
【2】https://www.elastic.co/guide/en/elasticsearch/reference/7.4/search-request-body.html#request-body-search-scroll