【问题标题】:How do I refer to multiple nesting levels in an Elastic Search's Filter Aggregation?如何在 Elastic Search 的过滤器聚合中引用多个嵌套级别?
【发布时间】:2018-12-13 21:56:27
【问题描述】:

让我们调用我的根级别foo 和我的子级别events。我想在events 级别上进行聚合,但使用过滤器,event 的颜色为“橙色”,或者父级foo 的 customerId 为“35”。

所以,我想在嵌套聚合中创建一个过滤聚合。在这个过滤器的查询子句中,我有一个孩子引用foo 上的一个字段,另一个引用events 上的一个字段。但是,第一个孩子无法像那样实际引用父母!我不能使用 reverse_nested 聚合,因为我不能将其中一个作为复合查询的子级,并且我不能在嵌套之前进行过滤,因为那样我会失去 OR 语义。如何引用foo 上的字段?

如果有帮助,请举个具体的例子。映射:

{
  "foo": {
    "properties": {
      "customer_id": { "type": "long" },
      "events": {
        "type": "nested",
        "properties": {
          "color": { "type": "keyword" },
          "coord_y": { "type": "double" }
        }
      }
    }
  }
}

(为清楚起见更新:这是一个名为 foo 的索引,其根映射名为 foo

我希望能够进行的查询:

{
  "aggs": {
    "OP0_nest": {
      "nested": { "path": "events" },
      "aggs": {
        "OP0_custom_filter": {
          "filter": {
            "bool": {
              "should": [
                { "term": { "events.color": "orange" } },
                { "term": { "customer_id": 35 } }
              ]
            }
          },
          "aggs": {
            "OP0_op": {
              "avg": { "field": "events.coord_y" }
            }
          }
        }
      }
    }
  }
}

当然,这不起作用,因为包含customer_idshould 子句的子句不起作用。该术语查询始终为 false,因为在嵌套聚合中无法访问 customer_id

提前致谢!

【问题讨论】:

    标签: elasticsearch elastic-stack elassandra


    【解决方案1】:

    由于您要应用过滤器的字段位于不同级别,因此您需要分别对每个级别进行查询并将它们放在bool 查询的should 子句中,该子句成为我们过滤器聚合的filter。在这个聚合中,我们添加一个嵌套聚合来获得coord_y 的平均值。

    聚合将是(已更新:因为foo 是从字段名称中删除foo 的索引名称):

    {
      "aggs": {
        "OP0_custom_filter": {
          "filter": {
            "bool": {
              "should": [
                {
                  "term": {
                    "customer_id": 35
                  }
                },
                {
                  "nested": {
                    "path": "events",
                    "query": {
                      "term": {
                        "events.color": "orange"
                      }
                    }
                  }
                }
              ]
            }
          },
          "aggs": {
            "OP0_op": {
              "nested": {
                "path": "events"
              },
              "aggs": {
                "OP0_op_avg": {
                  "avg": {
                    "field": "events.coord_y"
                  }
                }
              }
            }
          }
        }
      }
    }
    

    【讨论】:

    • 对,但现在您过滤的是foo,而不是过滤events。因此,我们仍将使用此查询对既非橙色也不属于 ID 为 35 的客户的事件的 coord_y 进行平均,对吧?
    • 好的,我已经测试过了,我的理论是正确的。该查询的意思是,将foo 过滤到foo 文档桶中,这些文档要么用于客户ID 35,要么具有任何橙色子events 文档。但是,问题在于,一旦我嵌套到 events 级别,过滤就不再受到尊重。在我嵌套到 events 级别之后需要进行过滤,但是一旦我嵌套到 events 级别,我就不能再进行过滤了。
    • 另外,我在我的例子中犯了错误吗? foo 只是索引的名称,foo 本身没有嵌套在任何东西中。
    • 一旦我嵌套到不再尊重过滤的事件级别。过滤需要在我嵌套到事件级别后进行,但一旦我嵌套到事件级别,我就不再专门进行过滤。这与预期结果有何不同?
    • 不同之处在于我的预期结果是我只得到颜色 = 橙色或父 foo 的 customerid = 35 的事件。您的查询仍将聚合既没有颜色 = 橙色也没有其父 foo 的 customerid = 35。它聚合具有父 foo 客户 = 35 或父 foo 的事件以及任何颜色 = 橙色的子事件。
    猜你喜欢
    • 1970-01-01
    • 2016-02-10
    • 1970-01-01
    • 2019-04-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多