高吞吐量查询优化
因业务扩展,es 内数据不断增多,查询压力也不断增大,直至已经严重影响用户体验,故需进行彻底整改。
在整改过程中,经过不断尝试,关于 ES 查询方面总结为以下几点:
升级ES
随着用户量的增加,必不可少的采取了加机器、换SSD等措施,同时升级es,ES6.0性能较之前会有大幅提升。
自定义分词器
因业务原因,例如“美的”这类特殊词汇的监测等等,改造了分词器,变成了单字分词。
但单字分词,有利有弊,随着业务增加,弊端不断暴露,如一个 “的” 字对应的文档数量几乎等同于所有的文档数量,导致查询速度急速下降。
采用bigrams
n-grams 方式,将含有m个字符的一句话拆分成m-1个n字符词汇,依次查询并组合结果集,这种查询会使查询效率在一定程度上有所提高,毕竟减少了每个词所需检索的文档数。
这种方式的弊端:不能适应单字查询与距离查询,须通过业务逻辑来满足业务需求。
巧用filter过滤
es 的过滤器有缓存的功能,且会优先进行过滤器里面的查询条件,综合自己的业务场景,提炼出一些能够大大减少文档数且相对固定的过滤词,能够大大提升查询效率,相对固定是为了能够复用缓存数据。如有必要,可推动改进业务需求来满足这一点。
查询语句优化
对于多个词的搜索,在使用多个单词query_string、should连接,单个多词query_string,match_phrase的方式都可以的情况下,这几种方式性能优劣是怎样的呢?
下面是具体场景的测试用例:
query_string (0)
(多个主体词空格分隔)
query_string (1)
(单个主体词)
match (2)
(单个主体词)
非bigram方式(0) bigram方式 (1) 非bigram方式(0) bigram方式 (1) 非bigram方式(0) bigram方式 (1) 用例编号 是否过滤 命中量 用时ms 命中量 用时ms 命中量 用时ms 命中量 用时ms 命中量 用时ms 命中量 用时ms 1 不加过滤(0) 11977 4046 11977 4046 11977 4046 11977 4046 11977 4046 11977 4046 主体过滤(1) 11161 4063 2624 2559 3520 5300 2475 2233 2472 2886 2472