背景

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}}
}