什么是ElasticSearch的深度分页问题？如何解决？

创作小达人

于 2024-08-21 20:16:16 发布

阅读量366

点赞数 12

文章标签： java elasticsearch 搜索引擎全文检索

本文链接：https://blog.csdn.net/2301_76166241/article/details/141401939

版权

Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。

在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。

From/Size参数

在ES中，分页查询默认返回最顶端的10条匹配hits。

如果需要分页，需要使用from和size参数。

from参数定义了需要跳过的hits数，默认为0；
size参数定义了需要返回的hits数目的最大值。

一个基本的ES查询语句是这样的：

POST /my_index/my_type/_search
{
    "query": { "match_all": {}},
    "from": 100,
    "size":  10
}

上面的查询表示从搜索结果中取第100条开始的10条数据。

那么，这个查询语句在ES集群内部是怎么执行的呢？

在ES中，搜索一般包括两个阶段，query 和 fetch 阶段，可以简单的理解，query 阶段确定要取哪些doc，fetch 阶段取出具体的 doc。

Query阶段

如上图所示，描述了一次搜索请求的 query 阶段：·

Client 发送一次搜索请求，node1 接收到请求，然后，node1 创建一个大小为from + size的优先级队列用来存结果，我们管 node1 叫 coordinating node。
coordinating node将请求广播到涉及到的 shards，每个 shard 在内部执行搜索请求，然后，将结果存到内部的大小同样为from + size 的优先级队列里，可以把优先级队列理解为一个包含top N结果的列表。
每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node，coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并，产生一个全局的优先级队列，存到自身的优先级队列里。

在上面的例子中，coordinating node 拿到(from + size) * 6条数据，然后合并并排序后选择前面的from + size条数据存到优先级队列，以便 fetch 阶段使用。

另外，各个分片返回给 coordinating node 的数据用于选出前from + size条数据，所以，只需要返回唯一标记 doc 的_id以及用于排序的_score即可，这样也可以保证返回的数据量足够小。

coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。

Fetch阶段

query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。

上图展示了 fetch 过程：

coordinating node 发送 GET 请求到相关shards。
shard 根据 doc 的_id取到数据详情，然后返回给 coordinating node。
coordinating node 返回数据给 Client。

coordinating node 的优先级队列里有from + size 个_doc _id，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前100条数据是不需要取的，只需要取优先级队列里的第101到110条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 来避免多次去同一分片取数据，从而提高性能。

这种方式请求深度分页是有问题的：

我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。

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

对结果排序的成本随分页的深度成指数上升。

size的大小不能超过index.max_result_window这个参数的设置，默认为10000。

如果搜索size大于10000，需要设置index.max_result_window参数

PUT _settings
{
    "index": {
        "max_result_window": "10000000"
    }
}

深度分页解决方案

滚动查询：Scroll Search

Scroll Search是一种用于处理大量数据的分批次查询机制。通过使用滚动搜索，可以在不影响性能的情况下逐批次地获取结果集。

假设我们有一个名为"exam_info"的索引，其中存放着10万名考生的考试信息。我们希望按照成绩进行倒序排序，并获取前100名考生的信息。

示例输入：

GET /exam_info/_search?scroll=5m
{
  "size": 100,
  "sort": [
    { "score": "desc" }
  ]
}

参数解释：

scroll：定义滚动搜索的时间间隔。这里设置为5分钟，在5分钟内完成整个滚动搜索操作。
size：每个滚动搜索批次返回的文档数量。这里设置为100，表示每次获取100个考生的信息。
sort：指定按照成绩字段（"score"）进行倒序排序。

示例输出：

{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAACsFlRlQjNqSVh0VzIwdXk4UnhOTmdSc2cAAAAAADFLW0xjb3VkT1dHcG9uejZtZURxS3oxMw==",
  "hits": {
    "total": 100000,
    "max_score": null,
    "hits": [
      { "name": "John", "score": 98 },
      { "name": "Alice", "score": 97 },
      { "name": "Bob", "score": 95 },
      ...
    ]
  }
}

