ES的三种分页的选择

一、ES的三种分页的选择

es实现分页查询,在ES中有三种方式可以实现分页:from+size、scroll、search_after

1、from+size 分页

原理:

假设取的页数较大时(深分页),如请求第20页,Elasticsearch不得不取出所有分片上的第1页到第20页的所有文档,并做排序,
最终再取出from后的size条结果作为最终的返回值。
假设你有16个分片,则需要在coordinate node汇总到 shards* (from+size)条记录,即需要16*(20+10)记录后做一次全局排序。
所以,当索引非常非常大(千万或亿),是无法使用from + size 做深分页的,分页越深则越容易OOM,即便不OOM,也很消耗CPU和内存资源。
因此ES使用index.max_result_window:10000作为保护措施 ,即默认 from + size 不能超过10000,虽然这个参数可以动态修改,
也可以在配置文件配置,但是最好不要这么做,应该改用ES游标来取得数据。
  • 在使用过程中,有一些典型的使用场景,比如分页、遍历等。在使用关系型数据库中,我们被告知要注意甚至被明确禁止使用深度分页,同理,在 Elasticsearch 中,也应该尽量避免使用深度分页。es为了性能,限制了我们分页的深度,es目前支持的最大的 max_result_window = 10000;from+size二者之和不能超过1w,也就是说我们不能分页到1w条数据以上。

  • from+size分页原理很简单,比如需要查询10条数据,es则需要执行from+size条数据然后根据偏移量截断前N条处理后返回。随着偏移量的增大这个时间会呈几何式增长。

如何解决from+size 分页带来的性能问题

  • 1.在业务逻辑上禁止深度分页,比如不允许查询10000条以后的数据
  • 2.更换分页方式,采用游标 scroll的方式

2、游标 scroll 分页

  • Scroll往往是应用于后台批处理任务中,不能用于实时搜索,因为这个scroll相当于维护了一份当前索引段的快照信息,这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据,都不会在这个快照中查询到。但是它相对于from和size,不是查询所有数据然后剔除不要的部分,而是记录一个读取的位置,保证下一次快速继续读取。查询时会自动返回一个_scroll_id,通过这个id可以继续查询

    public function list(Request $request)
        {
            if (!isset($request->scroll_id)) {
                $params = [
                    'scroll' => '30s',  //快照存活的时间  1m ->一分钟
                    'size' => $request->limit,
                    'index' => $this->index,
                    'type' => $this->type,
                ];
                $response = app('es')->search($params);
            } else {
                $response = app('es')->scroll([
                    'scroll_id' => $request->scroll_id,  //...using our previously obtained _scroll_id
                    'scroll' => '30s',           // and the same timeout window
                    ]
                );
            }
    
            return [
                'scroll_id' => $response['_scroll_id'],
                'data' => $response['hits']['hits'],
            ];
        }
    

游标 scroll 带来的问题

这种分页方式虽然查询变快了,但滚动上下文代价很高,每一个 scroll_id 不仅会占用大量的资源(特别是排序的请求),而且是生成的历史快照,对于数据的变更不会反映到快照上,那么在实时情况下如果处理深度分页的问题呢?es 给出了 search_after 的方式,这是在 >= 5.0 版本才提供的功能。

3、search_after分页

searchAfter的方式通过维护一个实时游标来避免scroll的缺点,它可以用于实时请求和高并发场景。
search_after的理念是,在不同分片上(假设有5个分片),先按照指定顺序排好,根据我们传的search_after值 ,然后仅取这个值之后的size个文档。这 5*size 个文档拿到Es内存中排序后,返回前size个文档即可。避免了浅分页导致的内存爆炸情况,经实际使用性能良好,ES空闲状态下查询耗时稳定在50ms以内,平均10~20ms。

    public function list(Request $request)
    {
        if (!isset($request->search_after)) {
            $params = [
                'size' => $request->limit,
                'index' => $this->index,
                'type' => $this->type,
                'body' => [
                    'sort' => [
                        [
                            '_id' => 'desc',
                        ],
                    ],
                ],
            ];
        } else {
            $params = [
                'size' => $request->limit,
                'index' => $this->index,
                'type' => $this->type,
                'body' => [
                    'sort' => [
                        [
                            '_id' => 'desc',
                        ],
                    ],
                    'search_after' => [$request->search_after],
                ],
            ];
        }
        $response = app('es')->search($params);

        return [
            //项目中需优化数组溢出,此处仅为简单演示
            'search_after' => $response['hits']['hits'][count($response['hits']['hits']) - 1]['sort'][0], 
            'data' => $response['hits']['hits'],
        ];
  • 注意:
    • 当我们使用search_after时,from值必须设置为0或者-1(当然你也可以不设置这个from参数)。
    • 当存在search_after参数时,不允许出现scroll参数

search_after 带来的问题

ElasticSearch之Search_After的注意事项

1.搜索时,需要指定sort,并且保证值是唯一的(可以通过加入_id或者文档body中的业务唯一值来保证);
2.再次查询时,使用上一次最后一个文档的sort值作为search_after的值来进行查询;
3.不能使用随机跳页,只能是下一页或者小范围的跳页(一次查询出小范围内各个页数,利用缓存等技术,来实现小范围分页,比较麻烦,比如从第一页调到第五页,则依次查询出2,3,4页的数据,利用每一次最后一个文档的sort值进行下一轮查询,客户端或服务端都可以进行,如果跳的比较多,则可能该方法并不适用)
它与滚动API非常相似,但与它不同,search_after参数是无状态的,它始终针对最新版本的搜索器进行解析。因此,排序顺序可能会在步行期间发生变化,具体取决于索引的更新和删除

4、总结

from+ size 分页,如果数据量不大或者from、size不大的情况下,效率还是蛮高的。但是在深度分页的情况下,这种使用方式效率是非常低的,并发一旦过大,还有可能直接拖垮整个ElasticSearch的集群。
scroll 分页通常不会用在客户端,因为每一个 scroll_id 都会占用大量的资源,一般是后台用于全量读取数据使用
search_after通过维护一个实时游标来避免scroll的缺点,它可以用于实时请求和高并发场景,一般用于客户端的分页查询
大体而言就是在这三种分页方式中,from + size不适合数据量很大的场景,scroll不适合实时场景,而search after在es5.x版本之后应运而生,较好的解决了这个问题。

你可能感兴趣的:(elasticsearch,elasticsearch,大数据,搜索引擎)