Elasticsearch分页的坑

1.from + size
传统的from+size的方法在数据量小时，客户端获取要求有顺序时可以使用。
2.scroll + scan
在数据量太大，尤其是需要遍历全部数据时，应该使用这种方式。
原因：假设每页大小为10，在获取第1001页时，es实际上是向每个分片发送请求第10000到10010的数据，每个分片会进行一次排序，如果有十个分片，就会获取所有分片的前10个，因此给CPU和内存造成很大的压力。使用scroll方式，es生成一个快照，并维护一个scroll_id，相当于一个索引下标，这个id有个有效期，在有效期内每次获取都会递增。

3.scanning scroll 查询与 standard scroll 查询有几点不同：
A scanning scroll 查询结果没有排序，结果的顺序是doc入库时的顺序；
A scanning scroll 查询不支持聚合
A scanning scroll最初的查询结果的“hits”列表中不会包含结果
A scanning scroll 最初的查询中如果设定了“size”，这个“size”是设定每个分片（shard）的数量，也就是说如果设定size=3，而有5个shard，每次返回结果的最大值就是3*5=15。

特别说明：

ES的分页索引时从0开始，而PageHelper的分页从1开始。前端一直默认的是1，从而导致那不导ES引擎中的商品数据(一定要注意这里的分页其实位置是0，而不是1,如果不小心写成1，会导致永远找不到自己查询的数据，因为即便是的第1页，由于ES分页索引其实位置是0，查询时起始索引位置设置为1查的是第2页 ，肯定是找不到第1页的数据的 ！！！)