即使是不成熟的尝试,也胜于胎死腹中的策略。

关于es聚合相关优化

Elasticsearch | 作者 finchan | 发布于2019年11月25日 | 阅读数:3098

背景:
es 版本6.8
4个数据节点,每个节点分配31.9G,机器内存128G,硬盘2T
每日流水索引文件10W~20wdoc,索引大小几十MB

DSL语句如下:
{
"size":0,
"query":{
"bool":{
"filter":[
{
"range":{
"day_str":{
"from":"2019-10-04",
"to":"2019-10-10",
"include_lower":true,
"include_upper":true,
"boost":1
}
}
}
],

"adjust_pure_negative":true,
"boost":1
}
},
"aggregations":{
"total_num": {
"cardinality": {
"field": "ad_id",
"precision_threshold": 1
}
},
"Bank":{
"terms":{
"field":"ad_id",
"size":2147483647,
"min_doc_count":1,
"shard_min_doc_count":0,
"show_term_doc_count_error":false,
"collect_mode":"breadth_first"
},

"aggregations":{
"score_bucket_sort": {
"bucket_sort": {
"sort": [
{
"exposure": "desc"
}
],
"from": 0,
"size": 60
}
},
"exposure":{
"sum":{
"field":"exposure"
}
},
"clk":{
"sum":{
"field":"clk"
}
},
"delivery_fetch_duration":{
"max":{
"field":"delivery_fetch_duration"
}
},
"advertiser_id":{
"terms":{
"field":"advertiser_id",
"size":1,
"min_doc_count":1,
"shard_min_doc_count":0,
"show_term_doc_count_error":false,
"execution_hint":"map",
"collect_mode":"breadth_first"
}
}

}
}
}
}
查询聚合计算一周时间的索引时间还是需要3s左右
已经做过的优化手段
1、控制字段存储,比如关闭无需要的index,与docvalue等
2、调整Lucene的压缩所算法,最佳压缩
3、通过force_merge接口强制合并segment,降低segment数量,减少segment体积
4、广度优先遍历
请问还有什么优化手段,或者源码上面去优化?
已邀请:

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

1核心:size":2147483647, 确认是否必须
2,你是多重嵌套,势必会慢
3,如何排查慢?推荐:profile:true 定位慢的根因
推荐:https://mp.weixin.qq.com/s/RTpBaFpNELQCO6VE0KMfsw
匿名用户

匿名用户

赞同来自:

@finchan: 这么说吧,所有的优化,都是因为需求不合理或者硬件资源不够导致的。
全量数据聚合,为什么要用ES呢?
而且你可以选择离线聚合一次保存到另一个,以后的查询可以走另一个索引。
3s已经非常快了。

要回复问题请先登录注册