1.搜索api

1.1.routing:路由

執行搜索時，它將廣播到所有索引/索引分片（副本之間的循環）。可以通過提供routing參數來控制將搜索哪些分片。例如，在索引推文時，路由值可以是用戶名。

POST /twitter/tweet?routing=kimchy
{
    "user" : "kimchy",
    "postDate" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}

1.2.adaptive replica selection:自適應副本選擇

作為以循環方式發送到數據副本的請求的替代方法，可以啟用自適應副本選擇。

• 協調節點與包含數據副本的節點之間的過去請求的響應時間
• 超過搜索請求的時間在包含數據的節點上執行
• 包含數據的節點上的搜索線程池的隊列大小

這可以通過改變所述動態群集配置開啟 cluster.routing.use_adaptive_replica_selection從false到true


PUT / _cluster / settings
{
    “短暫的”： {
        “cluster.routing.use_adaptive_replica_selection”：
 
true
    }
}

1.3.Stats Groups:統計組

搜索可以與統計組相關聯，統計組維護每個組的統計聚合。稍後可以使用indices stats API專門檢索它 。例如，以下是將請求與兩個不同的組相關聯的搜索正文請求：

POST /_search
{
    "query" : {
        "match_all" : {}
    },
    "stats" : ["group1", "group2"]
}

1.4.全局搜索超時

作為請求正文搜索的一部分，單個搜索可能會超時 。由於搜索請求可以源自多個源，因此Elasticsearch具有全局搜索超時的動態集群級設置，適用於未在請求正文搜索中設置超時的所有搜索請求。默認值為無全局超時。search.default_search_timeout

1.5.搜索取消

可以使用標準任務取消 機制取消搜索。默認情況下，正在運行的搜索僅檢查是否在段邊界上取消它，因此取消可能會被大段延遲。通過將動態集群級別設置設置search.low_level_cancellation為，可以提高搜索取消響應性true。但是，它帶來了更頻繁的取消檢查的額外開銷，這在大型快速運行的搜索查詢中是顯而易見的。更改此設置僅影響更改後開始的搜索。

1.6.搜索並發和並行

默認情況下，Elasticsearch不會根據請求命中的分片數拒絕任何搜索請求。雖然Elasticsearch將優化協調節點上的搜索執行，但大量分片會對CPU和內存產生重大影響。以這樣的方式組織數據通常是一個更好的主意，即更少的大分片。如果您要配置軟限制，可以更新action.search.shard_count.limit 群集設置以拒絕搜索過多分片的搜索請求。

request參數max_concurrent_shard_requests可用於控制搜索API將為請求執行的最大並發分片請求數。此參數應用於保護單個請求不會使群集過載（例如，默認請求將命中群集中的所有索引，如果每個節點的分片數量很高，則可能導致碎片請求被拒絕）。此默認值基於群集中的數據節點數，但最多256。

ES6.3常用api之搜索類api