Elasticsearch 8.X DSL 如何优化更有助于提升检索性能?

Posted 铭毅天下

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Elasticsearch 8.X DSL 如何优化更有助于提升检索性能?相关的知识,希望对你有一定的参考价值。

1、企业级实战 DSL(数据已经脱敏)

2、大家可以看一下,能发现哪些问题?

根据我的实战和咨询经验,我发现如下几个问题。

当然,这是在和球友交流确认问题之后总结出来的。

2.1 问题1:bool 组合嵌套过深。

官方实际是有参数来约束的,indices.query.bool.max_nested_depth——bool 最大支持的嵌套层数是 20,并且过大的嵌套层数会导致“堆栈溢出”异常问题。

那 bool 组合嵌套越深是不是越慢呢?

我拿 228 万+的微博数据(JMeter 模拟100用户并发)作为样例索引数据进行验证。

  • 实验1:嵌套 10 层;执行 5 次,平均耗时:835 ms。

  • 实验2:嵌套 2 层;执行 5 次,平均耗时:674.8 ms。

对比看实验 2 执行查询较实验 1 的查询要快!

其实,初步结论是嵌套越深,执行越慢!

2.2 问题2:大量使用 wildcard 查询。

我之前血淋淋的教训告诉大家,非必要不使用 wildcard !

尤其数据量大的场景。

参见:Elasticsearch 警惕使用 wildcard 检索!然后呢?

依然拿 228 万+的微博数据(JMeter 模拟 100 用户并发)作为样例索引数据进行验证。

检索语句如下:

使用:match_phrase 短语匹配较使用 wildcard 模糊匹配效率提升:6.34 倍!

初步结论:非必要,不使用  wildcard。

2.3 问题3:"track_total_hits": 2147483647 没有必要搞这么大?

认知前提:Elasticsearch 中 max_result_window 这个参数大家比较熟悉,就是允许 from + size 翻页检索命中的最多文档数为:10000 条记录。

那么问题来了,如果命中数据量超过 10000万怎么办?

  • 一方面:我们可以修改:max_result_window 的默认值,但默认值修改要慎之又慎。

  • 另一方面:我们可以在执行检索的时候加上 track_total_hits 这个参数。

问题来了?什么场景需要单独设置 track_total_hits 参数?什么时候不需要呢?

  • 场景一:当索引设置层面设置了 index.sort 后,本质上写入的数据已经进行了预排序。如果只对前 N 个结果感兴趣,而不关心总命中数,可以简单地将 track_total_hits 设置为 false。

  • 场景二:针对 filter 过滤检索的场景,用户仅关注是否存在,不关注相关性。可以分为如下两种情况:

(1)情况2.1:将 track_total_hits 设置为 false,检索结果将不再返回 hits.total 的具体值。

(2)情况2.2:将 track_total_hits 设置为给定的 N, 那么每个分片待召回 N 个文档后就返回。除此之外的业务场景,建议慎用 track_total_hits:true 的场景。

我们同样对比一下性能。

初步结论:加上 track_total_hits,检索会变慢,我们要结合业务场景谨慎使用。

2.4 问题4:track_scores 确认是否必要使用!

track_scores 含义如下:When sorting on a field, scores are not computed. By setting track_scores to true, scores will still be computed and tracked.

也就是说这是个和排序相关的参数,如果走排序,就不计算评分。

如果想对排序加上评分处理,需要加这个参数。

2.5 问题5:"_source": "includes": [ 确认是否必须

其实有更快的建模方式,就是 store 设置 true 对字段单独建模。当然,这涉及到数据建模和写入。

_source 下召回的数据字段越多,肯定会越慢。暂且不说别的,网络传输的角度就可见一斑。

网络传输中,网速一定,但是 _source 字段多,意味着传输的字节数多,必然会越慢。

还是拿微博数据验证一下,

初步结论,仅指定一个字段比全部默认字段(10个以上),影响时间要快很多!

2.6 问题6:match,match_phrase, wildcard 都混合使用,考虑分词问题解决。

推荐:字词混合索引方案。

一个线上问题引发的思考——Elasticsearch 8.X 如何实现更精准的检索?

2.7 问题7:建议线上使用复杂DSL,可以使用性能测试验证一下。

文中 JMeter 测试工具使用,推荐视频:

https://t.zsxq.com/0853Q9epD

3、小结

不要小瞧 DSL 的使用,不要堆砌一些不太理解的参数不加验证直接用于实战环境,后面的风险会变得很大。

DSL 的调优其实直接影响到检索性能。

大家对文中的 DSL 还有哪些调优建议,欢迎留言交流!

推荐阅读

  1. 全网首发!从 0 到 1 Elasticsearch 8.X 通关视频

  2. 重磅 | 死磕 Elasticsearch 8.X 方法论认知清单(2022年国庆更新版)

  3. 如何系统的学习 Elasticsearch ?

  4. esrally 如何进行简单的自定义性能测试?

  5. Elasticsearch 性能调优指南——推荐实战 DSL

  6. 让Elasticsearch飞起来!——性能优化实践干货

更短时间更快习得更多干货!

和全球 1800+ Elastic 爱好者一起精进!

比同事抢先一步学习进阶干货!

以上是关于Elasticsearch 8.X DSL 如何优化更有助于提升检索性能?的主要内容,如果未能解决你的问题,请参考以下文章

Elasticsearch 性能调优指南——推荐实战 DSL

Elasticsearch 8.X 检索实战调优锦囊 001

Elasticsearch 8.X 检索实战调优锦囊 001

Elasticsearch 8.X 检索实战调优锦囊 001

如何记录或打印被调用的 python elasticsearch-dsl 查询

我可以将 elasticsearch-dsl 的 IpRange 子类化以供 django-elasticsearch-dsl 使用吗?