ES性能优化最佳实践- 检索性能提升30倍！_交互

前言：检索性能问题

复杂性查询的挑战：当涉及大量检索关键词和多字段检索时，查询变得复杂，需要更多计算资源来处理这些复杂的查询。这会导致性能下降。
脚本排序开销：使用脚本排序可以在排序时进行自定义计算，但脚本的执行会增加额外的计算负担，尤其在大规模数据集上。
分片和节点负载：elasticsearch分布式架构依赖于分片和节点，如果查询请求分布不均匀或某些节点负载过重，性能问题可能会显著增加。
内存和磁盘资源：大规模查询需要更多的内存和磁盘资源来存储索引和数据，因此，硬件资源的配置可能成为性能瓶颈。

一、综合排序检索性能提升

1.1 性能提升效果

优化前后响应时间如下图1所示

图1

1.1.1 性能对比说明

其中横轴为普通检索场景，由检索时间范围和检索关键词个数组成。纵轴是请求平均响应时间，单位为秒。
在坐标轴上，红色代表的是性能优化前的请求响应时间，绿色代表的是优化后的请求响应时间。黑色虚线代表的是目标线，目标为，单次请求在5s内。

1.1.2 响应时间影响因素：

检索资源越多（服务器），响应时间越短。
检索时间范围越大（一次检索数据越多），响应时间越长。目前支持最大的检索时间跨度为3个月。
检索关键词越多，响应时间越长。目前能够给业务开放支持的是 100个检索词。

1.1.3 优化后效果

整体性能提升效果明显，提升在 1~ 30倍。
其中对于慢查询提升效果更好。对于检索时间范围越长，效果提升越好；对于检索关键词越多，效果提升越好。
最终的检索效果，检索关键词小于等于50个，响应时间可以控制在5s内，能够达到目标。其中只有检索时间跨度到3个月，检索关键词100无法达到5s内，目前是7s。

1.3 测试数据说明

性能提升前后测试数据如下图2：

测试对比数据由测试组同事提供。
测试接口为服务总线生产环境，检索逻辑为实际的业务检索条件。响应时间略大于es的响应时间。其中有0.3~0.5花在网络传输上。
其中提升前，是指综合排序，使用脚本实现，是闻海2.0实现思路。提升后是指使用cutting off机制，对搜索进行优化。

图2

1.4 关于综合排序说明

综合排序，是业务上使用最频繁的一种数据排序方式，也是默认的排序方式。其可以结合多个字段以及es的bm25相关性分数，做一个综合的排序。在实现上，使用script提取每一条数据的n个字段，然后计算一个分数，并和es的相关性分数做融合。

其最大的优点是召回的数据质量好，可以满足相关性的排序效果。

其最大的缺点是单次检索，有非常大的计算量，需要花费大量的资源。单个检索随着命中的数据变多，检索的时间复杂度增加，响应时间增加。使用script，需要对命中的所有数据做实时计算，计算过程需要将所需要的字段io出来，会产生大量小文件的io。由于每一条数据都需要做计算，索引，会占用大量的cpu资源，最终导致整体检索效果慢n倍，n>5。且随着关键词命中的结果集合增大，额外的io和cpu计算导致检索性能越来越差。50个检索词在三个月中，耗时39s。150个词在三个月数据中检索时间300s。

1.5 优化说明

1.5.1上述综合排序中的问题，归结为两点。

有脚本的存在，且需要实时计算。es中脚本排序是一种低性能的检索方式。
单次检索需要扫描全量的数据，且要对命中的数据做计算。单次检索复杂度高。其中最大检索时间跨度下，全部数据约450亿数据。最大检索关键词数下，100个检索关键词or的逻辑，能够命中上亿的数据。

1.5.2 针对问题，提出解决方案：

分数预处理机制：对于多个要参与排序的字段分数，可以提前计算好，用一个额外的字段承接此分数。此操作可避免实时计算，从io多个字段，变为io 一个字段。如下图所示，在数据处理层，在数据入es前，通过对数据的预处理，计算文档的质量分数。利用es的插入排序能力，将高质量的文档在插入的时候放在最前边检索。