这里分享一个ES2.X升级到ES5.X带来的天坑问题
结论先行
先上结论(最佳实践)
bash
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
这样兼顾了各种查询问题&&痛点
- es查询数据耗时长导致业务接口耗时接近10s
- es机器报警cpu使用率飙高
- 某个字段(仓库id)是long类型的,terms查询耗时达到了7000~8000ms
优化过程
bash
1.查看es最近的变动,发现没有代码上线
2.和运维沟通后发现是es机器有升级从2.X升级到5.X
3.搜索资料发现2.X升级到5.X确实
对数值类型字段的terms查询有影响(原理一会儿讲)
4.使用es multi field特性为数值字段增加keyword类型的映射
5.调整代码,terms字段使用刚才映射的keyword查询原理分析
bash
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最佳实践
bash
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
这样兼顾了各种查询