1.from+size浅分页

“浅”分页可以理解为简单意义上的分页。它的原理很简单,就是查询前20条数据,然后截断前10条,只返回10-20的数据。这样其实白白浪费了前10条的查询。

  1. GET test_dev/_search
  2. {
  3. "query": {
  4. "bool": {
  5. "filter": [
  6. {
  7. "term": {
  8. "age": 28
  9. }
  10. }
  11. ]
  12. }
  13. },
  14. "size": 10,
  15. "from": 20,
  16. "sort": [
  17. {
  18. "timestamp": {
  19. "order": "desc"
  20. },
  21. "_id": {
  22. "order": "desc"
  23. }
  24. }
  25. ]
  26. }

其中,from定义了目标数据的偏移值,size定义当前返回的数目。默认from为0,size为10,即所有的查询默认仅仅返回前10条数据。
在这里有必要了解一下from/size的原理:
因为es是基于分片的,假设有5个分片,from=100,size=10。则会根据排序规则从5个分片中各取回100条数据数据,然后汇总成500条数据后选择最后面的10条数据。
做过测试,越往后的分页,执行的效率越低。总体上会随着from的增加,消耗时间也会增加。而且数据量越大,就越明显!

2.scroll 深分页

from+size查询在10000-50000条数据(1000到5000页)以内的时候还是可以的,但是如果数据过多的话,就会出现深分页问题。
为了解决上面的问题,elasticsearch提出了一个scroll滚动的方式。
scroll 类似于sql中的cursor,使用scroll,每次只能获取一页的内容,然后会返回一个scroll_id。根据返回的这个scroll_id可以不断地获取下一页的内容,所以scroll并不适用于有跳页的情景。

  1. GET test_dev/_search?scroll=5m
  2. {
  3. "query": {
  4. "bool": {
  5. "filter": [
  6. {
  7. "term": {
  8. "age": 28
  9. }
  10. }
  11. ]
  12. }
  13. },
  14. "size": 10,
  15. "from": 0,
  16. "sort": [
  17. {
  18. "timestamp": {
  19. "order": "desc"
  20. },
  21. "_id": {
  22. "order": "desc"
  23. }
  24. }
  25. ]
  26. }
  1. scroll=5m表示设置scroll_id保留5分钟可用。
  2. 使用scroll必须要将from设置为0。
  3. size决定后面每次调用_search搜索返回的数量

然后我们可以通过数据返回的_scroll_id读取下一页内容,每次请求将会读取下10条数据,直到数据读取完毕或者scroll_id保留时间截止:

  1. GET _search/scroll
  2. {
  3. "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAJZ9Fnk1d......",
  4. "scroll": "5m"
  5. }

注意:请求的接口不再使用索引名了,而是 _search/scroll,其中GET和POST方法都可以使用。
scroll删除
根据官方文档的说法,scroll的搜索上下文会在scroll的保留时间截止后自动清除,但是我们知道scroll是非常消耗资源的,所以一个建议就是当不需要了scroll数据的时候,尽可能快的把scroll_id显式删除掉。
清除指定的scroll_id:DELETE _search/scroll/DnF1ZXJ5VGhlbkZldGNo.....
清除所有的scroll:DELETE _search/scroll/_all

3.search_after 深分页

scroll 的方式,官方的建议不用于实时的请求(一般用于数据导出),因为每一个 scroll_id 不仅会占用大量的资源,而且会生成历史快照,对于数据的变更不会反映到快照上。
search_after 分页的方式是根据上一页的最后一条数据来确定下一页的位置,同时在分页请求的过程中,如果有索引数据的增删改查,这些变更也会实时的反映到游标上。但是需要注意,因为每一页的数据依赖于上一页最后一条数据,所以无法跳页请求。
为了找到每一页最后一条数据,每个文档必须有一个全局唯一值,官方推荐使用 _uid 作为全局唯一值,其实使用业务层的 id 也可以。

  1. GET test_dev/_search
  2. {
  3. "query": {
  4. "bool": {
  5. "filter": [
  6. {
  7. "term": {
  8. "age": 28
  9. }
  10. }
  11. ]
  12. }
  13. },
  14. "size": 20,
  15. "from": 0,
  16. "sort": [
  17. {
  18. "timestamp": {
  19. "order": "desc"
  20. },
  21. "_id": {
  22. "order": "desc"
  23. }
  24. }
  25. ]
  26. }
  1. 使用search_after必须要设置from=0。
  2. 这里我使用timestamp和_id作为唯一值排序。
  3. 我们在返回的最后一条数据里拿到sort属性的值传入到search_after。

使用sort返回的值搜索下一页:

  1. GET test_dev/_search
  2. {
  3. "query": {
  4. "bool": {
  5. "filter": [
  6. {
  7. "term": {
  8. "age": 28
  9. }
  10. }
  11. ]
  12. }
  13. },
  14. "size": 10,
  15. "from": 0,
  16. "search_after": [
  17. 1541495312521,
  18. "d0xH6GYBBtbwbQSP0j1A"
  19. ],
  20. "sort": [
  21. {
  22. "timestamp": {
  23. "order": "desc"
  24. },
  25. "_id": {
  26. "order": "desc"
  27. }
  28. }
  29. ]
  30. }

4.三种分页方式对比

分页方式 说明 优点 缺点 使用场景
from + size 最常用的分页方式,指定分页大小和偏移量可以直接获取到需要的数据。但是内存消耗特别大,而且速度也很一般,当我们指定from = 100000,size = 10 的时候,每个node都会取出top 100000的数据,再进行汇总排序,假设3个node,那么就需要取出3*100000条数据进行排序后,再取top10的数据进行返回。所以ES默认的from+size的限制设置为10000。在数据量到达十万级百万级的时候这种分页方式显然不合理。 数据量小的情况使用最方便,灵活性好,实现简单 内存消耗大,速度一般,数据量大的情况面临深度分页问题 数据量较小且能容忍深度分页问题
scroll 是一种快照的查询形式,快照一旦形成,本次滚动查询内便无法查出来新增的那些数据,而且scroll是无法进行排序的,也无法指定from,那么我们想查看指定页码的数据就必须将该页数据之前的全部数据取出来再进行丢弃,所以scroll一般用于
导出全量数据。
导出全量数据时性能最高 无法反应数据的实时性(快照版本),维护成本高,需要维护一个 scroll_id,并且不支持排序,只能按照文档id排序 海量(全量)数据的导出
search_after search_after有点类似scroll,但是和scroll又不一样,它提供一个活动的游标,通过上一次查询最后一条数据来进行下一次查询同时可以实时查询出来新增的数据且支持排序。但是不支持跳页查询,即每一次的查询都需要依赖上一次的查询结果,只能一页一页的往下翻。 查询性能最好,不存在深度分页问题,能够反映数据的实时变更 实现复杂,需要有一个全局唯一的字段,连续分页的实现会比较复杂,因为每一次查询都需要上次查询的结果 海量数据的分页(不支持跳页)