分页
// 从第一条开始,获取两条数据 GET /people/test/_search { "from": 0, "size": 2 } // 可以先查询,再分页 GET /people/test/_search { "query": { "match": { "name": "lilei1" } }, "from": 0, "size": 1 }
排序
排序处理:【sort与query同级别,是一个数组,里面可以有多个排序参数,参数以{"FIELD":{"order":"desc/asc"}}为格式】 GET /people/test/_search { "query": { "match_all": {} }, "sort": [ { "age": { "order": "desc" } } ] }
对于分页和排序,需要共同面对一个问题:
首先,你要想到一个索引中的数据是散落在多个分片上的,你如何确定另一个分片上的数据与其他分片上的顺序问题?,比如可能A分片上的有数值为1和数值为3的数据,而B分片上有数值为2和数值为4的数据,所以B分片的部分数据与A分片数据的大小是不确定的。那么排序的时候怎么处理这些散落的数据呢?(就算是依据相对度来排序,这个时候散落的数据的相关度也是不太好确定的)
分页需要面对的问题也同样是因为数据散落的而不好排序的问题,因为分页也是要排序的,默认是按相关度排序。因为散落的数据的值的大小不确定,所以就需要把所有可能的数据取出来排完序再分页,这就会导致需要取出远远超出“页数”的数据来计算。
有两个primary shard(命名为A和B),现在要取第1000页的数据,假设每一页10条记录,那么理论上是只需要取第10000到第10010条记录出来即可。
但这时候我们并不知道A和B中的_score的大小如何,可能A中的最小的_score要比B中的最大的_score都要大,反过来也有可能,(所以我们并不能说仅仅从A和B中分别取10000到10010出来进行比较即可,我们需要对前面的数据都进行比较,以避免最小的_score都比另一个shard上的_score大的情况),为了确保数据的正确性,我们需要从A和B中都取出1到10010的数据来进行排序比较,然后再取出里面的10000到10010条。
所以,你看到了,我们只是为了拿十条数据,竟然要查10010数据出来。这就是deep paging了。
除了上述的内容,还有比较重要的内容应该是滚动查询,滚动查询有点类似分页查询,但它会提前准备好数据,我暂时没想好放在哪里讲合适,可能会在后面写,也有可能某一天补充在这里。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)