• Elasticsearch 深入理解search After 处理深度分页问题


    深度分页问题大致可以分为两类

    • 随机深度分页:随机跳转页面
    • 滚动深度分页:只能一页一页往下查询

    本文得search After 处理的是滚动深度分页的问题

    在旧版本中,ES为深度分页有scroll search 的方式,官方的建议并不是用于实时的请求,因为**每一个 scroll_id 不仅会占用大量的资源(特别是排序的请求),而且是生成的历史快照,对于数据的变更不会反映到快照上。**这种方式往往用于非实时处理大量数据的情况,比如要进行数据迁移或者索引变更之类的。那么在实时情况下如果处理深度分页的问题呢?es 给出了 search_after 的方式,这是在 >= 5.0 版本才提供的功能。

    这也是本文要重要讲解的内容

    **基本思想:**searchAfter的方式通过维护一个实时游标来避免scroll的缺点,它可以用于实时请求和高并发场景。

    ??思考:那search After 为什么不用产生临时快照之类的存储信息,就能保证滚动顺序读取数据呢?

    每个文档具有一个唯一值的字段应该用作排序规范的仲裁器。否则,具有相同排序值的文档的排序顺序将是未定义的。建议的方法是使用字段_id,它肯定包含每个文档的一个唯一值。

    POST twitter/_search
    {
        "size": 10,
        "query": {
            "match" : {
                "title" : "es"
            }
        },
        "sort": [
            {"date": "asc"},
            {"_id": "desc"}
        ]
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13

    返回出的结果信息

    {
          "took" : 29,
          "timed_out" : false,
          "_shards" : {
            "total" : 1,
            "successful" : 1,
            "skipped" : 0,
            "failed" : 0
          },
          "hits" : {
            "total" : {
              "value" : 5,
              "relation" : "eq"
            },
            "max_score" : null,
            "hits" : [
              {
                ...
                },
                "sort" : [
                  ...
                ]
              },
              {
                ...
                },
                "sort" : [
                  124648691,
                  "624812"
                ]
              }
            ]
          }
        }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    上面的请求会为每一个文档返回一个包含sort排序值的数组。这些sort排序值可以被用于 search_after 参数里以便抓取下一页的数据。比如,我们可以使用最后的一个文档的sort排序值,将它传递给 search_after 参数:

    GET twitter/_search
    {
        "size": 10,
        "query": {
            "match" : {
                "title" : "es"
            }
        },
        "search_after": [124648691, "624812"],
        "sort": [
            {"date": "asc"},
            {"_id": "desc"}
        ]
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14

    注意:当我们使用search_after时,from值必须设置为0或者-1。

    **search_after缺点是不能够随机跳转分页,只能是一页一页的向后翻,并且需要至少指定一个唯一不重复字段来排序。**它与滚动API非常相似,但与它不同,search_after参数是无状态的,它始终针对最新版本的搜索器进行解析。因此,排序顺序可能会在步行期间发生变化,具体取决于索引的更新和删除。

  • 相关阅读:
    微信视频号怎么下载别人的视频
    智慧交通与车载数据的聚合路由器通信方案
    基于 JMeter API 开发性能测试平台
    Composer 安装与使用
    Python 之Scikit-learn(七) -- Scikit-learn 中的不同度量指标详细介绍
    JAVA基础(四十九)——自定义泛型
    大数据之Hadoop集群搭建(4个节点)
    文心一言 VS 讯飞星火 VS chatgpt (115)-- 算法导论10.2 8题
    谁是下一个丘成桐?产业界也开始关心这事儿了
    STM32F4_I2C(从机EEPROM/MPU-6050)协议详解
  • 原文地址:https://blog.csdn.net/bhegi_seg/article/details/126359300