【问题标题】:elasticsearch aggs returns wrong count numberselasticsearch aggs 返回错误的计数
【发布时间】:2016-02-20 17:54:52
【问题描述】:

我正在尝试做一些聚合查询并遇到一些问题。

GET /my_index/_search
{
"size" : 0,
"aggs":{
   "group_by":{
       "terms": {
            "field" : "category"
       }
   }
  }
  }

这是让我回来:

"hits": {
  "total": 180,
  "max_score": 0,
  "hits": []
 },
"aggregations": {
  "group_by": {
     "doc_count_error_upper_bound": 0,
     "sum_other_doc_count": 1,
     "buckets": [
        {
           "key": "pf_rd_m",
           "doc_count": 139
        },
        {
           "key": "other",
           "doc_count": 13
        },
        {
           "key": "_encoding",
           "doc_count": 12
        },
        {
           "key": "ie",
           "doc_count": 10
        },
        {
           "key": "cadeaux",
           "doc_count": 2
        },
        {
           "key": "cartes",
           "doc_count": 2
        },
        {
           "key": "cheques",
           "doc_count": 2
        },
        {
           "key": "home",
           "doc_count": 2
        },
        {
           "key": "nav_logo",
           "doc_count": 1
        },
        {
           "key": "ref",
           "doc_count": 1
        }
     ]
  }

}

如您所见,这告诉我有 180 个文档,但如果我计算存储桶中每个键的 doc_count 总和,我会发现更多元素...

这当然适用于弹性搜索标记化机制 (https://www.elastic.co/guide/en/elasticsearch/guide/current/aggregations-and-analysis.html)

所以我尝试了这个 es 帖子中的解决方案,但仍然无法正常工作。这是我的地图

"properties":{
                            "status":{
                              "type":"integer",
                              "index":"analyzed"
                            },
                            "category":{
                              "type":"string",
                              "fields": {
                                "raw" : {
                                  "type": "string",
                                  "index": "not_analyzed"
                                }
                              }
                            },
                            "dynamic_templates": [
                                { "notanalyzed": {
                                      "match":              "*",
                                      "match_mapping_type": "string",
                                      "mapping": {
                                          "type":        "string",
                                          "index":       "not_analyzed"
                                      }
                                   }
                                }
                              ]
                          }

如您所见,我有一个名为“类别”的字段。并将“raw”添加为 not_analyzed 字符串,但仍然返回错误的数字。

当我尝试这个时:

GET /my_index/_search
{
"size" : 0,
"aggs":{
   "group_by":{
       "terms": {
            "field" : "category.raw"
         }
      }
    }
  }

返回:

"hits": {
  "total": 180,
  "max_score": 0,
  "hits": []
},
"aggregations": {
  "group_by": {
     "doc_count_error_upper_bound": 0,
     "sum_other_doc_count": 0,
     "buckets": []
  }
}

这很奇怪。有什么帮助吗?

【问题讨论】:

    标签: elasticsearch aggregation


    【解决方案1】:

    documentation中所述,

    术语聚合中的文档计数(以及任何子聚合的结果)并不总是准确的。这是因为每个分片都提供了自己的视图,即术语的有序列表应该是什么,并将这些组合在一起以给出最终视图

    为了以资源为代价克服这个问题,可以使用分片大小参数。
    同样,来自文档:
    Shard Size

    请求的大小越大,结果就越准确,但计算最终结果的成本也越高(这都是由于在分片级别上管理的优先级队列更大,并且由于更大的节点和客户端之间的数据传输)。 shard_size 参数可用于最大程度地减少请求大小更大带来的额外工作。定义后,它将确定协调节点将从每个分片请求多少个术语。一旦所有分片都响应,协调节点将根据大小参数将它们减少到最终结果 - 这样,可以提高返回术语的准确性并避免将大桶列表流回的开销给客户。如果设置为0,则shard_size 将设置为Integer.MAX_VALUE

    如果将分片大小参数添加到查询中:

    GET /my_index/_search
    {
    "size" : 0,
    "aggs":{
       "group_by":{
           "terms": {
                "field" : "category.raw",
                "shard_size" : 0
             }
          }
        }
      }
    

    【讨论】:

    • 感谢您的回复。我尝试了您的答案,但查询返回给我一个错误。解析失败 [元素 [shard_size]] 没有解析器]; }]", "状态": 400
    • 很抱歉它应该在聚合定义中。
    • 我如何定义这个聚合?在我的映射中还是在哪里?谢谢
    • 这将从 Java API 抛出 throw new IllegalArgumentException( "[shardSize] must be greater than 0. Found [" + shardSize + "] in [" + name + "]");
    • ^ 这是由于 ES5,在撰写本文时它还不存在。 ES5 不再允许大多数设置为 0,因为大多数用户没有意识到由此可能引发的问题
    猜你喜欢
    • 2018-07-30
    • 1970-01-01
    • 2015-01-26
    • 2023-02-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-26
    • 2016-06-01
    相关资源
    最近更新 更多