Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API

一序

本文属于极客时间Elasticsearch核心技术与实战学习笔记系列。

二分页

2.1 From / Size

默认情况下，查询按照相关度算分排序，返回前 10 条记录
容易理解的分页方案
- From ：开始位置
- Size：期望获取文档的总数

这里理解下：我只需要查询size条数据，而es则需要执行from+size条数据然后处理后返回。所以有很大的开销。

2.2 分布式系统中深度分页的问题

ES 天生就是分布式，查询信息，但是数据分别保存在多个分片，多台机器，ES 天生就需要满足排序的需要（按照相关性算分）
当一个查询：From = 990 ，Size =10

会在每个分片上先获取 1000 个文档。然后，通过 Coordinating Node 聚合所有结果。最后在通过排序选取前 1000 个文档
页数越深，占用内容越多。为了避免深度分页带来的内存开销。ES 有个设定，默认限定到 10000 个文档

2.3 demo

超出范围，会报错

3 Search After 避免深度分页的问题

避免深度分页的性能问题，可以实时获取下一页文档信息
- 不支持指定页数（From）
- 不能往下翻
第一步搜索需要指定 sort，并且保证值是唯一的（可以通过加入_id 保证唯一性）
然后使用上一次，最后一个文档的 sort 值进行查询

3.1 demo

数据准备：

#Scroll API
DELETE usersPOST users/_doc
{"name":"user1","age":10}POST users/_doc
{"name":"user2","age":11}POST users/_doc
{"name":"user2","age":12}POST users/_doc
{"name":"user2","age":13}

执行查询

针对返回的结果wkD_8HIBYdMHFwfFArwf，放到search_after。这样：

可以看到通过设置search_after的值，是可以避免深度分页的。

3.2Search After 是如何解决深度分页的问题

假设 Size 是 10
当查询 990 -1000
通过唯一排序值定位，将每次要处理的文档都控制在 10（避免性能开销）

看到这里，如果你熟悉MySQL，那么自然也会想到MySQL的分页也可以采取类似的办法来避免offset导致的分页的尾页慢。

4 Scoll API

创建一个快照，有新的数据写入以后，无法被查找
每次查询后，输入上一次的 Scroll Id

4.1demo

数据准备，重新插入3条数据

我们使用scroll 生成快照，时间是5分钟

再插入一条记录：

吧第一次的scroll id拷出来，这样执行查询，最终只能查出3条记录。

{"_scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAABjfgWNURvOERhUl9RV2U4U2stczl1RmZFQQ==","took" : 5,"timed_out" : false,"terminated_early" : true,"_shards" : {"total" : 1,"successful" : 1,"skipped" : 0,"failed" : 0},"hits" : {"total" : {"value" : 3,"relation" : "eq"},"max_score" : 1.0,"hits" : [ ]}
}

文档4 是快照产生之后插入的，是无法被查到的。

5 不同的搜索类型和使用场景

Regular

需要实时获取顶部的部分文档。例如查询最新的订单

Scorll

需要全部文档，例如导出全部数据

Pagination

From 和 Size
如何需要深度分页，则选用 Search After

***************************

理解很重要。

Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API相关推荐

《Elasticsearch核心技术与实战》笔记
<Elasticsearch核心技术与实战>笔记 1.Video1: 2.Video2: 3.Video3:简介及发展历史 4.Video4:家族成员 5.Video5:安装下载逻辑设计 ...
Redis核心技术与实战-学习笔记（二十九）：Redis并发控制
一.需要并发控制的原因 Redis不可避免的会遇到并发访问问题,比如多用户同时下单,就会对缓存在Redis中的商品库存并发更新,一旦有了并发操作,数据就会被修改,如果我们没有对并发写请求做好控制,就可 ...
Redis核心技术与实战-学习笔记（二十六）：缓存雪崩、击穿、穿透
一.缓存雪崩缓存雪崩:大量应用请求无法在Redis缓存中进行处理,应用请求频繁访问数据库,导致数据库压力激增. 产生原因: 缓存中有大量数据同时过期,导致大量请求无法得到处理数据保存在缓存中,并设 ...
Redis核心技术与实战-学习笔记（十五）：消息队列（Redis的解决方案）
一.消息队列消息队列:分布式系统必备的一个基础软件,能支持组件通信消息的快速读写 Redis本身支持数据的快速访问,满足消息队列的读写性能需求二.Redis适合做消息队列吗? 消息队列的消息存取需 ...
Redis核心技术与实战-学习笔记（五）内存快照RDB
一.为什么需要RDB AOF 方法优势:每次执行只需要记录操作命令,需要持久化的数据量不大.在进行写后日志只要不采用always(同步写回)的持久化策略就不会对性能造成太大影响. AOF方法劣势:AO ...
Kafka 核心技术与实战学习笔记（二十四）请求处理过程
一.请求/响应所有的请求都是通过 TCP 网络以 Socket 的方式进行通讯的. Apache Kafka自定义的请求协议: PRODUCE请求是用于生产消息的 FETCH请求是用于消费消息的 M ...
Redis核心技术与实战-学习笔记（七）哨兵机制
一.主库挂了,如何不间断服务? 主库挂了,需要运行一个新的主库:将从库切换为主库.这就涉及到三个问题: 主库真的挂了吗? 选择哪个从库作为主库? 如何把新主库相关信息通知给从库和客户端 Redis主从 ...
Redis核心技术与实战-学习笔记（三十五）Redis使用建议
键值对使用规范 key的命令规范,只有命名规范,才能提供可读性强,可维护性好的key,方便日常管理: value的设计规范,包括避免bigkey,选择高效序列化方法和压缩方法,使用整数对象共享池,数据 ...
Redis核心技术与实战-学习笔记（十四）：时间序列数据
一.时间序列数据时间序列数据:没有严格的关系模型,记录的信息可以表示成键和值的关系. (例如,一个设备ID对应一条记录): 时间序列数据的读写特点持续高并发写入,需要连续记录数万个设备的实时状态值 ...

Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API

一序

二分页

2.1 From / Size

2.2 分布式系统中深度分页的问题

2.3 demo

3 Search After 避免深度分页的问题

3.1 demo

3.2Search After 是如何解决深度分页的问题

4 Scoll API

4.1demo

5 不同的搜索类型和使用场景

Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API相关推荐

最新文章

热门文章

Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API

一 序

二 分页

2.1 From / Size

2.2 分布式系统中深度分页的问题

2.3 demo

3 Search After 避免深度分页的问题

3.1 demo

3.2Search After 是如何解决深度分页的问题

4 Scoll API

4.1demo

5 不同的搜索类型和使用场景

Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API相关推荐

最新文章

热门文章

一序

二分页