分页查询

分页查询是这样的：

POST     /shop/_doc/_search
{"query": {"match_all": {}},"from": 0,"size": 10
}

不过，当查询是这样时，会报错：

POST     /shop/_doc/_search
{"query": {"match_all": {}},"from": 9999,"size": 10
}

报错结果如下：

{"error": {"root_cause": [{"type": "illegal_argument_exception","reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [10009]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}],
...

这种结果就是深度分页。

深度分页

深度分页其实就是搜索的深浅度，比如第1页，第2页，第10页，第20页，是比较浅的；第10000页，第20000页就是很深了。

这其实是ES限制了查询结果的大小，也就是限制了result window的大小。为什么会进行这样的限制呢，首先，我们的ES是分片的。

由于这个分片的存在，我们想要获得size:10,from:0的数据时，需要在0,1,2三个分片中，分别取出10个数据，然后再做排序。
而如果从size:10,from:9999开始，每个分片都会拿到10009条数据，然后集合在一起，总共是10009*3=30027条数据，针对30027数据再次做排序处理，最终会获取最后10条数据。这样做的代价太高了，会造成性能问题，会耗费内存和占用cpu。而且es为了性能，他不支持超过一万条数据以上的分页查询。

深度分页解决方案

方案1:限制分页最大数
其实我们应该避免深度分页操作（限制分页页数），比如最多只能提供100页的展示，从第101页开始就没了，毕竟用户也不会搜的那么深，我们平时搜索淘宝或者百度，一般也就看个10来页就顶多了。

譬如淘宝搜索限制分页最多100页，如下：

方案2:修改result_window
有时候，由于业务需要，我们不得不去搜索到10000条数据之后的内容，可以通过修改result_window来实现：

GET     /shop/_settingsPUT     /shop/_settings
{ "index.max_result_window": "20000"
}

方案3:使用scroll搜索
滚动搜索可以先查询出一些数据，然后再紧接着依次往下查询。在第一次查询的时候会有一个滚动id，相当于一个锚标记，随后再次滚动搜索会需要上一次搜索的锚标记，根据这个进行下一次的搜索请求。每次搜索都是基于一个历史的数据快照，查询数据的期间，如果有数据变更，那么和搜索是没有关系的，搜索的内容还是快照中的数据。

scroll=1m，相当于是一个session会话时间，搜索保持的上下文时间为1分钟。

POST    /shop/_search?scroll=1m
{"query": { "match_all": {}},  "sort" : ["_doc"], "size":  5
}

其返回结果如下：

{"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAAACgFmkxLWVTcGxRUkY2bmNRUnd4RWVXOEEAAAAAAAAAoRZpMS1lU3BsUVJGNm5jUVJ3eEVlVzhBAAAAAAAAAKIWaTEtZVNwbFFSRjZuY1FSd3hFZVc4QQ==","took": 17,"timed_out": false,"_shards": {"total": 3,"successful": 3,"skipped": 0,
...

利用返回的结果，我们进行如下查询：

POST    /_search/scroll  这里不能带index
{"scroll": "1m", "scroll_id" : "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAAACgFmkxLWVTcGxRUkY2bmNRUnd4RWVXOEEAAAAAAAAAoRZpMS1lU3BsUVJGNm5jUVJ3eEVlVzhBAAAAAAAAAKIWaTEtZVNwbFFSRjZuY1FSd3hFZVc4QQ=="
}

其结果为:

{"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAAACsFmkxLWVTcGxRUkY2bmNRUnd4RWVXOEEAAAAAAAAArhZpMS1lU3BsUVJGNm5jUVJ3eEVlVzhBAAAAAAAAAK0WaTEtZVNwbFFSRjZuY1FSd3hFZVc4QQ==","took": 45,"timed_out": false,"terminated_early": false,"_shards": {"total": 3,"successful": 3,"skipped": 0,"failed": 0},...

Java架构直通车——ElasticSearch深度分页解决方案相关推荐

京东面试题：ElasticSearch深度分页解决方案
前言 Elasticsearch 是一个实时的分布式搜索与分析引擎,在使用过程中,有一些典型的使用场景,比如分页.遍历等. 在使用关系型数据库中,我们被告知要注意甚至被明确禁止使用深度分页,同理,在 ...
Java架构直通车——锁分段技术：微信如何扛住 10 亿用户同时修改微信号？
文章目录引入从HashMap到ConcurrentHashMap的转变:理解锁分段技术 HashMap的死循环 ConcurrentHashMap的实现方式---锁桶(或段) Concurrent ...
ES的深度分页解决方案
索引:共4T,5个索引,共100亿条数据查询语句: { "query":{ "term":{ "app_s ...
ElasticSearch 深度分页详解
来源 | OSCHINA 社区作者 | 京东云开发者-何守优原文链接:https://my.oschina.net/u/4090830/blog/5593128 1 前言 ElasticSearc ...
java es scroll,Elasticsearch Scroll分页检索案例分享
Elasticsearch Scroll分页检索案例分享 1.准备工作 2.定义scroll检索dsl 首先定义一个简单的scroll dsl检索脚本 { ## 这里都是用常量在操作,实际场景中可以参 ...
Java架构直通车——如何准备可以提高面试成功率？
文章目录硬实力准备软实力准备硬实力准备 a.准备好数据结构和算法,这个是互联网技术岗面试必过的一关. 很多人在大学阶段就接触和学习了相关知识.但是要吃透重点,你还需要具备比较好的数学基础才能搞懂 ...
Java架构直通车——分布式唯一 ID生成方案
文章目录分布式ID的几种生成方案 UUID MySQL主键自增数据库自增ID改进方案雪花算法(SnowFlake) 雪花算法的优化 Redis自增id Zookeeper有序节点最近要做区块链 ...
Java架构直通车——秒杀系统分析和设计
文章目录秒杀系统业务特点 & 技术挑战架构原则 & 设计前端设计网关设计服务端设计数据库层设计服务重启与服务降级其他优化点案例:利用消息中间件和缓存实现简单的秒杀系 ...
zookeeper 密码_阿里资深JAVA架构带你深度剖析dubbo和zookeeper关系
为什么要用dubbo? 当网站规模达到了一定的量级的时候,普通的MVC框架已经不能满足我们的需求,于是分布式的服务框架和流动式的架构就凸显出来了. 单一应用架构当网站流量很小时,只需一个应用,将所有 ...

Java架构直通车——ElasticSearch深度分页解决方案

文章目录

分页查询

深度分页

深度分页解决方案

Java架构直通车——ElasticSearch深度分页解决方案相关推荐

最新文章

热门文章