ES 分页查询
from+size分页
按照一般的查询流程来说，如果我想查询前10条数据：
- 客户端请求发给某个节点
- 节点转发给个个分片，查询每个分片上的前10条
- 结果返回给节点，整合数据，提取前10条
- 返回给请求客户端
该分页方式可以通过from+size的方式来进行实现。
from定义了目标数据的偏移值，size定义当前返回的事件数目。
这种分页方式只适合少量数据，因为随from增大，查询的时间就会越大，而且数据量越大，查询的效率指数下降
优点：from+size在数据量不大的情况下，效率比较高
缺点：在数据量非常大的情况下，from+size分页会把全部记录加载到内存中，这样做不但运行速递特别慢，而且容易让es出现内存不足而挂掉
比如要取第5001页的数据，在分页的时候，elasticsearch需要首先在每一个节点上取出50020的数据，然后和每一个节点的所有数据进行排序，取出排序后在50010到50020的数据，然后返回。这样随着数据量的增大，每次分页时排序的开销会越来越大。
两种方式，1. 使用滚动API；2. 直接设置[index.max_result_window]参数。
curl -XPUT http://127.0.0.1:9200/my_index/_settings -d '{ "index" : { "max_result_window" : 500000}}'my_index 更换为要修改默认参数值的索引，后面的数值也可以自己设置，比如数据量为两万多并且不会发生大的数量上的变化，可以把值设置为30000。
如果是在Kibana控制面板里面，则执行下面这段：
PUT my_index/_settings
{
"index":{
"max_result_window":500000
}
}ElasticSearch实际上更适合作为一个搜索的引擎，像这种分页查询遍历查询，实际上不是非常合适的。并且数值设置过大，会对机器造成压力，可能造成内存溢出等错误。
scroll深分页
ES为了避免深分页，不允许使用分页(from&size)查询10000条以后的数据，因此如果要查询第10000条以后的数据，要使用ES提供的 scroll(游标) 来查询
可以把 scroll 理解爲关系型数据库里的 cursor，因此，scroll 并不适合用来做实时搜索，而更适用于后台批处理任务，比如群发
scroll 具体分爲初始化和遍历两步
1、初始化时将所有符合搜索条件的搜索结果缓存起来，可以想象成快照；
GET fs/_search?scroll=3m
{
"query": {"match_all": {}},
"size": 3
}初始化的时候就像是普通的search一样
其中的scroll=3m代表当前查询的数据缓存3分钟
Size：3 代表当前查询3条数据
2、遍历时，从这个快照里取数据；
在遍历时候，拿到上一次遍历中的_scroll_id，然后带scroll参数，重复上一次的遍历步骤，直到返回的数据为空，表示遍历完成。
每次都要传参数scroll，刷新搜索结果的缓存时间，另外不需要指定index和type（不要把缓存的时时间设置太长，占用内存）。
游标可以增加性能的原因，是因为如果做深分页，每次搜索都必须重新排序，非常浪费，使用scroll就是一次把要用的数据都排完了，分批取出，因此比使用from+size还好
具体实例
1、初始化
请求
注意要在URL中的search后加上scroll=1m，不能写在request body中，其中1m表示这个游标要保持开启1分钟
可以指定size大小，就是每次回传几笔数据，当回传到没有数据时，仍会返回200成功，只是hits裡的hits会是空list
在初始化时除了回传_scroll_id，也会回传前100笔(假设size=100)的数据
request body和一般搜索一样，因此可以说在初始化的过程中，除了加上scroll设置游标开启时间之外，其他的都跟一般的搜寻没有两样 (要设置查询条件，也会回传前size笔的数据)
POST 127.0.0.1:9200/my_index/_search?scroll=1m
{
"query":{
"range":{
"createTime": {
"gte": 1522229999999
}
}
},
"size": 1000
}
返回结果
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAfv5-FjNOamF0Mk1aUUhpUnU5ZWNMaHJocWcAAAAAAH7-gBYzTmphdDJNWlFIaVJ1OWVjTGhyaHFnAAAAAAB-_n8WM05qYXQyTVpRSGlSdTllY0xocmhxZwAAAAAAdsJxFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbCcBZlZGUwSWpSVlJqeVJiN1dBWHNpUG1R",
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 84,
"max_score": 1,
"hits": [
{
"_index": "video1522821719",
"_type": "doc",
"_id": "84056",
"_score": 1,
"_source": {
"title": "三个院子",
"createTime": 1522239744000
}
}
....99 data
]
}
}
2、遍历数据
请求
使用初始化返回的_scroll_id来进行请求，每一次请求都会继续返回初始化中未读完数据，并且会返回一个_scroll_id，这个_scroll_id可能会改变，因此每一次请求应该带上上一次请求返回的_scroll_id
要注意返回的是_scroll_id，但是放在请求裡的是scroll_id，两者拼写上有不同
且每次发送scroll请求时，都要再重新刷新这个scroll的开启时间，以防不小心超时导致数据取得不完整
POST 127.0.0.1:9200/_search/scroll?scroll=1m
{
"scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB"
}
返回结果
如果没有数据了，就会回传空的hits，可以用这个判断是否遍历完成了数据
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB",
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 84,
"max_score": null,
"hits": []
}
}
优化scroll查询
在一般场景下，scroll通常用来取得需要排序过后的大笔数据，但是有时候数据之间的排序性对我们而言是没有关系的，只要所有数据都能取出来就好，这时能够对scroll进行优化
初始化
使用_doc去sort得出来的结果，这个执行的效率最快，但是数据就不会有排序，适合用在只想取得所有数据的场景
POST 127.0.0.1:9200/my_index/_search?scroll=1m
{
"query": {
"match_all" : {}
},
"sort": [
"_doc"
]
}
}
清除scroll
虽然我们在设置开启scroll时，设置了一个scroll的存活时间，但是如果能够在使用完顺手关闭，可以提早释放资源，降低ES的负担
DELETE 127.0.0.1:9200/_search/scroll
{
"scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB"
}