1. 返回指定的字段
- 考虑到性能问题,需要对搜索结果进行“瘦身”——指定返回的字段。
- 在ES中,通过
_source
子句可以设定返回结果的字段。_source
指向一个JSON数组,数组中的元素是希望返回的字段名称。
GET /hotel/_search { "_source": [ "title", "city" ], "query": { "term": { "city": { "value": "北京" } } } }
在搜索结果中,每个命中文档的_source
结构体中只包含指定的city
和title
两个字段的数据。
2. 结果计数
- 为提升搜索体验,需要给前端传递搜索匹配结果的文档条数,即需要对搜索结果进行计数。
- 针对这个要求,ES提供了
_countAPI
功能,在该API中,用户提供query子句用于结果匹配,ES会返回匹配的文档条数。
GET /hotel/_count { "query": { "term": { "city": { "value": "北京" } } } }
在搜索结果中,每个命中文档的_source
结构体中只包含指定的city
和title
两个字段的数据。
2. 结果计数
- 为提升搜索体验,需要给前端传递搜索匹配结果的文档条数,即需要对搜索结果进行计数。
- 针对这个要求,ES提供了
_countAPI
功能,在该API中,用户提供query子句用于结果匹配,ES会返回匹配的文档条数。
GET /hotel/_count { "query": { "term": { "city": { "value": "北京" } } } }
ES不仅返回匹配的文档数量,并且还返回和分片相关的元数据,如总共扫描的分片个数,以及成功、失败、跳过的分片个数等。
3. 结果分页
- 在实际的搜索应用中,分页是必不可少的功能。
- 在默认情况下,ES返回前10个搜索匹配的文档。
- 用户可以通过设置from和size来定义搜索位置和每页显示的文档数量,from表示查询结果的起始下标,默认值为0,size表示从起始下标开始返回的文档个数,默认值为10。
- 在默认情况下,用户最多可以取得10 000个文档,即from为0时,size参数最大为10 000,如果请求超过该值,ES返回报错信息。
- 对于普通的搜索应用来说,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. 性能分析
- 在使用ES的过程中,有的搜索请求的响应可能比较慢,其中大部分的原因是DSL的执行逻辑有问题。
- ES提供了profile功能,该功能详细地列出了搜索时每一个步骤的耗时,可以帮助用户对DSL的性能进行剖析。
- 开启profile功能只需要在一个正常的搜索请求的DSL中添加"profile":"true"即可。
- 在带有profile的返回信息中,除了包含搜索结果外,还包含profile子句,在该子句中展示了搜索过程中各个环节的名称及耗时情况。
- 需要注意的是,使用profile功能是有资源损耗的,建议用户只在前期调试的时候使用该功能,在生产中不要开启profile功能。
- 因为一个搜索可能会跨越多个分片,所以使用shards数组放在profile子句中。每个shard子句中包含3个元素,分别是id、searches和aggregations。
- id表示分片的唯一标识,它的组成形式为[nodeID][indexName][shardID]。
- searches以数组的形式存在,因为有的搜索请求会跨多个索引进行搜索。每一个search子元素即为在同一个索引中的子查询,此处不仅返回了该search子元素耗时的信息,而且还返回了搜索“金都”的详细策略,即被拆分成“title:金”和“title:都”两个子查询。同理,children子元素给出了“title:金”、“title:都”的耗时和详细搜索步骤的耗时。
- aggregations只有在进行聚合运算时才有内容。
- 如果查询比较复杂或者命中的分片比较多,profile返回的信息将特别冗长。在这种情况下,用户进行性能剖析的效率将非常低。
- 为此,Kibana提供了可视化的profile功能,该功能建立在ES的profile功能基础上。在Kibana的Dev Tools界面中单击Search Profiler链接,就可以使用可视化的profile了。
5. 评分分析
- 在使用搜索引擎时,一般都会涉及排序功能。
- 如果用户不指定按照某个字段进行升序或者降序排列,那么ES会使用自己的打分算法对文档进行排序。
- 有时我们需要知道某个文档具体的打分详情,以便于对搜索DSL问题展开排查。
- ES提供了explain功能来帮助使用者查看搜索时的匹配详情。
GET /${index_name}/_explain/${doc_id} { "query": { //搜索的具体逻辑 … } }