es分页解决方案--深分页、浅分页

es分页解决方案--深分页、浅分页 一、ES 的 from size（浅分页）：

如果需要搜索分页，可以通过from size组合来进行。from表示从第几行开始，size表示查询多少条文档。from默认为0，size默认为10。

1、原理：

客户端请求发给某个节点节点转发给个个分片，查询每个分片上的前10条结果返回给节点，整合数据，提取前10条返回给请求客户端 2、分析

例如现有一个索引T，该索引接收到了一个查询请求，查询第3页，页大小100（也就是想要排序后第三页的100条数据），即设置了 from = 300, size =100 参数。

 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
    sourceBuilder.from((query.getPageNo() > 0 ? (query.getPageNo() - 1) : 0) * query.getPageSize());
    sourceBuilder.size(query.getPageSize());

​假设索引T有三个分片，​那么索引内部就会分别去三个分片里面，各召回 from + size = 300 + 100 = 400 个文档集合。

注意，这里有三个分片！所以一共召回了 400 * 3 = 1200 个文档到协调节点处。
从各个分片召回文档到内存后，协调节点结合全局信息进行一次排序，获取前400 的文档集；
最后，再基于这个 Top400 的文档集，从第300个文档起 (from) ，往后拿100个文档 (size)

这才是第3页，如果数据多时，我想查第200页的100条数据呢，共召回内存（20000+100）*3=…如果用户突然点到10000页呢…很明显，效率会低，内存也容易溢出。

3、限制

为了保护ES集群，防止单一请求数据集合过大，导致内存溢出，所以size的大小不能超过index.max_result_window这个参数的设置，默认为10,000（当然可以调整这个参数，但是治标不治本），单一请求数据大小一旦超过该阈值，便会出现如下报错，建议你去使用scroll：

Result window is too large, from + size must be less than or equal to: [10000] but was [500000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."

所以from size方式只适合数据量少的浅分页场景，单一请求数据集合小于10000的场景，但是实时分页查询。

二、scroll（ 深分页） 1、原理：

scroll查询原理是在第一次查询的时候一次性生成一个快照，根据上一次的查询的id（这是一个base64编码的长字符串）来进行下一次的查询，这个就类似于游标。

2、分析：

因为快照没有更新最新的索引，在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到，所以它不是“实时的”。

但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取，所以性能高。所以可以用来查询数据量多的场景，甚至全部数据。

遍历时，从这个快照里取数据；
在遍历时候，拿到上一次遍历中的_scroll_id，然后带scroll参数，重复上一次的遍历步骤，直到返回的数据为空，表示遍历完成。
每次都要传参数scroll，刷新搜索结果的缓存时间，不要把缓存的时时间设置太长，占用内存。

3、限制

scroll不支持跳页查询。
使用场景：对实时性要求不高的查询

scroll支持排序，scroll-scan不支持排序，是按照索引顺序返回，可以提高查询效率。
scroll-scan第一次查询只支持返回id，没有结果。