ES 深度分页scroll使用方式

我们知道ES对于from+size的个数是有限制的，二者之和不能超过1w。当所请求的数据总量大于1w时，可用scroll来代替from+size。

首次查询使用方式如下：

curl -XGET 'localhost:9200/twitter/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}
'

接下来的查询方式如下：

curl -XGET 'localhost:9200/_search/scroll?pretty' -H 'Content-Type: application/json' -d'
{
    "scroll" : "1m", 
    "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==" 
}
'

如果你对scroll取出的数据顺序没有要求的话，则可以对“_doc”进行排序，es对这种排序做了优化。使用方式如下：

curl -XGET 'localhost:9200/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
  "sort": [
    "_doc"
  ]
}
'

如果你想通过slice并行分片查询的话，可以这样设置：

curl -XGET 'localhost:9200/twitter/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
    "slice": {
        "id": 0, 
        "max": 2 
    },
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}
'
curl -XGET 'localhost:9200/twitter/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
    "slice": {
        "id": 1,
        "max": 2
    },
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}
'

两个请求可以同时运行。但是这样做会有个缺陷，内存占用较大，且第一次查询很慢。因为查询是O(N)的复杂度且每个slice占用N个bits，N是shard的总文档数。之后缓存的数据将加快查询。

为了避免上述情况，可以选择一个doc_values做slice，但是必须要确保这个field有以下特性：

1. Field必须是数字。
2. doc_values在这个field是启用的。
3. 每个文档应该包含一个值，如果有多个，则第一个被使用。
4. 该值在文档创建后不再改变。
5. 该值的基数很大，即取值范围很广。

curl -XGET 'localhost:9200/twitter/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
    "slice": {
        "field": "date",
        "id": 0,
        "max": 10
    },
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}
'

关于seach after和scroll的原理

在第一次查询时，记录上一次查询的位置，在接下来的查询中获取到上次查询的位置，接着查询。
比如说将查询order by time offset 0 limit 100，改写成order by time where time>0 limit 100，记录最后一个$time_max,接下来的查询order by time offset 100 limit 100，改写成order by time where time>$time_max limit 100。如此往复，可以看出scroll是一个常量查询延迟和开销，并无什么副作用。

关于scroll 和search after的详细信息，请看http://www.jianshu.com/p/91d03b16af77.

问题

scan被取消了，用sort _doc代替

https://www.elastic.co/guide/en/elasticsearch/reference/5.4/breaking_50_search_changes.html

对应到java api中，可用addSort("_doc", SortOrder.ASC)代替。

scroll查询时，scan类型scroll_id会变，普通查询scroll_id不会变

http://zcty5v5.xyz/2016/10/17/ES-scroll-issues/

同样的命令，curl scroll scroll_id不会变，但java scroll会变。还没找到原因。

 QueryBuilder qb = matchAllQuery();
 SearchResponse scrollResp = source_client.prepareSearch(index)
      .setScroll(new TimeValue(60000))
      .addSort(FieldSortBuilder.DOC_FIELD_NAME, SortOrder.ASC)
      .setQuery(qb)
      .setSize(5000).get();
    
curl localhost:9200/customer/_search?scroll=3m -d '{"size":50,"sort":[{"_doc":{"order":"asc"}}],"query":{"match_all":{}}}'