[[查询时提升]]
=== 查询时提升
在 <<prioritising-clauses,Prioritizing Clauses>>中, 我们解释了 ((("relevance", "controlling", "query time boosting")))((("boosting", "query-time")))你可以怎样在查询时使用 `boost`
来使得一个查询项比其它的更重要.
例如:
[source,json]
------------------------------
GET /_search
{
"query": {
"bool": {
"should": [
{
"match": {
"title": {
"query": "quick brown fox",
"boost": 2 <1>
}
}
},
{
"match": { <2>
"content": "quick brown fox"
}
}
]
}
}
}
------------------------------
<1> 查询项 `title` 的重要性是查询项 `content` 的2倍, 因为它被因数 `2` 提升了.
<2> 没有 `boost` 值的查询项会拥有一个默认因数为 `1` 的提升.
_查询时提升_ 是用于调节相关性的主要工具. 任何类型的查询都接受 `boost` 参数.
((("boost parameter", "setting value"))) 把 `boost` 设置为 `2` 并不会简单的加倍最后的 `_score`;
实际使用的 boost 值取决于标准化和一些内置的优化. 然而, 它确实意味着 boost 值为 `2` 的项的重要性是 boost 值为 `1`的项的2倍.
事实上, 对于一个实际的查询项,没有简单的算法来决定 ``正确'' 的 boost 值,它是边做边看的事.
要记得 `boost` 仅仅是影响相关性分数的因素之一; 它必须与其它因素竞争. 例如, 在之前的例子里,
`title` 字段相较于 `content 字段,可能已经有了一个 ``自然的'' 提升, 这归功于 ((("field-length norm"))) <<field-norm,field-length norm>>
(title通常比相关的 content 要短), 所以,不要仅仅因为你觉得它应该被提升就盲目的提升一个字段
应用一个提升并且检查结果. 改变提升并且重新检查.
==== 提升一个索引
当在多个索引间搜索时, ((("boosting", "query-time", "boosting an index")))((("indices", "boosting an index"))) 你可以通过 `indices_boost` 参数提升这些索引中的某一个索引.
((("indices_boost parameter"))) 下面的例子中使用了这种方法, 使得最近的索引文档拥有更高的权重:
[source,json]
------------------------------
GET /docs_2014_*/_search <1>
{
"indices_boost": { <2>
"docs_2014_10": 3,
"docs_2014_09": 2
},
"query": {
"match": {
"text": "quick brown fox"
}
}
}
------------------------------
<1> 该多索引搜索包含了所有以 `docs_2014_` 开头的索引.
<2> 索引 `docs_2014_10` 中的文档将被因数 `3` 提升, `docs_2014_09` 中的文档被因数 `2` 提升, 其它匹配的索引将被默认的因数 `1` 提升.
==== t.getBoost()
boost 值可以通过 <<practical-scoring-function>> `t.getBoost()` 获得.
((("practical scoring function", "t.getBoost() method")))((("boosting", "query-time", "t.getBoost()")))((("t.getBoost() method")))
提升不会被应用在出现查询 DSL 的地方. 而是任何 boost 值都会被合并、传递到单独的 terms 中.
`t.getBoost()` 方法会返回任意应用到 term本身或更高阶查询链的 `boost` 值.
[TIP]
==================================================
事实上, 阅读 <<explain,`explain`>> 输出略为复杂. 你不会在`explanation`看到它提到过 `boost` 值或 `t.getBoost()`.
提升是被放入了应用于特殊term的<<query-norm,`queryNorm`>>中.
尽管我们说 `queryNorm` 对于每一个 term 都是相同的, 但是你会发现已提升的term的 `queryNorm`
要比未提升的term 的 `queryNorm` 要高.
==================================================
- 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