es scroll slice深度分页

scroll

保持结果1分钟，查询结果花费的时间不能超过1分钟，不然此次生成的scrollid会失效，不能继续查询下一轮数据，每次查询的数据量可以用size定义，深度分页的实现就是先用1，2语句查询出结果，得到scroll_id，把这个值贴到3中执行查询，只要前后时间差在设定时间范围内scroll_id没有失效就可以实现翻页查询，每次查询都是接着上次查询最后的位置做查询。

在做大数据量的数据迁移的时候可以用深度分页

1.GET /_search?scroll=1m
{
  "sort": [
    "_doc"
  ]
}

2.GET /_search?scroll=1m
{
  "size":10  
  "sort": [
    "_doc"
  ]
}

3.

POST /_search/scroll 
{
    "scroll" : "1m", 
    "scroll_id" : "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAHZ5cFk45b0cxOGw3Ul9hVkVqd3VUVV9Ja1EAAAAAABtVqBZFUVV5OWxZX1RiRzFEUUtrVktrdWpnAAAAAAAY9q0WcU40Ulg5WGdUWEtpS0N4NkZFSVc2QQ==" 
}

slice

slice下的max值一般设置为所查询的索引分片数shards相等的个数，如果设置成比分片数大的第一次执行会花费比较长时间

相关官方解释如下，大致的意思是会有分配分片的计算过程：

 

If the number of slices is bigger than the number of shards the slice filter is very slow on the first calls, it has a complexity of O(N) and a memory cost equals to N bits per slice where N is the total number of documents in the shard. After few calls the filter should be cached and subsequent calls should be faster but you should limit the number of sliced query you perform in parallel to avoid the memory explosion.

可以看到sliceid是从0开始的，查询会根据max值将查询数据分成max个块来做查询，假如一共有90万数据，max=2,sliceid=0的块中有30万的数据，sliceid=1的块中有60万的数据，这样就降低了每个模块的查询总量，就像多线程执行查询一样

GET /twitter/_search?scroll=1m
{
    "slice": {
        "id": 0, 
        "max": 2 
    },
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}
GET /twitter/_search?scroll=1m
{
    "slice": {
        "id": 1,
        "max": 2
    },
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}