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

相关推荐
每日新鲜事几秒前
热销复盘:招商林屿缦岛203套售罄背后的客户逻辑分析
大数据·人工智能
AI架构全栈开发实战笔记1 小时前
Eureka 在大数据环境中的性能优化技巧
大数据·ai·eureka·性能优化
AI架构全栈开发实战笔记1 小时前
Eureka 对大数据领域服务依赖关系的梳理
大数据·ai·云原生·eureka
自挂东南枝�1 小时前
政企舆情大数据服务平台的“全域洞察中枢”
大数据
Dragon~Snow2 小时前
Linux Centos9 安装 Elasticsearch
linux·elasticsearch·jenkins
熊延2 小时前
麒麟V10系统安装部署elasticsearch
linux·运维·服务器·elasticsearch·搜索引擎·全文检索
weisian1512 小时前
Elasticsearch-1--什么是ES?
大数据·elasticsearch·搜索引擎
LaughingZhu2 小时前
Product Hunt 每日热榜 | 2026-02-08
大数据·人工智能·经验分享·搜索引擎·产品运营
玄同7652 小时前
Git常用命令指南
大数据·git·elasticsearch·gitee·github·团队开发·远程工作
瑞华丽PLM4 小时前
电子行业国产PLM系统功能差异化对比表
大数据·plm·国产plm·瑞华丽plm·瑞华丽