elasticsearch学习笔记（二十三）——Elasticsearch 分页搜索以及深分页性能问题

在实际应用中，分页是必不可少的，例如，前端页面展示数据给用户往往都是分页进行展示的。

1、ES分页搜索

Elasticsearch分页搜索采用的是from+size。from表示查询结果的起始下标，size表示从起始下标开始返回文档的个数。
示例：

GET /test/_search?from=0&size=1

{
  "took" : 4,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "test",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "field1" : "value1",
          "field2" : "value2"
        }
      }
    ]
  }
}

2、深分页性能问题

什么是深分页（deep paging）?简单来说，就是搜索的特别深，比如总共有60000条数据，三个primary shard,每个shard上分了20000条数据，每页是10条数据，这个时候，你要搜索到第1000页，实际上要拿到的是10001~10010。

注意这里千万不要理解成每个shard都是返回10条数据。这样理解是错误的！

下面做一下详细的分析：
请求首先可能是打到一个不包含这个index的shard的node上去，这个node就是一个协调节点coordinate node，那么这个coordinate node就会将搜索请求转发到index的三个shard所在的node上去。比如说我们之前说的情况下，要搜索60000条数据中的第1000页，实际上每个shard都要将内部的20000条数据中的第10001~10010条数据，拿出来，不是才10条，是10010条数据。3个shard的每个shard都返回10010条数据给协调节点coordinate node，coordinate node会收到总共30030条数据，然后在这些数据中进行排序，根据_score相关度分数，然后取到10001~10010这10条数据，就是我们要的第1000页的10条数据。
如下图所示：

deep paging问题就是说from + size分页太深，那么每个shard都要返回大量数据给coordinate node协调节点，会消耗大量的带宽，内存，CPU。