原创手做网站,网上免费自己设计商标,网站设计思路,老牛wordpress背景
ES7 相比于 ES6 有多个层面的优化#xff0c;对于开源的ES而言#xff0c;升级是必经之路。
ES的使用场景非常多#xff0c;在升级过程中可能会遇到非预期的结果#xff1b;
比如之前文章提到的典型案例#xff1a;ES7.17版本terms查询性能问题
ES7.17版本terms查…背景
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}}
}
