Search API
Search API
來自專欄一起讀ElasticSearch官方文檔
搜索這一章並不是將具體那些搜索語句，而是es的搜索是怎麼設計的，有很多東西我從來沒想過，感覺也是非常精彩。
Routing
在執行一次搜索時，這個消息將被廣播到所有索引/分片（副本之間的輪詢調度），可以通過提供路由參數可以控制要搜索的分片。 例如，在索引tweets時，路由值可以是user的值。
POST /twitter/tweet?routing=kimchy{ "user" : "kimchy", "postDate" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
這部分內容在 Mapping 之 Meta-Fields 那篇文章已經講過了。 routing參數的值就對應著某個分片，直到這個就行了。
Adaptive Replica Selection
輪詢調度過程，是對副本進行循環的請求等待請求的響應。 另一種替代輪詢調度請求副本的方式，是你設定adaptive_replica_selection的參數為 true，像下面這樣。
PUT /_cluster/settings{ "transient": { "cluster.routing.use_adaptive_replica_selection": true }}
上面設置之後，有一個起「協調」作用的節點根據多個標準將請求發送給被認為是「最佳」的副本，主要判斷標準是下面幾個： 1.以前協調節點與包含數據副本的節點之間請求的響應時間； 2.以前在包含數據的節點上執行請求的時間； 3.包含數據的節點上的搜索線程池的隊列大小
Stats Groups
這個我看了比較久，不一定理解的對。 搜索可以與Stats的組概念相關聯，STATS可以維護每個組的統計聚合。它可以稍後使用索引indices stats API具體檢索。 我認為大概的場景就是你可以在搜索的時候，你可以給自己起個組名，這樣es可以記錄各個組的搜索記錄。
POST /_search{ "query" : { "match_all" : {} }, "stats" : ["group1", "group2"]}
上面這一段就是group1和group2（這個隨便起）用match_all搜索了一次。
GET _stats/search?groups=_all
可以用這句話去看各個組的搜索記錄。
Global Search Timeout
單個搜索可以把超時這個參數作為請求體搜索的一部分。由於搜索請求可以源自許多源，所以Elasticsearch有一個動態集群級別的關於全局搜索超時的設置，該設置適用於在請求體中沒有設置超時的所有搜索請求。 這些請求可以使用Search Cancellation機制在指定時間之後取消。因此，關於響應超時的警告同樣值得注意。 這個設置的關鍵是使用search.default_search_timeout，可以使用 Cluster Update Settings來設置。默認沒有全局超時值，設置此值為-1將全局搜索超時重置為無超時。
Search Cancellation
可以使用標準 task cancellation 機制來取消搜索。默認情況下，正在運行的搜索只檢查它在在倒排索引邊界上是否已經被取消，因此如果倒排索引很多取消可能會有延遲。 通過設置search.low_level_cancellation為true，來提高搜索取消的反應靈敏度。但是，在大型快速運行的搜索查詢中，它帶來了更頻繁的取消檢查的額外開銷。更改此設置只會影響在更改之後進行的搜索。
Search concurrency and parallelism（搜索並發和並行）
默認情況下，es不會根據請求命中的碎片數量拒絕任何搜索請求。 雖然Elasticsearch會優化協調節點上的搜索執行，但是大量分片可能對CPU和內存有重大影響。組織數據通常是一種更好的方法，即分片變少。如果希望配置軟限制，可以更新集群設置中的action.search.shard_count.limit參數，以便拒絕命中太多分片的搜索請求。 這個軟限制就是不是直接去設置分片，而是使用參數不去訪問過多分片。
請求參數max_concurrent_shard_requests可用於控制搜索API針對請求執行的並發分片請求的最大數量。這個參數應該用於保護單個請求不超載集群（例如，預設請求將命中集群中的所有索引，如果每個節點的碎片數量很高，則會導致碎片請求拒絕）。此預設值基於集群中的數據節點數量，但最多為256。 就是你搜索整個ES，es有很多索引，每個索引又有很多分片，這個並發的查詢要限制。
推薦閱讀：
