ElasticSearch分页查询几种方式分析

ElasticSearch分页查询几种方式分析

引用

CSDN

1.

https://blog.csdn.net/qq_41649001/article/details/124172509

ElasticSearch分页查询几种方式分析

1. from+size

语句示例

# from+size浅分页
GET test/_search
{
  "from": 10,
  "size": 2
}

简要查询过程

1. 在发送查询请求之后，某个节点node接收请求后，会创建一个大小为from+size的优先队列来保存结果；
2. 然后会把请求发送给相关的分片shard，在每个分片shard里面也会做同样的事情，执行查询，并将结果保存到大小为from+size大小的队列里面；
3. 最后每个分片会把结果返回到节点node中。

node最终会拿到（from+size)*分片数条数据，这样来看数据量会根据查询的偏移量增加而增加，然后会将这些数据排序后，选出靠前的from+size条数据存到优先队列中。

最后会根据查询条件获取(from,from+size]数据即可。

深度分页问题

1. 当from+size的数值大于10000之后，就无法使用from+size方式去查询了。
2. 默认情况下，ES对索引的配置项中设置的max_result_window最大值为10000，分页不能超过1W条数据以上
3. 受限于from+size的查询逻辑，当查询数据的偏移量越大时，整体的查询耗时会几何倍数增加，性能问题会越来越明显

解决办法

1. 使用from+size这种方式的分页应用到对于深度分页容忍度较高的应用场景
2. 调整索引的max_result_window参数，可以根据适当情况调大这个参数。但是不是很推荐，设定这个参数的原因是源于保护的原因，设置一个比较合理的临界值不会导致内存溢出，如果只是一昧的扩大参数值，有可能就会导致很严重的后果，所以在调整这个值的时候最好要考虑各方面因素再决定，如并发、数据量、内存、es本身设置等等。
3. 采用其他的分页方式，如下面的scroll和search after

优缺点

1. 写起来简单，性能低，会存在深度分页问题，适合数据量较小的情况且能容忍深度分页问题

2. scroll

语句示例

（暂时把第一条语句称为初始化操作，第二条为检索操作）

1. 获取scroll_id并获取第一页数据

GET test/_search?scroll=1m
{
  "size": 2
}

2. 检索

GET _search/scroll
{
  "scroll": "1m",
  "scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlkDXF1ZXJ5QW5kRmV0Y2gBFEZJQ2xKb0FCcXY3U2dtcVFud0p0AAAAAAAAFrMWNjY3dlA3RGNTcjZNRE52dmFxRDR5QQ=="
}

简要查询过程

1. 初始化操作时，需要增加scroll参数，这个参数的值表示本次请求的有效期限，这里是1m=1分钟，返回的结果中包括一个scroll_id这个返回参数值就是用来向下检索的
2. 后续检索操作都可以直接使用初始化操作获取到的scroll_id，scroll参数表示ES将保留搜索的有效期延长多久，查询到的结果条数也和第一次查询的一致（上述示例中，第一次查询指定了size=2，那么进行后续翻页操作得到的结果都是2条数据）
3. 可以把scroll的逻辑分成两步操作：需要有一次初始化，以及后续的数据检索
   1. 在初始化操作的时候，ES会把此刻的符合条件的数据保存起来，形成快照，然后返回存在有效期的scroll_id，在后续遍历的之后一直使用这个参数就可以遍历完所有数据
   2. 每次执行初始化操作都会返回不同的含有有效期的scroll_id

优缺点

1. 能解决深度分页问题，适合处理大量数据，不适合实时数据需求的业务场景。
2. 由于scroll_id存在有效期，可能会占用大量资源，而且生成scroll_id时是缓存的当时的符合条件的数据，在那之后的数据变更，都不会在此scroll_id的查询结果中得到同步。

3. search_after

语句示例

1. 首次查询

GET test/_search
{
  "size": 2,
  "sort": [
    {
      "fid": {
        "order": "desc"
      }
    }
  ]
}

2. 第二次查询

GET test/_search
{
  "size": 2,
  "sort": [
    {
      "fid": {
        "order": "desc"
      }
    }
  ],
  "search_after": [19999]
}

简要查询过程

1. search_after的原理是根据上一页的最后一条数据来确定下一页的起始位置的
2. 在第一次查询的时候，不需要指定search_after的值，但是需要指定排序sort，排序可以指定多个字段，但是可以直接采用每条数据的唯一值字段（可以用_id)，在执行查询之后，获取到返回结果最后一条数据的sort值
3. 第二次查询时就直接使用第一次获取的sort值作为search_after的值即可，后续以此类推，就可以遍历全部数据

优缺点

1. 效率高，不存在深度分页问题，可以反应数据实时变化；需要有全局唯一的标识类定位一条数据（可以是一个字段，也可以是多个字段排序组合）
2. 无状态查询，实时的数据改变会影响查询结果。