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

相关推荐
森语林溪2 小时前
大数据环境搭建从零开始(十四)CentOS 7 系统更新源更换详解:阿里云镜像源配置完整指南
大数据·linux·运维·阿里云·centos
杂家3 小时前
Zookeeper完全分布式部署(超详细)
大数据·分布式·zookeeper
snakecy3 小时前
树莓派学习资料共享
大数据·开发语言·学习·系统架构
悠闲蜗牛�4 小时前
技术融合新纪元:深度学习、大数据与云原生的跨界实践
大数据·深度学习·云原生
武子康4 小时前
大数据-147 Java 访问 Apache Kudu:从建表到 CRUD(含 KuduSession 刷新模式与多 Master 配置)
大数据·后端·nosql
qq_5470261794 小时前
Canal实时同步MySQL数据到Elasticsearch
数据库·mysql·elasticsearch
snakecy5 小时前
信息系统项目管理师--论文case
大数据·学习·职场和发展·区块链
数据库安全6 小时前
世界互联网大会|美创科技无侵入数据安全多智体治理技术首发
大数据·人工智能·科技·数据安全
sniper-拒绝白嫖6 小时前
uniapp ios android 本地离线debug
大数据
森语林溪6 小时前
大数据环境搭建从零开始(十七):JDK 17 安装与配置完整指南
java·大数据·开发语言·centos·vmware·软件需求·虚拟机