这是一个创建于 864 天前的主题，其中的信息可能已经有所发展或是发生改变。
es 分页查询可以用 from,size 实现。这种查询会有两个步骤
1.query
搜索请求被发送到某个节点时，这个节点就变成了协调节点，协调节点会转发请求到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果(ID 和排序值)到大小为 from + size 。如果有 n 个节点。协调节点会收到 n*(from + size) 的结果(ID 和排序值)。
2.fetch
协调节点 接收到 n*(from + size)的结果，将其全局排序。然后取当前页的数据，向相关的分片取完整的数据。
那 scroll 完成分页，不也要经历这两步？ 第二步 fetch 阶段不也是耗性能的深度分页吗？是不是说 scroll 第二部只做一次，然后将其全局的数据保存成一个快照。之后就不会取 fetch 。 但是 from ，size 是每次都要做 fetch ？
1.query
搜索请求被发送到某个节点时，这个节点就变成了协调节点，协调节点会转发请求到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果(ID 和排序值)到大小为 from + size 。如果有 n 个节点。协调节点会收到 n*(from + size) 的结果(ID 和排序值)。
2.fetch
协调节点 接收到 n*(from + size)的结果，将其全局排序。然后取当前页的数据，向相关的分片取完整的数据。
那 scroll 完成分页，不也要经历这两步？ 第二步 fetch 阶段不也是耗性能的深度分页吗？是不是说 scroll 第二部只做一次，然后将其全局的数据保存成一个快照。之后就不会取 fetch 。 但是 from ，size 是每次都要做 fetch ？
 |
1
sy20030260 2022-07-14 16:09:41 +08:00
仅就深度分页，scroll 的主要提升来自基于 scroll_id + server 端 context 实现的类似游标查询。
以分页大小 100 ，查询第 100 页为例：普通分页查询（ from/size ）需要对 0~100100 的数据进行查询和排序，而游标查询根据 scroll_id 可以不再需要查询和处理 0~10000 的数据，所以不存在深度分页下的性能问题。scroll 还是需要 query/fetch 等阶段，只是处理的数据量都减少了。 |
Select Language