Elasticsearch Terms Aggregation 根据某一项的聚合

最新推荐文章于 2024-03-10 23:31:21 发布

weixin_34262482

最新推荐文章于 2024-03-10 23:31:21 发布

阅读量494

点赞数

文章标签：大数据 python

原文链接：https://my.oschina.net/xiaominmin/blog/1785983

版权

2019独角兽企业重金招聘Python工程师标准>>>

原文
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html

根据某一项的每个唯一的值的聚合。
举例：

{
    "aggs" : {
        "genres" : {
            "terms" : { "field" : "genre" }
        }
    }
}

{ 
    "aggregations" : {
        "genres" : {
            "doc_count_error_upper_bound": 0, 
            "sum_other_doc_count": 0, 
            "buckets" : [ 
                {
                    "key" : "jazz",
                    "doc_count" : 10
                },
                {
                    "key" : "rock",
                    "doc_count" : 10
                },
                {
                    "key" : "electronic",
                    "doc_count" : 10
                },
            ]
        }
    }
}

上面，对于genre 这个字段，对它里面的各个值的文档数量进行统计。
doc_count_error_upper_bound 未知
sum_other_doc_count 当有大量不同值时，ES只返回数量最多的项。这个数字表示有多少文档的统计数量没有返回。
默认情况，对于某一项的聚合，只会返回数量最高的10项，通过调整size参数，可以控制默认的行为。
我测试到，令size=0时候，会返回所有的项。

Size
size参数用来指定在列表中返回多少项。如果该项的值的个数要大于这个size ，那么返回的结果可能会不准确，有轻微的误差。甚至文档数最多的那个值没有的返回。

文档的数量是大约的量
文档的数量是不准确的，只是一个大概值。因为每个分片给出它排好的前n的部分，然后再把各个分片的结果联合成最后的结果。
官方文档给了一个非常好的例子，还有几张表格，说明造成这个情况的原因。可以自己跳过去阅读以下就明白了。这一切的原因都是因为 ES是一个分布式的存储方式。

Shard size
取得size的值越大，结果会越接近准确，当然这样导致的负载也会越高（因为更多的查询和节点之间大数据量的传输）。
默认shard_size是等于size的。如果shard_size 取更大的值，结果会更准确。

计算文档数错误

有两个错误值会显示在项的聚合上，第一个doc_count_error_upper_bound ，给出个没有被算进最后的结果的最大可能的数字。这个表明在最坏情况下，有doc_count_error_upper_bound 这么多文档个数的一个值被遗漏了。这就是doc_count_error_upper_bound （文档数错误上界）这个参数的意义。

每个桶里的错误数
如果设置show_term_doc_count_error这个参数为ture，还会对每个 bucket都显示一个错误数，表示最大可能的误差情况。

而且，如果不是按照排序的话，这个错误是算不出来的，这时候，会给一个-1来表示这种有错，但是不知道错误边界的情况。

Order
用order参数可以做排序，默认是按照doc_count倒序排列的。
可以改变默认情况
“order” : { “_count” : “asc” } 这是按照doc_count升序排列
“order” : { “_term” : “asc” } 这是按照字母表升序排列。

转载于:https://my.oschina.net/xiaominmin/blog/1785983