背景
ES7 相比于 ES6 有多个层面的优化，对于开源的ES而言，升级是必经之路。
ES的使用场景非常多，在升级过程中可能会遇到非预期的结果；
比如之前文章提到的典型案例：ES7.17版本terms查询性能问题
ES7.17版本terms查询性能问题_es terms查询慢 profile-CSDN博客
接下来再分析一个升级之后聚合性能下降的case；
场景
1. 按照标准最佳实践进行改造（分片控制在20G左右，term/terms查询使用keyword类型...）
2. 集群从ES6.8.5 升级到 ES7.17.5
3. 异常：升级后性能骤降
avg 100ms -> 400ms
特定聚合查询 400ms -> 1500ms
4. 通过 profile ，以及实际测试，耗时主要是在聚合
分析
1. 性能下降，随之而来的还有CPU升高
2. 通过 arthas 工具采集火焰图
可以看到和global_ordinals全局序数相关；（查询/聚合时临时构建全局序数）
3. 针对全局序数，一般是2种优化手段
方案一：不使用序数 "execution_hint": "map"
注：只有在聚合时基数较小的情况下适用，否则容易OOM；（即字段整体数据基数较小；或者聚合时需要带有查询条件，查询条件筛选后用于聚合的字段数据基数比较小）
"aggregations": {
"agg_count": {
"terms": {
"field": "xxxxID",
"execution_hint": "map",
"size": 2,
"min_doc_count": 1,
"shard_min_doc_count": 0,
"show_term_doc_count_error": false,
"order": [
{
"_key": "asc"
}
]
}
}
}方案二：在查询之前提前创建好全局序数 "eager_global_ordinals": true，将全局序数的构建转移到索引（写数据）阶段，保证查询的效率
PUT xxxx/_mapping
{
"properties": {
"xxxxxID":{
"type": "keyword",
"eager_global_ordinals": true
}
}
}结论
1. 使用方案一，"execution_hint": "map"，性能大幅提升
1600ms -> 10ms （没有pageCache时候是40ms左右）
注：POST xxxx/_cache/clear 只能清理ES本身的缓存，无法清理pageCache
然后check一下terms聚合使用的字段的基数
POST xxxxx/_search
{
"query": {
"match_all": {}
},
"size": 0,
"aggs": {
"count_aggs": {
"cardinality": {
"field": "xxxxID"
}
}
}
}
整个索引，该字段的基数为 8kw，如果聚合不带任何条件就会消耗大量内存；
如果聚合都带查询条件，那么该方案适用，并且性能提升 90%+；
2. 方案二需要重建索引，理论查询性能也会大幅提升，此处暂无测试数据
PUT xxxx/_mapping
{
"properties": {
"xxxxxID":{
"type": "keyword",
"eager_global_ordinals": true
}
}
}
