es之search after

一，问题

es的分页查询基于from/size，存在深度分页问题。

比如from=10000，size=10时，es会从每个分片取出(10000 + 10)条记录，如果有10个分片，则总共要取出(10000 + 10)*10条数据，协调节点在内存中对这些数据进行排序，最终返回10条数据。

这种方式会耗费大量的系统资源，包括时间和空间。

二，search after

search after可以解决这个问题，search after会记住每次分页查询在每个分片的最后位置，当下一次查询时，会从上一次查询结束的位置开始查询，则每次每个分片的只需去除10个文档，总共取出（size * 分片数）即10*10个文档，排序后返回10条记录。

search after 在时间和空间上都能大量减少资源的消耗。

三，玩转search after

1，search after 不能指定页数，只能一页挨一页问下查。第一次查询时带上sort，返回最后一个文档的id。

GET kibana_sample_data_ecommerce/_search
{
  "from": 0,
  "size": 1,
  "sort": [
    {
      "order_date": {
        "order": "desc"
      },
      "_id":{
        "order": "desc"
      }
    }
  ]
}

2，下一次查询带上search after参数

GET kibana_sample_data_ecommerce/_search
{
  "from": 0,
  "size": 1,
   "query": {
     "match_all": {}
   },
   "search_after":[
          1592091936000,
          "_MhjQHIBgW5fcfR17HRJ"
    ],
    "sort": [
      {
        "order_date": {
          "order": "desc"
        },
        "_id": {
          "order": "desc"
        }
      }
    ]
}

三，scroll

scroll的原理是讲索引数据备份，每次记住最后一次查询的位置，下一次从最后一次位置开始查询。

1，第一次查询带scroll参数

GET kibana_sample_data_ecommerce/_search?scroll=5m
{
  "size": 1
}

查询结果会返回scroll_id，第二次查询会带上scroll_id，就能从上一次查询的末尾开始查询了。

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