Search after解决ES深度分页问题

文章目录

  • [1、search_after 的作用和意义](#1、search_after 的作用和意义)
  • [2、search_after 的工作原理](#2、search_after 的工作原理)
  • [3、search_after 的使用方法](#3、search_after 的使用方法)
  • 4、注意事项
  • 5、与传统分页的对比
  • 6、总结

search_after 是 Elasticsearch 中用于实现深度分页的一种机制。相比于传统的 from 和 size 分页方式,search_after 更适合处理大数据集的分页查询,因为它避免了深度分页带来的性能问题。

1、search_after 的作用和意义

传统分页的问题

在 Elasticsearch 中,使用 from 和 size 进行分页时,每次查询都需要从索引的第一个文档开始扫描,直到找到 from 指定的位置。对于深度分页(例如 from=10000, size=10),这种方式会导致性能急剧下降,因为需要扫描大量文档。

search_after 的优势

  • 性能优化:search_after 通过基于排序值的游标机制,避免了从头扫描文档的开销。

  • 适合大数据集:特别适合需要分页查询大量数据的场景。

  • 实时性:search_after 是基于实时数据的,能够反映索引的最新状态。

适用场景

  • 需要分页查询大量数据(例如日志数据、时间序列数据)。

  • 需要实现"无限滚动"或"加载更多"功能。

  • 需要避免深度分页的性能问题。

2、search_after 的工作原理

search_after 的工作原理是基于排序字段的值。每次查询时,Elasticsearch 会返回一组排序值(sort 字段),下一次查询时可以使用这些值作为游标,从上次查询结束的位置继续查询。

注意事项

  • 必须指定一个或多个排序字段(sort)。

  • 排序字段的值必须是唯一的,否则可能会导致分页不准确。

  • 使用 search_after 时,from 参数必须设置为 0 或省略。

3、search_after 的使用方法

步骤

1:第一次查询:

  • 指定排序字段(例如 @timestamp 和 _id)。

  • 设置 size 参数,确定每页返回的文档数量。

  • 不设置 search_after 参数。

2:后续查询:

  • 使用上一次查询返回的最后一个文档的排序值作为 search_after 参数。

  • 继续指定相同的排序字段和 size 参数。

示例

假设有一个索引 logs,存储日志数据,字段包括 @timestamp 和 message。我们需要按时间顺序分页查询日志。

第一次查询

json 复制代码
GET /logs/_search
{
  "size": 10,
  "sort": [
    { "@timestamp": "asc" },
    { "_id": "asc" }
  ]
}

响应结果

json 复制代码
{
  "hits": {
    "hits": [
      {
        "_id": "1",
        "_source": {
          "@timestamp": "2023-10-01T00:00:00Z",
          "message": "Log entry 1"
        },
        "sort": [ "2023-10-01T00:00:00Z", "1" ]
      },
      {
        "_id": "2",
        "_source": {
          "@timestamp": "2023-10-01T00:01:00Z",
          "message": "Log entry 2"
        },
        "sort": [ "2023-10-01T00:01:00Z", "2" ]
      },
      ...
    ]
  }
}

第二次查询

使用第一次查询的最后一个文档的排序值作为 search_after 参数:

json 复制代码
GET /logs/_search
{
  "size": 10,
  "sort": [
    { "@timestamp": "asc" },
    { "_id": "asc" }
  ],
  "search_after": [ "2023-10-01T00:01:00Z", "2" ]
}

响应结果

json 复制代码
{
  "hits": {
    "hits": [
      {
        "_id": "3",
        "_source": {
          "@timestamp": "2023-10-01T00:02:00Z",
          "message": "Log entry 3"
        },
        "sort": [ "2023-10-01T00:02:00Z", "3" ]
      },
      {
        "_id": "4",
        "_source": {
          "@timestamp": "2023-10-01T00:03:00Z",
          "message": "Log entry 4"
        },
        "sort": [ "2023-10-01T00:03:00Z", "4" ]
      },
      ...
    ]
  }
}

4、注意事项

  • 排序字段的唯一性:如果排序字段的值不唯一,可能会导致分页不准确。因此,通常需要结合 _id 或其他唯一字段进行排序。

  • 实时性:search_after 是基于实时数据的,因此在分页过程中,如果有新文档插入或旧文档删除,可能会导致分页结果不一致。

  • 性能优化:尽量选择高效的排序字段(例如数值字段或日期字段),避免使用文本字段进行排序。

5、与传统分页的对比

特性 fromsize 分页 search_after 分页
性能 深度分页性能差 深度分页性能好
适用场景 小数据集分页 大数据集分页
实时性 基于查询时的快照 基于实时数据
实现复杂度 简单 需要维护排序值
内存占用 高(需要缓存大量文档) 低(仅缓存排序值)

6、总结

search_after 是 Elasticsearch 中用于实现高效深度分页的机制。它通过基于排序值的游标机制,避免了传统分页的性能问题,特别适合处理大数据集的分页查询。使用时需要注意排序字段的唯一性和实时性,并结合实际场景选择合适的排序字段。

相关推荐
大数据追光猿31 分钟前
Tree of Thought Prompting(思维树提示)
大数据·人工智能·深度学习·计算机视觉·语言模型
z26373056112 小时前
Git 面试问题,解决冲突
大数据·git·elasticsearch
lusklusklusk3 小时前
ES_用户管理之ElasticSearch 8.0创建用户,用户组,授权,查询权限和LDAP认证
大数据·elasticsearch·jenkins
Yee_mo3 小时前
helm部署metricbeat
elasticsearch·kubernetes·k8s·运维开发·devops
交响梦4 小时前
医院信息系统平台总体架构原则
大数据·数据库·人工智能·架构·健康医疗
闯闯桑4 小时前
Spark 中的Shuffle过程
大数据·开发语言·spark·php·scala
cyhysr4 小时前
大数据-spark3.5安装部署之免密登录
大数据
阿什么名字不会重复呢4 小时前
在本地跑通spark环境
大数据·ajax·spark
小白的白是白痴的白5 小时前
3.17 配置hadoop集群-理论准备
大数据·hadoop·分布式