基于Elasticsearch的搜索优化

高吞吐量查询优化

因业务扩展，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