Aggregations: allow terms bucket aggregations
#130
Conversation
max-moser
force-pushed
the
mm/bucket-aggregations
branch
from
4caeee4 to
8cf84b5
Compare
|
|
* because we don't need the actual query hits, we just need the aggregations * also, remove the unused temporary variable assignment
* because we're reusing parts of the aggregation query results directly, and per default they're wrapped in DSL objects (e.g. AttrList) that aren't JSON-serializable * see: elastic/elasticsearch-dsl-py#913
max-moser
force-pushed
the
mm/bucket-aggregations
branch
from
8cf84b5 to
da9f4ef
Compare
|
As we've discussed, we couldn't come up with immediate use-cases that would actually depend on this feature being merged in. The tricky part here is that aggregations are only an "intermediate" result, because the queries still need some way of aggregating the aggregations ( |
This PR adds support for bucket aggregations as cousins to the already supported metric aggregations.
Its main purpose is to enable simple document counts based on keywords ("how often does each value for a key occur in all events"), e.g. for the boolean
via_apiflag forrecord-viewevents:reference payload:
{ "timestamp": "2023-02-21T00:00:00", "unique_id": "recid_mnccv-j8r20", "count": 3, "unique_count": 1, "via_api": { "true": 2, "false": 1 }, "countries": {}, "recid": "mnccv-j8r20", "parent_recid": "b9jbe-qq607" }Limitations:
terms-type bucket aggregations are supported.Discussion:
v1:
{ "timestamp": "2023-02-21T00:00:00", "unique_id": "recid_mnccv-j8r20", "count": 3, "unique_count": 1, "via_api": { "true": 2, "false": 1 }, "countries": { "portugal": 3, "china": 0 }, "recid": "mnccv-j8r20", "parent_recid": "b9jbe-qq607" }v2:
{ // ... "countries": [ {"key": "portugal", "count": 3}, {"key": "china", "count": 0} ] }Use cases:
Charts:
#120