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

相关推荐
byte轻骑兵1 小时前
大数据时代时序数据库选型指南:深度解析与 Apache IoTDB 实践
大数据·apache·时序数据库
NPE~2 小时前
[docker/大数据]Spark快速入门
大数据·分布式·docker·spark·教程
的小姐姐3 小时前
AI与IIOT如何重新定义设备维护系统?_璞华大数据Hawkeye平台
大数据·人工智能
TDengine (老段)4 小时前
TDengine IDMP 最佳实践
大数据·数据库·物联网·ai·时序数据库·tdengine·涛思数据
彬彬醤4 小时前
Mac怎么连接VPS?可以参考这几种方法
大数据·运维·服务器·数据库·线性代数·macos·矩阵
星域智链4 小时前
车载 GPS 与手机导航的终极对决:谁在复杂路况下更胜一筹?
大数据·科技·ai
MaxCode-16 小时前
单智能体篇:Prompt工程艺术
大数据·人工智能·prompt
Elasticsearch7 小时前
传统 AI 与生成式 AI:IT 领导者指南
elasticsearch
计算机毕设残哥8 小时前
大数据毕业设计推荐:基于Hadoop+Spark的手机信息分析系统完整方案
大数据·hadoop·课程设计
Hello.Reader9 小时前
Elasticsearch Rails 集成(elasticsearch-model / ActiveRecord)
大数据·elasticsearch·jenkins