本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。 Elasticsearch: 权威指南 » 基础入门 » 执行分布式检索 » 搜索选项 « 取回阶段 游标查询 Scroll »
搜索选项编辑
有几个 查询参数可以影响搜索过程。
偏好编辑
偏好这个参数 preference
允许
用来控制由哪些分片或节点来处理搜索请求。 它接受像 _primary
,
_primary_first
, _local
, _only_node:xyz
, _prefer_node:xyz
, 和
_shards:2,3
这样的值, 这些值在
search preference
文档页面被详细解释。
但是最有用的值是某些随机字符串,它可以避免 bouncing results 问题。
Bouncing Results
想象一下有两个文档有同样值的时间戳字段,搜索结果用 timestamp
字段来排序。
由于搜索请求是在所有有效的分片副本间轮询的,那就有可能发生主分片处理请求时,这两个文档是一种顺序,
而副本分片处理请求时又是另一种顺序。
这就是所谓的 bouncing results 问题: 每次用户刷新页面,搜索结果表现是不同的顺序。
让同一个用户始终使用同一个分片,这样可以避免这种问题,
可以设置 preference
参数为一个特定的任意值比如用户会话ID来解决。
超时问题编辑
通常分片处理完它所有的数据后再把结果返回给协同节点,协同节点把收到的所有结果合并为最终结果。
这意味着花费的时间是最慢分片的处理时间加结果合并的时间。如果有一个节点有问题,就会导致所有的响应缓慢。
参数 timeout
告诉 分片允许处理数据的最大时间。如果没有足够的时间处理所有数据,这个分片的结果可以是部分的,甚至是空数据。
搜索的返回结果会用属性 timed_out
标明分片是否返回的是部分结果:
... "timed_out": true, ...
| 这个搜索请求超时了。 |
超时仍然是一个最有效的操作,知道这一点很重要; 很可能查询会超过设定的超时时间。这种行为有两个原因:
- 超时检查是基于每文档做的。 但是某些查询类型有大量的工作在文档评估之前需要完成。 这种 "setup" 阶段并不考虑超时设置,所以太长的建立时间会导致超过超时时间的整体延迟。
- 因为时间检查是基于每个文档的,一次长时间查询在单个文档上执行并且在下个文档被评估之前不会超时。 这也意味着差的脚本(比如带无限循环的脚本)将会永远执行下去。
路由编辑
在 路由一个文档到一个分片中 中, 我们解释过如何定制参数 routing
,它能够在索引时提供来确保相关的文档,比如属于某个用户的文档被存储在某个分片上。
在搜索的时候,不用搜索索引的所有分片,而是通过指定几个 routing
值来限定只搜索几个相关的分片:
GET /_search?routing=user_1,user2
这个技术在设计大规模搜索系统时就会派上用场,我们在 扩容设计 中详细讨论它。
搜索类型编辑
缺省的搜索类型是 query_then_fetch
。 在某些情况下,你可能想明确设置 search_type
为 dfs_query_then_fetch
来改善相关性精确度:
GET /_search?search_type=dfs_query_then_fetch
搜索类型 dfs_query_then_fetch
有预查询阶段,这个阶段可以从所有相关分片获取词频来计算全局词频。
我们在 被破坏的相关度! 会再讨论它。
Getting Started Videos
- Starting Elasticsearch
- Introduction to Kibana
- Logstash Starter Guide
官方地址:https://www.elastic.co/guide/cn/elasticsearch/guide/current/_search_options.html