Elasticsearch 分页查询

·  阅读 2654
Elasticsearch 分页查询

前言

我们在实际工作中,有很多分页的需求,商品分页、订单分页等,在MySQL中我们可以使用limit,那么在Elasticsearch中我们可以使用什么呢?

ES 分页搜索一般有三种方案,from + size、search after、scroll api,这三种方案分别有自己的优缺点,下面将进行分别介绍。

使用的数据是kibana中的kibana_sample_data_flights

from + size

这是ES分页中最常用的一种方式,与MySQL类似,from指定起始位置,size指定返回的文档数。

GET kibana_sample_data_flights/_search
{
  "from": 10,
  "size": 2, 
  "query": {
    "match": {
      "DestWeather": "Sunny"
    }
  },
  "sort": [
    {
      "timestamp": {
        "order": "asc"
      }
    }
  ]
}
复制代码

这个例子中查询航班中,目的地的天气是晴朗的,并且按时间进行排序。

使用简单,且默认的深度分页限制是1万,from + size 大于 10000会报错,可以通过index.max_result_window参数进行修改。

{
  "error": {
    "root_cause": [
      {
        "type": "query_phase_execution_exception",
        "reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [10001]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."
      }
    ],
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    "grouped": true,
    "failed_shards": [
      {
        "shard": 0,
        "index": "kibana_sample_data_flights",
        "node": "YRQNOSQqS-GgSo1TSzlC8A",
        "reason": {
          "type": "query_phase_execution_exception",
          "reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [10001]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."
        }
      }
    ]
  },
  "status": 500
}
复制代码

这种分页方式,在分布式的环境下的深度分页是有性能问题的,一般不建议用这种方式做深度分页,可以用下面将要介绍的两种方式。

理解为什么深度分页是有问题的,我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页(结果从 1 到 10 ),每一个分片产生前 10 的结果,并且返回给协调节点 ,协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页,结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

可以看到,在分布式系统中,对结果排序的成本随分页的深度成指数上升。

search after

search after 利用实时有游标来帮我们解决实时滚动的问题。第一次搜索时需要指定 sort,并且保证值是唯一的,可以通过加入 _id 保证唯一性。

GET kibana_sample_data_flights/_search
{
  "size": 2, 
  "query": {
    "match": {
      "DestWeather": "Sunny"
    }
  },
  "sort": [
    {
      "timestamp": {
        "order": "asc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}
复制代码

在返回的结果中,最后一个文档有类似下面的数据,由于我们排序用的是两个字段,返回的是两个值。

"sort" : [
  1614561419000,
  "6FxZJXgBE6QbUWetnarH"
]
复制代码

第二次搜索,带上这个sort的信息即可,如下

GET kibana_sample_data_flights/_search
{
  "size": 2,
  "query": {
    "match": {
      "DestWeather": "Sunny"
    }
  },
  "sort": [
    {
      "timestamp": {
        "order": "asc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ],
  "search_after": [
    1614561419000,
    "6FxZJXgBE6QbUWetnarH"
  ]
}
复制代码

scroll api

创建一个快照,有新的数据写入以后,无法被查到。每次查询后,输入上一次的 scroll_id。目前官方已经不推荐使用这个API了,使用search_after即可。

GET kibana_sample_data_flights/_search?scroll=1m
{
  "size": 2,
  "query": {
    "match": {
      "DestWeather": "Sunny"
    }
  },
  "sort": [
    {
      "timestamp": {
        "order": "asc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}
复制代码

在返回的数据中,有一个_scroll_id字段,下次搜索的时候带上这个数据,并且使用下面的查询语句。

POST _search/scroll
{
  "scroll" : "1m",
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ=="
}
复制代码

上面的scroll指定搜索上下文保留的时间,1m代表1分钟,还有其他时间可以选择,有d、h、m、s等,分别代表天、时、分钟、秒。

搜索上下文有过期自动删除,但如果自己知道什么时候该删,可以自己手动删除,减少资源占用。

DELETE /_search/scroll
{
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ=="
}
复制代码

总结

from + size 的优点是简单,缺点是在深度分页的场景下系统开销比较大。

search after 可以实时高效的进行分页查询,但是它只能做下一页这样的查询场景,不能随机的指定页数查询。

scroll api 方案也很高效,但是它基于快照,不能用在实时性高的业务场景,且官方已不建议使用。

参考资料

分类:
后端
标签:
分类:
后端
标签: