ElasticSearch Group by Multi Field，多字段聚合

This is something that can already be done using scripts. For example, if you have two fields f and g, you can run a terms aggregation on the union of the values of these fields by running the following aggregation (it works with both groovy and mvel):


GET test/_search
{
  "aggs": {
    "t": {
      "terms": {
        "script": "doc['f'].values + doc['g'].values"
      }
    }
  }
}
It might not be very performant, so if you plan on running a terms aggregation on several fields on a regular basis, you might want to use the copy_to directive in your mappings in order to copy field values to a dedicated field at indexing time and use this field to run the aggregations:


PUT test
{
  "mappings": {
    "test": {
      "properties": {
        "f": {
          "type": "string",
          "index": "not_analyzed",
          "copy_to": "f_and_g"
        },
        "g": {
          "type": "string",
          "index": "not_analyzed",
          "copy_to": "f_and_g"
        },
        "f_and_g": {
          "type": "string",
          "index": "not_analyzed"
        }
      }
    }
  }
}


[Add data]


GET test/_search
{
  "aggs": {
    "t": {
      "terms": {
        "field": "f_and_g"
      }
    }
  }
}
Adrien Grandjpountz closed this on 12 Aug
Clinton Gormley
Owner
clintongormley commented on 12 Aug
The reason why we're not planning on supporting this directly is that it would be much slower and heavier than a normal terms aggregation. The terms agg uses global ordinals (rather than concrete values) for counting, but the global ordinals for two different fields are completely separate, so we would have to look up each concrete value independently, which would be a huge performance cost.

With the solutions that @jpountz has suggested, the performance cost is obvious to the user: either you pay the price at aggregation time (with a script) or at index time (with the copy_to) field. We'd rather make this cost obvious to the user, instead of providing functionality which performs poorly.

SOURCE URL:https://github.com/elasticsearch/elasticsearch/issues/5100