大多數搜索API都是多索引的,但Explain API端點除外。segmentfault
執行搜索時,它將廣播到全部索引/索引碎片(副本之間的循環負載),能夠經過提供routing
參數來控制將搜索哪些碎片,例如,在索引推文時,路由值能夠是用戶名:併發
POST /twitter/_doc?routing=kimchy { "user" : "kimchy", "postDate" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch" }
在這種狀況下,若是咱們只想搜索特定用戶的推文,咱們能夠將其指定爲路由,從而致使搜索只觸及相關的分片:elasticsearch
POST /twitter/_search?routing=kimchy { "query": { "bool" : { "must" : { "query_string" : { "query" : "some query string here" } }, "filter" : { "term" : { "user" : "kimchy" } } } } }
路由參數能夠是多值的,表示爲逗號分隔的字符串,這將致使命中路由值匹配的相關碎片。post
做爲以循環方式發送到數據副本的請求的替代方法,你能夠啓用自適應副本選擇,這容許協調節點根據許多標準將請求發送到被認爲「最佳」的副本:優化
這能夠經過將動態集羣設置cluster.routing.use_adaptive_replica_selection
從false
更改成true
來啓用此功能:線程
PUT /_cluster/settings { "transient": { "cluster.routing.use_adaptive_replica_selection": true } }
搜索能夠與統計組相關聯,統計組維護每一個組的統計聚合,稍後可使用索引統計API專門檢索它,例如,如下是將請求與兩個不一樣的組相關聯的搜索體請求:code
POST /_search { "query" : { "match_all" : {} }, "stats" : ["group1", "group2"] }
做爲請求體搜索的一部分,單個搜索能夠有一個超時設置,因爲搜索請求能夠源自多個源,所以Elasticsearch具備全局搜索超時的動態集羣級設置,適用於未在請求正文中設置超時的全部搜索請求。這些請求將在指定時間後使用下一節「搜索取消」中描述的機制取消,所以,關於超時響應的相同警告也適用。索引
設置鍵爲search.default_search_timeout
,可使用羣集更新設置端點進行設置,默認值爲無全局超時,將此值設置爲-1
會將全局搜索超時重置爲無超時。隊列
可使用標準任務取消機制取消搜索,默認狀況下,正在運行的搜索僅檢查是否在片斷邊界上取消它,所以取消可能會被大段延遲。經過將動態集羣級別設置的search.low_level_cancellation
設置爲true
,能夠提升搜索取消響應性,可是,它帶來了更頻繁的取消檢查的額外開銷,這在大型快速運行的搜索查詢中是很是明顯的,更改此設置僅影響更改後開始的搜索。內存
默認狀況下,Elasticsearch不會根據請求命中的碎片數拒絕任何搜索請求,雖然Elasticsearch將優化協調節點上的搜索執行,但大量碎片會對CPU和內存產生重大影響。一般,以更少的較大碎片的方式組織數據是一個更好的主意,若是你要配置軟限制,你能夠更新action.search.shard_count.limit
羣集設置,以拒絕搜索過多碎片的搜索請求。
請求參數max_concurrent_shard_requests
可用於控制搜索API將爲請求執行的最大併發碎片請求數。此參數應用於保護單個請求不會使羣集過載(例如,默認請求將命中羣集中的全部索引,若是每一個節點的碎片數量很高,則可能致使碎片請求被拒絕),此默認值基於羣集中的數據節點數,但最多爲256
個。
搜索API容許你執行搜索查詢並返回與查詢匹配的搜索命中,可使用簡單查詢字符串做爲參數或使用請求體來提供查詢。
全部搜索API均可以應用於多個索引,並支持多索引語法,例如,咱們能夠搜索twitter
索引中的全部文檔:
GET /twitter/_search?q=user:kimchy
咱們還能夠在多個索引中搜索具備特定標記的全部文檔(例如,當每一個用戶有一個索引時):
GET /kimchy,elasticsearch/_search?q=tag:wow
或者咱們可使用_all
搜索全部可用的索引:
GET /_all/_search?q=tag:wow