Java架构直通车——ElasticSearch深度分页解决方案_es深度分页解决方案 - CSDN文库

88 浏览量更新于2023-03-03 评论 1 收藏 112KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

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

文章目录文章目录分页查询深度分页深度分页解决方案

分页查询分页查询

分页查询是这样的：

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/_settings

PUT /shop/_settings

{

"index.max_result_window": "20000"

}

方案方案3:使用使用scroll搜索搜索

滚动搜索可以先查询出一些数据，然后再紧接着依次往下查询。在第一次查询的时候会有一个滚动id，相当于一个锚标记，随后再次滚动搜索会需要上一次搜索的锚标记，根据这个

进行下一次的搜索请求。每次搜索都是基于一个历史的数据快照，查询数据的期间，如果有数据变更，那么和搜索是没有关系的，搜索的内容还是快照快照中的数据。

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余1页未读，立即下载

评论0

weixin_38557515

粉丝: 5
资源: 918

会员权益专享

图片转文字

全年可省5，000元立即开通

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