elastic search分页的问题

电玩女神 2022-12-24 06:58 101阅读 0赞

其实我觉得elastic search主要是用来搜索的，搜索嘛，自然大家都关注相关度高的排名靠前的结果，所以翻页越往后内容越不相关一般也就没人翻了，但架不住上级想把它当数据库用啊~百度谷歌之类的搜索引擎，我没记错翻页顶多也就让你翻70多页吧。

场景：传统的一个分页列表展示，按理说不是巨大量数据目前大概20w，如果只是RDBMS应该也没啥太大问题，but我们现在的列表展示数据是一个嵌套的巨复杂的数据，里面的字段属性可能来自各个微服务，所以列表的查询速度还是比较慢的（是不是设计的问题呢？服务拆分的特别细，感觉是不是关联度很高的放表到一个数据库join就好了呢，拆分成各种微服务各种不同数据库带来的弊端就是无法关联查询）。于是乎，就出现了这么个方案，每次把拼接好的显示数据同步过来塞到es，这样直接查es的数据就完美了，but还有尚未解决的问题（我们用的小众数据库，没有mysql那种现成的同步工具），数据无法完全及时同步。。。

继续聊分页，一搬如查询的条数不多用from+size分页即可，但是如果超过了10000条，就会报错" "reason": "Result window is too large, from + size must be less than or equal to: \[10000\] but was \[XXXXXX\]. 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.""es默认最多查10000条数据，这也是对性能的考虑，比如你想查前500条，有5个分片，es会每个分片拿前100个拼500个返回吗？显然这不太科学，极端例子就某学霸班级的最后一名，也可能吊打其他班的第一名，如果挑选年级学习好的同学，肯定也是把年级的学生合起来统计找排名靠前的。所以es会把每个分片的前500条也就是5\*500条，再从这里排序找出前500个。很多博客写解决方案是把max\_result\_window 值改大，这个方案不太好，过于简单粗暴，有的文章上来加好几个00000，稍微改大点还行，不知道用户量上来了对性能影响大不大啊？所以错误信息还写了一个方案，“See the scroll api”，那么scroll是个什么呢？

scoll即滚动，相当于一个游标，es官网说了，“游标查询会取某个时间点的快照数据，查询初始化之后索引上的任何变化会被它忽略”，从这里我们可以得知，es会保存一份快照数据让我们查询，既然是保存就需要消耗资源，既然是资源，那不用了自然要释放掉，而且他是某个时间点的，也就是说我先scroll之后对数据一顿增删改查操作，你查询的还是快照不会变。

scroll 用起来也比较简单，首先对你想查的“索引”发一个scroll请求，告诉索引我这个请求是scroll请求哦！我每次滚动要返回多少条（如 size=1000）！在多长时间内scroll有效，也就是快照保存多久(如scroll=1m)，示例

GET /myindex/_search?scroll=1m 
    {
        "query": { "match_all": {}},//条件 可无
        "sort" : ["_doc"], //排序 最好用默认效率高
        "size":  1000
    }

然后es会返回一个你要的结果(之前设置size条数)和一个scroll\_id，再用scroll\_id和过期时间请求 ip:port/\_search/scroll，注意这里url不用加索引，示例

GET /_search/scroll
    {
        "scroll": "1m", 
        "scroll_id" : "cXVlcnlUaGVuRmV0Y2g7NTsxMDk5NDpkUmpiR2FjOFNhNnlCM1ZDMWpWYnRROzEwOTk1OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MTA5OTM6ZFJqYkdhYzhTYTZ5QjNWQzFqVmJ0UTsxMTE5MDpBVUtwN2lxc1FLZV8yRGVjWlI2QUVBOzEwOTk2OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MDs="
    }

此时会继续返回滚动的结果和scroll\_id，每次拿返回的scroll\_id和过期时间循环直到滚动完，最后不要忘了清除滚动，当然超过过期时间也会自动清除，最好还是手动清除防止资源占用。

下面是使用java的RestHighLevelClient 进行scroll的完整示例。第一步，初始化scroll请求。第二步，while循环拉取数据。

final Scroll scroll = new Scroll(TimeValue.timeValueMinutes(1L));
    SearchRequest searchRequest = new SearchRequest("posts");
    searchRequest.scroll(scroll);
    SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();
    searchSourceBuilder.query(matchQuery("title", "Elasticsearch"));
    searchRequest.source(searchSourceBuilder);
    
    SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); 
    String scrollId = searchResponse.getScrollId();
    SearchHit[] searchHits = searchResponse.getHits().getHits();
    
    while (searchHits != null && searchHits.length > 0) { 
        
        SearchScrollRequest scrollRequest = new SearchScrollRequest(scrollId); 
        scrollRequest.scroll(scroll);
        searchResponse = client.scroll(scrollRequest, RequestOptions.DEFAULT);
        scrollId = searchResponse.getScrollId();
        searchHits = searchResponse.getHits().getHits();
    }
    
    ClearScrollRequest clearScrollRequest = new ClearScrollRequest(); 
    clearScrollRequest.addScrollId(scrollId);
    ClearScrollResponse clearScrollResponse = client.clearScroll(clearScrollRequest, RequestOptions.DEFAULT);
    boolean succeeded = clearScrollResponse.isSucceeded();

传统数据库可以实现跳页，比如一上来我就想看第100页的数据，但是scroll这里不适用，从使用过程也可以看出，需要每次拿本次响应scroll\_id请求下一次的数据，像手机下拉加载，需要一页一页请求，scroll是没办法指定也无法得知跳到哪页。

好想吐槽，有时产品和技术完全不在一个点上，有个1000多页的数据列表，很少直接翻最后几页的概率还是不大吧？另外翻页居然还有10/50/100/500这种可选，真的有人会看500条数据一页的列表吗？scroll适合拉取全部数据的场景，比如下载导出数据之类的功能。其实很多时候并没有完美的方案，用es作分页列表数据展示，也不能完全达到关系型数据库分页的全部效果，但是确实也提升了一些响应速度。可能到头看来，最初架构设计也有一些问题，有待不断改善吧。