输出解释：

_scroll_id：滚动搜索的标识符，用于后续获取下一批次结果。
hits.total：符合查询条件的总文档数。这里为10万。
hits.hits：当前批次返回的文档列表，每个文档包含考生的姓名（"name"）和成绩（"score"）。

在获得第一批结果后，可以使用滚动搜索的Scroll API来获取下一批结果，直到获取完整的结果集。

示例输入：

GET /_search/scroll
{
  "scroll": "5m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAACsFlRlQjNqSVh0VzIwdXk4UnhOTmdSc2cAAAAAADFLW0xjb3VkT1dHcG9uejZtZURxS3oxMw=="
}

示例输出：

{
  "_scroll_id": "DXF1ZXJ5VGhlbkZldGNoBQAAAAAAAACsFlRlQjNqSVh0VzIwdXk4UnhOTmdSc2cAAAAAADFLW0xjb3VkT1dHcG9uejZtZURxS3oxMw==",
  "hits": {
    "total": 100000,
    "max_score": null,
    "hits": [
      { "name": "Eric", "score": 94 },
      { "name": "Catherine", "score": 93 },
      { "name": "David", "score": 92 },
      ...
    ]
  }
}

Search After

Search After 是一种基于游标的分页查询机制，用于获取大量数据的连续结果。与滚动搜索不同，Search After适用于持久化保存查询状态，并支持随时获取下一页结果。

假设我们有一个名为"exam_info"的索引，其中存放着10万名考生的考试信息。我们希望按照成绩进行倒序排序，并获取前100名考生的信息。

示例输入：

GET /exam_info/_search
{
  "size": 100,
  "sort": [
    { "score": "desc" }
  ]
}

参数解释：

size：每页返回的文档数量。这里设置为100，表示每次获取100个考生的信息。
sort：指定按照成绩字段（"score"）进行倒序排序。

示例输出：

{
  "took": 5,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 100000,
    "max_score": null,
    "hits": [
      { "name": "John", "score": 98 },
      { "name": "Alice", "score": 97 },
      { "name": "Bob", "score": 95 },
      ...
    ]
  }
}

输出解释：

took：查询所花费的时间，单位为毫秒。
hits.total：符合查询条件的总文档数。这里为10万。
hits.hits：当前页返回的文档列表，每个文档包含考生的姓名（"name"）和成绩（"score"）。

在获得第一页结果后，可以使用Search After来获取下一页的结果

示例输入：

GET /exam_info/_search
{
  "size": 100,
  "sort": [
    { "score": "desc" }
  ],
  "search_after": [97]
}

参数解释：

size：每页返回的文档数量。与初始请求保持一致。
sort：指定按照成绩字段进行倒序排序。与初始请求保持一致。
search_after：指定上一页最后一条数据的排序值，以此作为游标进行下一页查询。

示例输出：

{
  "took": 2,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 100000,
    "max_score": null,
    "hits": [
      { "name": "Eva", "score": 94 },
      { "name": "Daniel", "score": 93 },
      { "name": "Catherine", "score": 92 },
      ...
    ]
  }
}

Search After 和 Scroll Search 的主要区别如下：

结果排序：Search After依赖排序字段进行分页，需要指定相应的排序方式。而Scroll Search可以根据查询条件对结果进行排序。
时间限制：Search After没有时间限制，可按需获取结果。而Scroll Search需要设置滚动时间间隔，超过该时间将失去滚动上下文。

总结起来，ES的深度分页在处理大规模数据集时是一项非常有用的功能，深度分页查询可能会面临一些性能和可靠性方面的挑战，需要根据具体情况进行权衡和优化。

创作小达人

关注

12
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
什么是ElasticSearch的深度分页问题？如何解决？

Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。
复制链接

扫一扫