== Sorting Multivalue Buckets
Multivalue buckets--the `terms`, `histogram`, and ++date_histogram++—dynamically produce many buckets.((("sorting", "of multivalue buckets")))((("buckets", "multivalue, sorting")))((("aggregations", "sorting multivalue buckets"))) How does Elasticsearch decide the order that
these buckets are presented to the user?
By default, buckets are ordered by `doc_count` in((("doc_count", "buckets ordered by"))) descending order. This is a
good default because often we want to find the documents that maximize some
criteria: price, population, frequency. But sometimes you'll want to modify this sort order, and there are a few ways to
do it, depending on the bucket.
=== Intrinsic Sorts
These sort modes are _intrinsic_ to the bucket: they operate on data that bucket((("sorting", "of multivalue buckets", "intrinsic sorts")))
generates, such as `doc_count`.((("buckets", "multivalue, sorting", "intrinsic sorts"))) They share the same syntax but differ slightly
depending on the bucket being used.
Let's perform a `terms` aggregation but sort by `doc_count`, in ascending order:
[source,js]
--------------------------------------------------
GET /cars/transactions/_search?search_type=count
{
"aggs" : {
"colors" : {
"terms" : {
"field" : "color",
"order": {
"_count" : "asc" <1>
}
}
}
}
}
--------------------------------------------------
// SENSE: 300_Aggregations/50_sorting_ordering.json
<1> Using the `_count` keyword, we can sort by `doc_count`, in ascending order.
We introduce an +order+ object((("order parameter (aggregations)"))) into the aggregation, which allows us to sort on
one of several values:
`_count`::
Sort by document count. Works with `terms`, `histogram`, `date_histogram`.
`_term`::
Sort by the string value of a term alphabetically. Works only with `terms`.
`_key`::
Sort by the numeric value of each bucket's key (conceptually similar to `_term`).
Works only with `histogram` and `date_histogram`.
=== Sorting by a Metric
Often, you'll find yourself wanting to sort based on a metric's calculated value.((("buckets", "multivalue, sorting", "by a metric")))((("metrics", "sorting multivalue buckets by")))((("sorting", "of multivalue buckets", "sorting by a metric")))
For our car sales analytics dashboard, we may want to build a bar chart of
sales by car color, but order the bars by the average price, ascending.
We can do this by adding a metric to our bucket, and then referencing that
metric from the +order+ parameter:
[source,js]
--------------------------------------------------
GET /cars/transactions/_search?search_type=count
{
"aggs" : {
"colors" : {
"terms" : {
"field" : "color",
"order": {
"avg_price" : "asc" <2>
}
},
"aggs": {
"avg_price": {
"avg": {"field": "price"} <1>
}
}
}
}
}
--------------------------------------------------
// SENSE: 300_Aggregations/50_sorting_ordering.json
<1> The average price is calculated for each bucket.
<2> Then the buckets are ordered by the calculated average in ascending order.
This lets you override the sort order with any metric, simply by referencing
the name of the metric. Some metrics, however, emit multiple values. The
`extended_stats` metric is a good example: it provides half a dozen individual
metrics.
If you want to sort on a multivalue metric,((("metrics", "sorting multivalue buckets by", "multivalue metric"))) you just need to use the
dot-path to the metric of interest:
[source,js]
--------------------------------------------------
GET /cars/transactions/_search?search_type=count
{
"aggs" : {
"colors" : {
"terms" : {
"field" : "color",
"order": {
"stats.variance" : "asc" <1>
}
},
"aggs": {
"stats": {
"extended_stats": {"field": "price"}
}
}
}
}
}
--------------------------------------------------
// SENSE: 300_Aggregations/50_sorting_ordering.json
<1> Using dot notation, we can sort on the metric we are interested in.
In this example we are sorting on the variance of each bucket, so that colors
with the least variance in price will appear before those that have more variance.
=== Sorting Based on "Deep" Metrics
In the prior examples, the metric was a direct child of the bucket. An average
price was calculated for each term.((("buckets", "multivalue, sorting", "on deeper, nested metrics")))((("metrics", "sorting multivalue buckets by", "deeper, nested metrics"))) It is possible to sort on _deeper_ metrics,
which are grandchildren or great-grandchildren of the bucket--with some limitations.
You can define a path to a deeper, nested metric by using angle brackets (`>`), like
so: `my_bucket>another_bucket>metric`.
The caveat is that each nested bucket in the path must be a _single-value_ bucket.
A `filter` bucket produces((("filter bucket"))) a single bucket: all documents that match the
filtering criteria. Multivalue buckets (such as `terms`) generate many
dynamic buckets, which makes it impossible to specify a deterministic path.
Currently, there are only three single-value buckets: `filter`, `global`((("global bucket"))), and `reverse_nested`. As
a quick example, let's build a histogram of car prices, but order the buckets
by the variance in price of red and green (but not blue) cars in each price range:((("histograms", "buckets generated by, sorting on a deep metric")))
[source,js]
--------------------------------------------------
GET /cars/transactions/_search?search_type=count
{
"aggs" : {
"colors" : {
"histogram" : {
"field" : "price",
"interval": 20000,
"order": {
"red_green_cars>stats.variance" : "asc" <1>
}
},
"aggs": {
"red_green_cars": {
"filter": { "terms": {"color": ["red", "green"]}}, <2>
"aggs": {
"stats": {"extended_stats": {"field" : "price"}} <3>
}
}
}
}
}
}
--------------------------------------------------
// SENSE: 300_Aggregations/50_sorting_ordering.json
<1> Sort the buckets generated by the histogram according to the variance of a nested metric.
<2> Because we are using a single-value `filter`, we can use nested sorting.
<3> Sort on the stats generated by this metric.
In this example, you can see that we are accessing a nested metric. The `stats`
metric is a child of `red_green_cars`, which is in turn a child of `colors`. To
sort on that metric, we define the path as `red_green_cars>stats.variance`.
This is allowed because the `filter` bucket is a single-value bucket.
- Introduction
- 入門
- 是什么
- 安裝
- API
- 文檔
- 索引
- 搜索
- 聚合
- 小結
- 分布式
- 結語
- 分布式集群
- 空集群
- 集群健康
- 添加索引
- 故障轉移
- 橫向擴展
- 更多擴展
- 應對故障
- 數據
- 文檔
- 索引
- 獲取
- 存在
- 更新
- 創建
- 刪除
- 版本控制
- 局部更新
- Mget
- 批量
- 結語
- 分布式增刪改查
- 路由
- 分片交互
- 新建、索引和刪除
- 檢索
- 局部更新
- 批量請求
- 批量格式
- 搜索
- 空搜索
- 多索引和多類型
- 分頁
- 查詢字符串
- 映射和分析
- 數據類型差異
- 確切值對決全文
- 倒排索引
- 分析
- 映射
- 復合類型
- 結構化查詢
- 請求體查詢
- 結構化查詢
- 查詢與過濾
- 重要的查詢子句
- 過濾查詢
- 驗證查詢
- 結語
- 排序
- 排序
- 字符串排序
- 相關性
- 字段數據
- 分布式搜索
- 查詢階段
- 取回階段
- 搜索選項
- 掃描和滾屏
- 索引管理
- 創建刪除
- 設置
- 配置分析器
- 自定義分析器
- 映射
- 根對象
- 元數據中的source字段
- 元數據中的all字段
- 元數據中的ID字段
- 動態映射
- 自定義動態映射
- 默認映射
- 重建索引
- 別名
- 深入分片
- 使文本可以被搜索
- 動態索引
- 近實時搜索
- 持久化變更
- 合并段
- 結構化搜索
- 查詢準確值
- 組合過濾
- 查詢多個準確值
- 包含,而不是相等
- 范圍
- 處理 Null 值
- 緩存
- 過濾順序
- 全文搜索
- 匹配查詢
- 多詞查詢
- 組合查詢
- 布爾匹配
- 增加子句
- 控制分析
- 關聯失效
- 多字段搜索
- 多重查詢字符串
- 單一查詢字符串
- 最佳字段
- 最佳字段查詢調優
- 多重匹配查詢
- 最多字段查詢
- 跨字段對象查詢
- 以字段為中心查詢
- 全字段查詢
- 跨字段查詢
- 精確查詢
- 模糊匹配
- Phrase matching
- Slop
- Multi value fields
- Scoring
- Relevance
- Performance
- Shingles
- Partial_Matching
- Postcodes
- Prefix query
- Wildcard Regexp
- Match phrase prefix
- Index time
- Ngram intro
- Search as you type
- Compound words
- Relevance
- Scoring theory
- Practical scoring
- Query time boosting
- Query scoring
- Not quite not
- Ignoring TFIDF
- Function score query
- Popularity
- Boosting filtered subsets
- Random scoring
- Decay functions
- Pluggable similarities
- Conclusion
- Language intro
- Intro
- Using
- Configuring
- Language pitfalls
- One language per doc
- One language per field
- Mixed language fields
- Conclusion
- Identifying words
- Intro
- Standard analyzer
- Standard tokenizer
- ICU plugin
- ICU tokenizer
- Tidying text
- Token normalization
- Intro
- Lowercasing
- Removing diacritics
- Unicode world
- Case folding
- Character folding
- Sorting and collations
- Stemming
- Intro
- Algorithmic stemmers
- Dictionary stemmers
- Hunspell stemmer
- Choosing a stemmer
- Controlling stemming
- Stemming in situ
- Stopwords
- Intro
- Using stopwords
- Stopwords and performance
- Divide and conquer
- Phrase queries
- Common grams
- Relevance
- Synonyms
- Intro
- Using synonyms
- Synonym formats
- Expand contract
- Analysis chain
- Multi word synonyms
- Symbol synonyms
- Fuzzy matching
- Intro
- Fuzziness
- Fuzzy query
- Fuzzy match query
- Scoring fuzziness
- Phonetic matching
- Aggregations
- overview
- circuit breaker fd settings
- filtering
- facets
- docvalues
- eager
- breadth vs depth
- Conclusion
- concepts buckets
- basic example
- add metric
- nested bucket
- extra metrics
- bucket metric list
- histogram
- date histogram
- scope
- filtering
- sorting ordering
- approx intro
- cardinality
- percentiles
- sigterms intro
- sigterms
- fielddata
- analyzed vs not
- 地理坐標點
- 地理坐標點
- 通過地理坐標點過濾
- 地理坐標盒模型過濾器
- 地理距離過濾器
- 緩存地理位置過濾器
- 減少內存占用
- 按距離排序
- Geohashe
- Geohashe
- Geohashe映射
- Geohash單元過濾器
- 地理位置聚合
- 地理位置聚合
- 按距離聚合
- Geohash單元聚合器
- 范圍(邊界)聚合器
- 地理形狀
- 地理形狀
- 映射地理形狀
- 索引地理形狀
- 查詢地理形狀
- 在查詢中使用已索引的形狀
- 地理形狀的過濾與緩存
- 關系
- 關系
- 應用級別的Join操作
- 扁平化你的數據
- Top hits
- Concurrency
- Concurrency solutions
- 嵌套
- 嵌套對象
- 嵌套映射
- 嵌套查詢
- 嵌套排序
- 嵌套集合
- Parent Child
- Parent child
- Indexing parent child
- Has child
- Has parent
- Children agg
- Grandparents
- Practical considerations
- Scaling
- Shard
- Overallocation
- Kagillion shards
- Capacity planning
- Replica shards
- Multiple indices
- Index per timeframe
- Index templates
- Retiring data
- Index per user
- Shared index
- Faking it
- One big user
- Scale is not infinite
- Cluster Admin
- Marvel
- Health
- Node stats
- Other stats
- Deployment
- hardware
- other
- config
- dont touch
- heap
- file descriptors
- conclusion
- cluster settings
- Post Deployment
- dynamic settings
- logging
- indexing perf
- rolling restart
- backup
- restore
- conclusion