[[decay-functions]]
=== The Closer, The Better
Many variables could influence the user's choice of vacation
home.((("relevance", "controlling", "using decay functions"))) Maybe she would like to be close to the center of town, but perhaps
would be willing to settle for a place that is a bit farther from the
center if the price is low enough. Perhaps the reverse is true: she would be
willing to pay more for the best location.
If we were to add a filter that excluded any vacation homes farther than 1
kilometer from the center, or any vacation homes that cost more than £100 a
night, we might exclude results that the user would consider to be a good
compromise.
The `function_score` query gives ((("function_score query", "decay functions")))((("decay functions")))us the ability to trade off one sliding scale
(like location) against another sliding scale (like price), with a group of
functions known as the _decay functions_.
The three decay functions--called `linear`, `exp`, and `gauss`—operate on numeric fields, date fields, or lat/lon geo-points.((("linear function")))((("exp (exponential) function")))((("gauss (Gaussian) function"))) All three take
the same parameters:
`origin`::
The _central point_, or the best possible value for the field.
Documents that fall at the `origin` will get a full `_score` of `1.0`.
`scale`::
The rate of decay--how quickly the `_score` should drop the further from
the `origin` that a document lies (for example, every £10 or every 100 meters).
`decay`::
The `_score` that a document at `scale` distance from the `origin` should
receive. Defaults to `0.5`.
`offset`::
Setting a nonzero `offset` expands the central point to cover a range
of values instead of just the single point specified by the `origin`. All
values in the range `-offset <= origin <= +offset` will receive the full
`_score` of `1.0`.
The only difference between these three functions is the shape of the decay
curve. The difference is most easily illustrated with a graph (see <<img-decay-functions>>).
[[img-decay-functions]]
.Decay function curves
image::images/elas_1705.png["The curves of the decay functions"]
The curves shown in <<img-decay-functions>> all have their `origin`—the
central point--set to `40`. The `offset` is `5`, meaning that all values in
the range `40 - 5 <= value <= 40 + 5` are treated as though they were at the
`origin`—they all get the full score of `1.0`.
Outside this range, the score starts to decay. The rate of decay is
determined by the `scale` (which in this example is set to `5`), and the
`decay` (which is set to the default of `0.5`). The result is that all three
curves return a score of `0.5` at `origin +/- (offset + scale)`, or at points
`30` and `50`.
The difference between `linear`, `exp`, and `gauss` is the shape of the curve at other points in the range:
* The `linear` funtion is just a straight line. Once the line hits zero,
all values outside the line will return a score of `0.0`.
* The `exp` (exponential) function decays rapidly, then slows down.
* The `gauss` (Gaussian) function is bell-shaped--it decays slowly, then
rapidly, then slows down again.
Which curve you choose depends entirely on how quickly you want the `_score`
to decay, the further a value is from the `origin`.
To return to our example: our user would prefer to rent a vacation home close
to the center of London (`{ "lat": 51.50, "lon": 0.12}`) and to pay no more
than £100 a night, but our user considers price to be more important than
distance. ((("gauss (Gaussian) function", "in function_score query"))) We could write this query as follows:
[source,json]
----------------------------------
GET /_search
{
"query": {
"function_score": {
"functions": [
{
"gauss": {
"location": { <1>
"origin": { "lat": 51.5, "lon": 0.12 },
"offset": "2km",
"scale": "3km"
}
}
},
{
"gauss": {
"price": { <2>
"origin": "50", <3>
"offset": "50",
"scale": "20"
}
},
"weight": 2 <4>
}
]
}
}
}
----------------------------------
<1> The `location` field is mapped as a `geo_point`.
<2> The `price` field is numeric.
<3> See <<Understanding-the-price-Clause>> for the reason that `origin` is `50` instead of `100`.
<4> The `price` clause has twice the weight of the `location` clause.
The `location` clause is((("location clause, Gaussian function example"))) easy to understand:
* We have specified an `origin` that corresponds to the center of London.
* Any location within `2km` of the `origin` receives the full score of `1.0`.
* Locations `5km` (`offset + scale`) from the centre receive a score
of `0.5`.
[[Understanding-the-price-Clause]]
=== Understanding the price Clause
The `price` clause is a little trickier.((("price clause (Gaussian function example)"))) The user's preferred price is
anything up to £100, but this example sets the origin to £50. Prices can't be
negative, but the lower they are, the better. Really, any price between £0 and
£100 should be considered optimal.
If we were to set the `origin` to £100, then prices below £100 would receive a
lower score. Instead, we set both the `origin` and the `offset` to £50. That
way, the score decays only for any prices above £100 (`origin + offset`).
[TIP]
==================================================
The `weight` parameter can be used to increase or decrease the contribution of
individual clauses. ((("weight parameter (in function_score query)"))) The `weight`, which defaults to `1.0`, is multiplied by
the score from each clause before the scores are combined with the specified
`score_mode`.
==================================================
- 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