{
"size": 0,
"query": {
"bool": {
"filter": {
"range": {
"requestTime": {
"from": 1536127200000,
"to": 1536135000006,
"include_lower": true,
"include_upper": true
}
}
}
}
},
"aggregations": {
"ip": {
"terms": {
"field": "ip",
"size": 50
},
"aggregations": {
"modeZero": {
"filter": {
"term": {
"mode": "0"
}
},
"aggregations": {
"userName": {
"cardinality": {
"field": "userName"
}
}
}
},
"resultOne": {
"filter": {
"term": {
"result": "1"
}
},
"aggregations": {
"userName": {
"cardinality": {
"field": "userName"
}
}
}
}
}
}
}
}- 结果：
"took": 3435, "timed_out": false, "_shards": { "total": 25, "successful": 25, "failed": 0 }, "hits": { "total": 715625, "max_score": 0, "hits": [ ] }速度很慢，修改下语句，terms aggregation内部加一个 "execution_hint": "map"。
-
结果：
{ "took": 265, "timed_out": false, "_shards": { "total": 25, "successful": 25, "failed": 0 }, "hits": { "total": 715625, "max_score": 0, "hits": [ ] }性能提升了10倍以上。原因如下：
-
Terms aggregation默认的计算方式并非直观感觉上的先查询，然后在查询结果上直接做聚合。
ES假定用户需要聚合的数据集是海量的，如果将查询结果全部读取回来放到内存里计算，内存消耗会非常大。因此ES利用了一种叫做global ordinals的数据结构来对聚合的字段来做bucket分配，这个ordinals用有序的数值来代表字段里唯一的一个字符串，因此为每个ordinals值分配一个bucket就等同于为每个唯一的term分配了bucket。 之后遍历查询结果的时候，可以将结果映射到各个bucket里，就可以很快的统计出每个bucket里的文档数了。
这种计算方式主要开销在构建global ordinals和分配bucket上，如果索引包含的原始文档非常多，查询结果包含的文档也很多，那么默认的这种计算方式是内存消耗最小，速度最快的。
如果指定execution_hint:map则会更改聚合执行的方式，这种方式不需要构造global ordinals，而是直接将查询结果拿回来在内存里构造一个map来计算，因此在查询结果集很小的情况下会显著的比global ordinals快。
要注意的是这中间有一个平衡点，当结果集大到一定程度的时候，map的内存开销带来的代价可能就抵消了构造global ordinals的开销，从而比global ordinals更慢，所以需要根据实际情况测试对比一下才能找好平衡点。
-
terms聚合测试结果可以看：https://blog.csdn.net/laoyang360/article/details/79253294