1. 返回指定的字段

1. 考虑到性能问题，需要对搜索结果进行“瘦身”——指定返回的字段。
2. 在ES中，通过_source子句可以设定返回结果的字段。_source指向一个JSON数组，数组中的元素是希望返回的字段名称。

GET /hotel/_search
{
  "_source": [
    "title",
    "city"
  ],
  "query": {
    "term": {
      "city": {
        "value": "北京"
      }
    }
  }
} 

在搜索结果中，每个命中文档的_source结构体中只包含指定的city和title两个字段的数据。

2. 结果计数

1. 为提升搜索体验，需要给前端传递搜索匹配结果的文档条数，即需要对搜索结果进行计数。
2. 针对这个要求，ES提供了_countAPI功能，在该API中，用户提供query子句用于结果匹配，ES会返回匹配的文档条数。

GET /hotel/_count
{
  "query": {
    "term": {
      "city": {
        "value": "北京"
      }
    }
  }
} 

在搜索结果中，每个命中文档的_source结构体中只包含指定的city和title两个字段的数据。

2. 结果计数

1. 为提升搜索体验，需要给前端传递搜索匹配结果的文档条数，即需要对搜索结果进行计数。
2. 针对这个要求，ES提供了_countAPI功能，在该API中，用户提供query子句用于结果匹配，ES会返回匹配的文档条数。

GET /hotel/_count
{
  "query": {
    "term": {
      "city": {
        "value": "北京"
      }
    }
  }
} 

ES不仅返回匹配的文档数量，并且还返回和分片相关的元数据，如总共扫描的分片个数，以及成功、失败、跳过的分片个数等。

3. 结果分页

1. 在实际的搜索应用中，分页是必不可少的功能。
2. 在默认情况下，ES返回前10个搜索匹配的文档。
3. 用户可以通过设置from和size来定义搜索位置和每页显示的文档数量，from表示查询结果的起始下标，默认值为0，size表示从起始下标开始返回的文档个数，默认值为10。
4. 在默认情况下，用户最多可以取得10 000个文档，即from为0时，size参数最大为10 000，如果请求超过该值，ES返回报错信息。
5. 对于普通的搜索应用来说，size设为10 000已经足够用了。如果确实需要返回多于10 000条的数据，可以适当修改max_result_window的值。

PUT /hotel/_settings
{
 "index": {
   "max_result_window": 20000
 }
} 

6.注意，如果将配置修改得很大，一定要有足够强大的硬件作为支撑。

7.作为一个分布式搜索引擎，一个ES索引的数据分布在多个分片中，而这些分片又分配在不同的节点上。一个带有分页的搜索请求往往会跨越多个分片，每个分片必须在内存中构建一个长度为from+size的、按照得分排序的有序队列，用以存储命中的文档。然后这些分片对应的队列数据都会传递给协调节点，协调节点将各个队列的数据进行汇总，需要提供一个长度为number_of_shards*(from+size)的队列用以进行全局排序，然后再按照用户的请求从from位置开始查找，找到size个文档后进行返回。基于上述原理，ES不适合深翻页。什么是深翻页呢？简而言之就是请求的from值很大。

当深翻页的请求过多时会增加各个分片所在节点的内存和CPU消耗。尤其是协调节点，随着页码的增加和并发请求的增多，该节点需要对这些请求涉及的分片数据进行汇总和排序，过多的数据会导致协调节点资源耗尽而停止服务。

8.作为搜索引擎，ES更适合的场景是对数据进行搜索，而不是进行大规模的数据遍历。一般情况下，只需要返回前1000条数据即可，没有必要取到10 000条数据。如果确实有大规模数据遍历的需求，可以参考使用scroll模式或者考虑使用其他的存储引擎。

4. 性能分析

1. 在使用ES的过程中，有的搜索请求的响应可能比较慢，其中大部分的原因是DSL的执行逻辑有问题。
2. ES提供了profile功能，该功能详细地列出了搜索时每一个步骤的耗时，可以帮助用户对DSL的性能进行剖析。
3. 开启profile功能只需要在一个正常的搜索请求的DSL中添加"profile":"true"即可。
4. 在带有profile的返回信息中，除了包含搜索结果外，还包含profile子句，在该子句中展示了搜索过程中各个环节的名称及耗时情况。
5. 需要注意的是，使用profile功能是有资源损耗的，建议用户只在前期调试的时候使用该功能，在生产中不要开启profile功能。
6. 因为一个搜索可能会跨越多个分片，所以使用shards数组放在profile子句中。每个shard子句中包含3个元素，分别是id、searches和aggregations。
7. id表示分片的唯一标识，它的组成形式为[nodeID][indexName][shardID]。
8. searches以数组的形式存在，因为有的搜索请求会跨多个索引进行搜索。每一个search子元素即为在同一个索引中的子查询，此处不仅返回了该search子元素耗时的信息，而且还返回了搜索“金都”的详细策略，即被拆分成“title:金”和“title:都”两个子查询。同理，children子元素给出了“title：金”、“title：都”的耗时和详细搜索步骤的耗时。
9. aggregations只有在进行聚合运算时才有内容。
10. 如果查询比较复杂或者命中的分片比较多，profile返回的信息将特别冗长。在这种情况下，用户进行性能剖析的效率将非常低。
11. 为此，Kibana提供了可视化的profile功能，该功能建立在ES的profile功能基础上。在Kibana的Dev Tools界面中单击Search Profiler链接，就可以使用可视化的profile了。

5. 评分分析

1. 在使用搜索引擎时，一般都会涉及排序功能。
2. 如果用户不指定按照某个字段进行升序或者降序排列，那么ES会使用自己的打分算法对文档进行排序。
3. 有时我们需要知道某个文档具体的打分详情，以便于对搜索DSL问题展开排查。
4. ES提供了explain功能来帮助使用者查看搜索时的匹配详情。

GET /${index_name}/_explain/${doc_id} 
{ "query": 
 { //搜索的具体逻辑
   … 
 } 
}