一、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，没有结果。
