es优化实践(es升级带来的大坑)-＞问题与痛点-＞优化过程-＞原理分析-＞最佳实践

这里分享一个ES2.X升级到ES5.X带来的天坑问题

结论先行

先上结论(最佳实践)

es5以后版本 对于某个字段
1.字段用于terms查询,则字段定义为keyword类型,
如果定义为数值类型(number,long,short等)会有严重的性能问题
,查询耗时会很长

2.字段用于range查询,则字段定义为数值类型

3.如果该既要terms查询又要范围查询查询,
可以使用multi field特性让一个字段映射多种类型 
比如
"city_id":{
	"type": "long"
} range范围查询性能好,terms查询性能极差
改造后:
"city_id":{
	"type": "long",
	"fields":{
		"keyId":{
			"type":"keyword"
		}
	}
}
range查询的时候,使用city_id
terms查询的时候,使用city_id.keyId
这样兼顾了各种查询
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

问题&&痛点

• es查询数据耗时长导致业务接口耗时接近10s
• es机器报警cpu使用率飙高
• 某个字段(仓库id)是long类型的,terms查询耗时达到了7000~8000ms

优化过程

1.查看es最近的变动,发现没有代码上线
2.和运维沟通后发现是es机器有升级从2.X升级到5.X
3.搜索资料发现2.X升级到5.X确实
对数值类型字段的terms查询有影响(原理一会儿讲)
4.使用es multi field特性为数值字段增加keyword类型的映射
5.调整代码,terms字段使用刚才映射的keyword查询
1
2
3
4
5
6

原理分析

1.ES2.X
ES2.X用到的lucene版本,
实际上只能索引文本数据,
所以字段中定义的数值类型,
实际上都被转换成了字符串,
并编排成了倒排索引
这种方式对于数值的精确查询比价友好,
但是对于range范围查询开销大耗时高

2.ES5.X
ES5.X为了支持良好的range范围查询,引入了Block-k-d-tree这种索引结构
这种索引结构能很好地支持range查询,但terms查询就会变得极其耗时

问题复现
1.A字段你在es2.X的时候定义为数值类型并且使用了terms查询
2.es2.X数值类型转成文本类型,使用倒排索引,terms查询耗时短
3.运维升级es
4.数值类型不在转成为本类型使用倒排索引
而是使用block-k-d-tree索引
5.A字段使用到terms查询的地方性能崩溃
6.使用multi field将该字段映射出keyword类型,
terms查询使用该keyword

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

最佳实践

es5以后版本 对于某个字段
1.字段用于terms查询,则字段定义为keyword类型,
如果定义为数值类型(number,long,short等)会有严重的性能问题
,查询耗时会很长

2.字段用于range查询,则字段定义为数值类型

3.如果该既要terms查询又要范围查询查询,
可以使用multi field特性让一个字段映射多种类型 
比如
"city_id":{
	"type": "long"
} range范围查询性能好,terms查询性能极差
改造后:
"city_id":{
	"type": "long",
	"fields":{
		"keyId":{
			"type":"keyword"
		}
	}
}
range查询的时候,使用city_id
terms查询的时候,使用city_id.keyId
这样兼顾了各种查询
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25