Avg aggregation

Avg aggregation #

A single-value metrics aggregation that computes the average of numeric values that are extracted from the aggregated documents. It summarizes “what does a typical matching document look like on this field” into one number — the question SQL spells AVG(price) — without fetching a single document.

How it works #

The engine walks the matching documents once, keeping a running sum and count; the result is sum / count. Nothing is estimated: the average is exact. Values are coerced to doubles as they are read — integers, floats and booleans (true = 1, false = 0) contribute, non-numeric values such as keyword strings do not.

Avg bucket aggregation

Avg bucket aggregation #

A sibling pipeline aggregation computing the average of a metric across another aggregation’s buckets. Bucket aggregations answer “what is the revenue per day / per category / per range”; avg_bucket rolls those per-bucket numbers into one mean — “what does a typical day or category bring in” — without a second query or client-side arithmetic.

"avg_day": { "avg_bucket": { "buckets_path": "per_day>revenue" } }

How it works #

avg_bucket is declared next to the bucket aggregation it consumes (a sibling in the same aggs object) and runs after every regular aggregation has finished — after the merge, too, in a distributed search. It reads the parent’s finished buckets, collects one number per bucket, and divides their sum by their count. The result is a single-value metric ({"value": 56.25}) placed alongside the parent.

Terms aggregation

Terms aggregation #

A multi-bucket value source based aggregation where buckets are dynamically built - one per unique value. It answers “group by this field, count (and aggregate) per value” without knowing the values in advance, which a fixed-bucket aggregation like histogram or range cannot do.

How it works #

Every matching document is placed in the bucket keyed by its value of field. Multi-valued fields bucket per element: a document whose tags holds ["search", "architecture"] is counted once in the search bucket and once in the architecture bucket. Documents without the field are skipped — unless missing is set, in which case they land together in one bucket keyed by that value.

Cardinality aggregation

Cardinality aggregation #

A single-value metrics aggregation that counts the number of distinct values of a field — how many different types were sold, how many different hosts logged, how many different authors wrote.

How it works #

The engine counts with a HyperLogLog++ sketch — tuned so that small counts stay exact:

• Values are hashed (MurmurHash3, 64-bit) into a sketch that keeps an exact set while the number of distinct values stays at or below precision_threshold; those counts are returned verbatim.
• Above the threshold the sketch promotes to dense HyperLogLog registers, so memory stops growing with the data: roughly 1.6% relative error at the default threshold of 3000, tightening to about 0.4% at the maximum of 40000. The returned value is always a rounded whole number.
• When documents lack the field and missing is set, they all count as one additional distinct value; without missing they are simply not counted.

Distributed queries ship the sketch itself with each shard’s partial result and the coordinating node unions the sketches before estimating — the same number a single-node execution over all shards' documents would produce. (Cardinality nested inside bucket sub-aggregations still merges its per-shard finalized counts by maximum, a lower bound, when no sketch travels with them.)

Multi terms aggregation

Multi terms aggregation #

A multi-bucket aggregation like terms, but the bucket key is a TUPLE of values from several fields — e.g. every (merchant, status) combination. It answers cross-tab questions — “rows by column” tables — that a single-field terms aggregation cannot express without chaining requests.

How it works #

Each entry in the terms array contributes one component of the composite key. A document is placed in the bucket keyed by the tuple of its values, and the response reports each bucket’s key as an array — ["infini-store", "pending"].

Sum bucket aggregation

Sum bucket aggregation #

A sibling pipeline aggregation computing the sum of a metric across another aggregation’s buckets — e.g. “total of the daily totals”. Where avg_bucket characterizes the typical bucket, sum_bucket re-totals the per-bucket values, which is how you grand-total a figure that was only computed per group.

"grand_total": { "sum_bucket": { "buckets_path": "per_day>revenue" } }

How it works #

sum_bucket is declared next to the bucket aggregation it consumes and runs after every regular aggregation — including the distributed merge — has finished. It walks the parent’s finished buckets, collects one number per bucket, and adds them up into a single-value metric ({"value": 6750}) placed alongside the parent.

Lesson 4 — Aggregations

Lesson 4 — Aggregations #

From counts to histograms to composite paging — over sales and logs, with known answers you can verify by hand.

The use case #

Dashboards, reports, and faceted navigation — wherever the deliverable is not a page of hits but an answer. The questions this lesson answers:

• “What is the average / min / max price?” — metric aggregations.
• “How is revenue split by status?” — terms buckets.
• “Volume per week / per price band” — histograms.
• “Every (merchant, day) pair, complete — not just the top N” — composite aggregations with after cursors.
• “Just the number, skip the hits” — size: 0.

Metric aggregations #

One number out: sum, avg, min, max, stats (all of them at once), cardinality (distinct values):

Max aggregation

Max aggregation #

A single-value metrics aggregation that keeps track and returns the maximum value among the numeric values extracted from the aggregated documents. It answers “how high does this field go” over any query — the top of a price range, the latest timestamp in a window, the biggest order that matches a filter.

How it works #

The engine walks the matching documents once, keeping the largest value seen; any smaller value costs one comparison. Values are coerced to doubles as they are read — integers, floats and booleans (true = 1, false = 0) qualify, non-numeric values such as keyword strings do not.

Min bucket aggregation

Min bucket aggregation #

A sibling pipeline aggregation identifying the smallest per-bucket metric value. Bucket aggregations rank groups by their own key or doc_count; min_bucket answers the orthogonal question — which of the per-bucket numbers (a revenue, a latency, a rate) is the lowest, and how low.

"worst_seller": { "min_bucket": { "buckets_path": "per_type>revenue" } }

How it works #

min_bucket is declared next to the bucket aggregation it consumes and runs after every regular aggregation — including the distributed merge — has finished. It walks the parent’s finished buckets, collects one number per bucket, and returns their minimum as a single-value metric ({"value": 1350}) placed alongside the parent. Only the value is returned — not which bucket produced it; read the parent’s bucket list when you need the winner’s key.

Rare terms aggregation

Rare terms aggregation #

A multi-bucket aggregation that keeps only RARE terms — bucket keys whose document count is at or below max_doc_count. The mirror image of terms for finding the long tail: instead of the top-N most frequent values, it returns every low-frequency value.

How it works #

Bucketing works exactly like terms: one bucket per unique value of field, multi-valued fields counted per element, and documents without the field either skipped or folded into a missing bucket. include/exclude filter candidate keys up front (exact-value arrays or a single wildcard string prefix* / *suffix).