请求的大小(size)越大,结果将越准确,但计算最终结果的成本也将越高(这两者都是由于在分片级别上管理的优先级队列更大,并且节点和客户端之间的数据传输也更大)。
shard_size 参数可用于最大程度地减少请求的大小带来的额外工作。 定义后,它将确定协调节点将从每个分片请求多少个术语。 一旦所有分片都做出响应,协调节点便会将它们缩减为最终结果,该最终结果将基于size参数-这样一来,可以提高返回条款的准确性,并避免流回大量存储桶的开销给客户。
注意:shard_size 不能小于 size(因为意义不大)。 启用时,Elasticsearch 将覆盖它并将其重置为等于大小。
缺省 shard_size为(size* 1.5 + 10)。
Terms aggregation 对于大量数据来说通常是不精确的
我们先来看一下如下的一个图:
从上面的图中,在 shard_size 为3的情况下,我们想对 geoip.country_name 这个字段来进行 terms aggregation:
- 从 shard 0 中提取文档数靠前的前三个,它们分别是 USA,India 及 France。它们的文档数分别是5,4及4。
- 从 shard 1 中提取文档数靠前的前单个,它们分别是 USA,India 及 Japan。它们的文档数分别是4,5及3。
那么总的文档数是:
- USA为:5 + 4 = 9
- India为:4 + 5 = 9
- France为:4 + 0 = 4
- Japan为: 3 + 0 = 3
根据上面的计算,返回的结果将会是 USA,India 及 France。细心的开发者可能马上可以看出来,在上面的统计中国其实是不精确的,这是因为在 shard 0 中,我们可以看见 Japan 有3个文档没有被统计进去。这个统计是基于我们对 shard_size 为3的情况。假如我们把 shard_size 提供到4,情况马上就会不同,而且更加接近我们的实际的统计数据的结果。在这种情况下,Japan 将会有 3 + 6 共6很个文档,应该是排名第3。
我们可以修改我们的请求如下:
GET logs_server*/_search
{
"size": 0,
"aggs": {
"top_10_urls": {
"terms": {
"field": "geoip.country_name.keyword",
"size": 10,
"shard_size": 100
}
}
}
}
我们可以通过增加 shard_size 来提高数据的精确性,但是必须注意的是这样的代价是计算的成本增加,特别是针对大量数据而言。
参考: