# Search APIs 原文鏈接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.0/search.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/search.html) 譯文鏈接 : [http://www.apache.wiki/display/Elasticsearch](http://www.apache.wiki/display/Elasticsearch) 貢獻者 : @Josh @ Search URI Search ## Request Body Search ## Search 模板 ## Multi Search 模板 ## Search Shards API ## Suggesters ## Profile API * Profiling Queries * Profiling Aggregations * Profiling Considerations ## Multi Search API **multi search API?**允許在同一API中執行多個搜索請求。它的端點（**endpoint**）是** `_msearch`** 。 它的請求格式與 **multi API** 相似，結構如下（如果特定搜索最終重定向到另一個節點，則結構被特別優化以減少解析）： ``` header\n body\n header\n body\n ``` **header** 分包括要搜索的 **index / indices ，可搜索的可選（mapping）types** ，**search_type**，** `preference`** 和 **`routing`。** 正文包括典型的搜索正文請求（包括**`query`, `aggregations`, `from`, `size`** 等）。 這里是一個例子： ``` $ cat requests {"index" : "test"} {"query" : {"match_all" : {}}, "from" : 0, "size" : 10} {"index" : "test", "search_type" : "dfs_query_then_fetch"} {"query" : {"match_all" : {}}} {} {"query" : {"match_all" : {}}} {"query" : {"match_all" : {}}} {"search_type" : "dfs_query_then_fetch"} {"query" : {"match_all" : {}}} $ curl -XGET localhost:9200/_msearch --data-binary "@requests"; echo ``` 注意，上面包括也被支持的空標題（也可以只是沒有任何內容）的示例。 該響應返回一個響應數組，其中包括每個搜索請求的搜索響應和狀態代碼，與其在原始 **multi search** 請求中的順序相匹配。 如果該特定搜索請求的完全失敗，將返回具有錯誤消息和相應狀態代碼的對象，而不是實際的搜索響應。 端點還允許對URI中的 **index/indices**和 **type/types** 進行搜索，在這種情況下，它將被用作默認值，除非在標題中另有明確定義。 例如： ``` $ cat requests {} {"query" : {"match_all" : {}}, "from" : 0, "size" : 10} {} {"query" : {"match_all" : {}}} {"index" : "test2"} {"query" : {"match_all" : {}}} $ curl -XGET localhost:9200/test/_msearch --data-binary @requests; echo ``` 上面將針對沒有定義索引的所有請求對 **test** 索引執行搜索，最后一個將針對 **test2** 索引執行。 可以以類似的方式設置 **search_type** 以全局地應用于所有搜索請求。 **msearch** 的 _**max_concurrent_searches**_ 請求參數可用于控制 **multi search api** 將執行的并發搜索的最大數量。 此默認值基于數據節點的數量和默認搜索線程池大小。 ### 安全 請查看?[](https://www.elastic.co/guide/en/elasticsearch/reference/current/url-access-control.html "URL-based access control")_[_URL-based access control_](https://www.elastic.co/guide/en/elasticsearch/reference/current/url-access-control.html)_ ## Count API **Count API** 允許輕松執行查詢并獲取該查詢的匹配數。 它可以跨一個或多個索引并跨越一個或多個類型執行。 可以使用簡單的查詢字符串作為參數或使用在請求正文中定義的 **Query DSL** 來提供查詢。 這里是一個例子： ``` PUT /twitter/tweet/1?refresh { "user": "kimchy" } GET /twitter/tweet/_count?q=user:kimchy GET /twitter/tweet/_count { "query" : { "term" : { "user" : "kimchy" } } } ``` 注意 在正文中發送的查詢必須嵌套在查詢鍵中，與 **Search API** 相同 上面的兩個例子都做同樣的事情，這是從某個用戶的 twitter 索引計數 tweets 的數量。 其結果是： ``` { "count" : 1, "_shards" : { "total" : 5, "successful" : 5, "failed" : 0 } } ``` 查詢是可選的，如果沒有提供，它將使用 **match_all** 來計算所有的文檔。 ### Multi index, Multi type （多索引，多類型） **count API** 可以應用于多個索引中的多個類型。 ### Request Parameters （請求參數） 當使用查詢參數q執行計數時，傳遞的查詢是使用Lucene查詢解析器的查詢字符串。 還有其他可以傳遞的參數： | Name | Description | | --- | --- | | _`df`_ | 在查詢中未定義字段前綴時使用的默認字段。 | | _`analyzer`_ | 分析查詢字符串時使用的分析器名稱。 | | _`default_operator`_ | 要使用的默認運算符，可以是 **AND** 或 **OR**。 默認為 **OR**。 | | _`lenient`_ | 如果設置為 **true** 將導致基于格式的失敗（例如向數字字段提供文本）被忽略。 默認為 **false**。 | | _`lowercase_expanded_terms`_ | 術語是否自動小寫，默認為 **true** 。 | | _`analyze_wildcard`_ | 是否分析通配符和前綴查詢。 默認為false。 | | _`terminate_after`_ | 每個分片的最大計數，到達時，查詢執行將提前終止。 如果設置，響應將具有布爾字段 **terminated_early** 以指示查詢執行是否實際已終止。 默認為無 **terminate_after**。 | ### Request Body （請求主體） 計數可以使用其身體內的 **Query DSL** 來表達應該執行的查詢。 主體內容也可以作為名為 **source** 的 **REST** 參數傳遞。 **HTTP GET** 和 **HTTP POST** 都可以用于以主體執行計數。 由于并不是所有的客戶端都支持帶主體的 **GET**，因此也允許 **POST**。 ### Distributed （分布式） 計數操作在所有分片上廣播。 每個 **shard id group** 選擇一個副本并對其執行。 這意味著副本增加了計數的可伸縮性。 ### Routing （路由） 可以指定路由值（路由值的逗號分隔列表），以控制將對哪些分片執行計數請求。 ## Validate API **validate API** 允許用戶驗證一個可能復雜（expensive）的查詢而不執行它。 我們將使用以下測試數據來解釋_validate： ``` PUT twitter/tweet/_bulk?refresh {"index":{"_id":1}} {"user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"} {"index":{"_id":2}} {"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"} ``` 當發送一個有效查詢時： ``` GET twitter/_validate/query?q=user:foo ``` 響應包含有效：true： ``` {"valid":true,"_shards":{"total":1,"successful":1,"failed":0}} ``` ### Request Parameters 當執行查詢使用查詢參數q時，傳遞的查詢是使用Lucene查詢解析器的查詢字符串。 還有其他可以傳遞的參數： | Name | Description | | --- | --- | | `df` | 在查詢中未定義字段前綴時使用的默認字段。 | | `analyzer` | 分析查詢字符串時使用的分析器名稱。 | | `default_operator` | 要使用的默認運算符，可以是 **AND** 或 **OR**。 默認為 **OR**。 | | `lenient` | 如果設置為 **true** 將導致基于格式的失敗（例如向數字字段提供文本）被忽略。 默認為 **false**。 | | `lowercase_expanded_terms` | 術語是否自動小寫，默認為 **true** 。 | | `analyze_wildcard` | 是否分析通配符和前綴查詢。 默認為false。 | 查詢也可以在請求主體中發送： ``` GET twitter/tweet/_validate/query { "query" : { "bool" : { "must" : { "query_string" : { "query" : "*:*" } }, "filter" : { "term" : { "user" : "kimchy" } } } } } ``` 注意 在正文中發送的查詢必須嵌套在查詢鍵中，與 **Search API** 相同。 如果查詢無效，則`返回信息中 valid` 將為 false。 在這里，查詢無效，因為 **Elasticsearch** 知道post_date字段應該是動態映射的日期，foo無法正確解析為日期： ``` GET twitter/tweet/_validate/query?q=post_date:foo {"valid":false,"_shards":{"total":1,"successful":1,"failed":0}} ``` 可以指定 **explain** 參數以獲取有關查詢失敗原因的更詳細信息： ``` GET twitter/tweet/_validate/query?q=post_date:foo&explain=true ``` 響應是： ``` { "valid" : false, "_shards" : { "total" : 1, "successful" : 1, "failed" : 0 }, "explanations" : [ { "index" : "twitter", "valid" : false, "error" : "twitter/IAEc2nIXSSunQA_suI0MLw] QueryShardException[failed to create query:...failed to parse date field [foo]" } ] } ``` **當查詢有效時，explanations** 默認為該查詢的字符串表示形式。 將 **rewrite** 設置為 **true** 時，**explanations** 將更詳細地顯示將要執行的實際Lucene查詢。 模糊查詢（**Fuzzy Queries**）： ``` GET twitter/tweet/_validate/query?rewrite=true { "query": { "match": { "user": { "query": "kimchy", "fuzziness": "auto" } } } } ``` 響應： ``` { "valid": true, "_shards": { "total": 1, "successful": 1, "failed": 0 }, "explanations": [ { "index": "twitter", "valid": true, "explanation": "+user:kimchy +user:kimchi^0.75 #(ConstantScore(_type:tweet))^0.0" } ] } ``` 相似度查詢（**More Like This**）： ``` GET twitter/tweet/_validate/query?rewrite=true { "query": { "more_like_this": { "like": { "_id": "2" }, "boost_terms": 1 } } } ``` 響應： ``` { "valid": true, "_shards": { "total": 1, "successful": 1, "failed": 0 }, "explanations": [ { "index": "twitter", "valid": true, "explanation": "((user:terminator^3.71334 plot:future^2.763601 plot:human^2.8415773 plot:sarah^3.4193945 plot:kyle^3.8244398 plot:cyborg^3.9177752 plot:connor^4.040236 plot:reese^4.7133346 ... )~6) -ConstantScore(_uid:tweet#2)) #(ConstantScore(_type:tweet))^0.0" } ] } ``` 警告 請求只在單個分片上執行，這是隨機選擇的。 查詢的詳細解釋可以取決于哪個分片被命中，并且因此可以從一個請求到另一個請求而變化。 ## Explain API **Explain API** 計算查詢和特定文檔的分數說明。 這可以提供有用的反饋，無論文檔是否匹配特定查詢。? index 和 type 參數分別期望單個索引和單個類型。 ### Usage 完整查詢示例： ``` GET /twitter/tweet/0/_explain { "query" : { "match" : { "message" : "elasticsearch" } } } ``` 這將產生以下結果： ``` { "_index" : "twitter", "_type" : "tweet", "_id" : "0", "matched" : true, "explanation" : { "value" : 1.55077, "description" : "sum of:", "details" : [ { "value" : 1.55077, "description" : "weight(message:elasticsearch in 0) [PerFieldSimilarity], result of:", "details" : [ { "value" : 1.55077, "description" : "score(doc=0,freq=1.0 = termFreq=1.0\n), product of:", "details" : [ { "value" : 1.3862944, "description" : "idf(docFreq=1, docCount=5)", "details" : [ ] }, { "value" : 1.1186441, "description" : "tfNorm, computed from:", "details" : [ { "value" : 1.0, "description" : "termFreq=1.0", "details" : [ ] }, { "value" : 1.2, "description" : "parameter k1", "details" : [ ] }, { "value" : 0.75, "description" : "parameter b", "details" : [ ] }, { "value" : 5.4, "description" : "avgFieldLength", "details" : [ ] }, { "value" : 4.0, "description" : "fieldLength", "details" : [ ] } ] } ] } ] }, { "value" : 0.0, "description" : "match on required clause, product of:", "details" : [ { "value" : 0.0, "description" : "# clause", "details" : [ ] }, { "value" : 1.0, "description" : "_type:tweet, product of:", "details" : [ { "value" : 1.0, "description" : "boost", "details" : [ ] }, { "value" : 1.0, "description" : "queryNorm", "details" : [ ] } ] } ] } ] } } ``` 還有一種更簡單的通過 q 參數指定查詢的方法。 然后解析指定的 q 參數值，就像使用 query_string 查詢一樣。 在api中的 q 參數的用法示例： ``` GET /twitter/tweet/0/_explain?q=message:search ``` 這將產生與先前請求相同的結果。 所有的參數： | Name | Description | | --- | --- | | `_source` | 設置為true以檢索所解釋的文檔的_source。 您還可以使用_source_include＆_source_exclude檢索文檔的一部分（有關更多詳細信息，請參閱Get API） | | `stored_fields` | 允許控制哪些存儲字段作為文檔說明的一部分返回。 | | `routing` | 在索引期間使用路由的情況下控制路由。 | | `parent` | 與設置 `routing` 參數的效果相同。 | | `preference` | 控制執行解釋的分片。 | | `source` | 允許請求的數據放在url的查詢字符串中。 | | `q` | 查詢字符串（映射到 query_string 查詢）。 | | `df` | 在查詢中未定義字段前綴時使用的默認字段。 默認為_all字段。 | | `analyzer` | 分析查詢字符串時使用的分析器名稱。 默認為_all字段的分析器。 | | `analyze_wildcard` | 是否分析通配符和前綴查詢。 默認為false。 | | `lowercase_expanded_terms` | 術語是否自動小寫，默認為 **true** 。 | | `lenient` | 如果設置為 **true** 將導致基于格式的失敗（例如向數字字段提供文本）被忽略。 默認為 **false**。 | | `default_operator` | 要使用的默認運算符，可以是AND或OR。 默認為OR。 | ## Profile API ? ?Profiling Queries ? ?query 部分包含了Lucene在特定分片上執行的查詢樹的詳細選擇,此查詢樹的總體結構將類似于您的原始Elasticsearch查詢，但有還是有點區別，它也將使用類似但不總是相同的命名。 使用我們以前的匹配查詢示例，讓我們分析查詢部分： "query": [ { ?"type": "BooleanQuery", "description": "message:message message:number", "time": "1.873811000ms", "breakdown": {...}, (1) "children": [ { "type": "TermQuery", "description": "message:message", "time": "0.3919430000ms", "breakdown": {...} }, { "type": "TermQuery", "description": "message:number", "time": "0.2106820000ms", "breakdown": {...} } ] } ] (1) 為了方便學習使用的省略號 ? ? 基于配置文件結構，我們可以看到，我們的 match 查詢被Lucene重寫成一個BooleanQuery，帶有兩個子句（兩者都持有一個TermQuery）“type”字段顯示Lucene類名，常常也是與ES一樣的，“description”字段顯示查詢的Lucene描述文本并可用于幫助區分查詢的各個部分（例如，“message：search”和“message：test”都是TermQuery的，否則會顯示相同的內容。 ??“time”字段顯示該查詢時間 -15ms來執行整個BooleanQuery。 記錄的時間包括所有的子類。 ??“breakdown”字段將提供花費時間的詳細統計信息，我們會在下面看到。 最后，“children”數組列出可能存在的任何子查詢。 因為我們搜索了兩個值（“search test”），我們的BooleanQuery保存兩個子項TermQueries。 它們具有相同的信息（type，time，分類等）。 childern可以還有自己的childern(父子、嵌套mapping)。 ? ?timing breakdown(時間分類) ??“breakdown”組件列出了有關低級Lucene執行的詳細時序統計信息： "breakdown": { "score": 51306, "score_count": 4, "build_scorer": 2935582, "build_scorer_count": 1, "match": 0, "match_count": 0, "create_weight": 919297, "create_weight_count": 1, "next_doc": 53876, "next_doc_count": 5, "advance": 0, "advance_count": 0 } 時序以納秒為單位列出，并且根本沒有標準化。 統計的含義如下： 全部參數 create_weight：Lucene中的Query必須能夠跨多個IndexSearcher重用（認為它是針對特定Lucene Index執行搜索的引擎）這使得Lucene在一個棘手的地方，因為許多查詢需要累積與正在使用的索引相關聯的臨時state/statistices 信息，但是Query 結構要求它必須是不可變的。為了解決這個問題，Lucene要求每個查詢生成一個Weight對象，該對象充當臨時上下文對象，用于保存與此特定（IndexSearcher，Query）元組相關聯的狀態。 權重度量顯示此過程需要多長時間 build_scorer：?此參數顯示為查詢構建Scorer所需的時間。 Scorer是迭代匹配文檔生成每個文檔的分數（例如，“foo”與文檔匹配得多好）的機制。注意，這會記錄生成Scorer對象所需的時間，而不會實際記錄文檔。 一些查詢具有更快或更慢的Scorer初始化，這取決于優化，復雜性等。這也可以示出與緩存相關聯的定時，如果啟用 and/or 查詢 next_doc:?Lucene方法next_doc返回與查詢匹配的下一個文檔的文檔ID。 此統計信息顯示確定哪個文檔是下一個匹配所需的時間，這個過程根據查詢的性質有很大的不同。 Next_doc是advance（）的一種特殊形式，對于Lucene中的許多查詢都更方便。 它等價于advance（docId（）+ 1） advance:?advance是next_doc的“lower level”版本：它具有找到下一個匹配文檔的相同目的，但是需要調用查詢來執行額外的任務，例如識別和移動過去的跳過等。然而，不是所有的查詢都可以使用next_doc ，所以advance也為這些查詢計時。 連接（例如布爾值中的must子句）是提前的典型消費者 matches:某些查詢（例如詞組查詢）使用“two phase”過程匹配文檔。 首先，文檔“近似”匹配，并且如果大致匹配，則用更嚴格（且昂貴）的過程第二次檢查該文檔。 第二階段驗證是 matches 統計量度量。 例如，短語查詢首先大致通過確保短語中的所有詞語都存在于文檔中來檢查文檔。 如果所有術語都存在，則其然后執行第二階段驗證以確保術語是為了形成短語，這比僅僅檢查術語的存在相對更貴。 由于此兩階段過程僅由少量查詢使用，因此 metric 統計數據通常為零 score :這記錄了通過它的Scorer對特定文檔記分所花費的時間 *_count:?記錄特定方法的調用數。 例如，“next_doc_count”：2，表示在兩個不同的文檔上調用nextDoc（）方法。?這可以用于通過比較不同查詢組件之間的計數來幫助判斷選擇性查詢的方式。 ?collectors Section 響應的Collectors部分顯示高級執行詳細信息。 Lucene通過定義一個“Collector”來工作，它負責協調匹配文檔的遍歷，評分和收集。 收集器也是單個查詢如何記錄聚合結果，執行未范圍化的“全局”查詢，執行查詢后過濾器等。 看看例子： "collector": [ { "name": "SimpleTopScoreDocCollector", "reason": "search_top_hits", "time": "0.06989100000ms" } ] ? ? 我們看到一個名為SimpleTopScoreDocCollector的收集器。 這是Elasticsearch使用的默認“評分和排序”收集器。“reason”字段試圖給出類名的簡單的描述。 “time”類似于查詢樹中的時間：包含所有子項的時間。 同樣，children列出所有子收集 ? ?應該注意，收集器時間與查詢時間無關。 它們是獨立計算，組合和規范的！ 由于Lucene的執行性質，不可能將時間從收集器“合并”到查詢部分，因此它們以單獨的部分顯示。 ??作為參考，各種收集器的原因是： ?search_sorted：文檔評分和排序的收集器。 這是最常見的收集器，將在最簡單的搜索中看到 ??search_count：?僅計算與查詢匹配的文檔數，但不會獲取源的收集器。 這在指定size：0時可見 ?search_terminate_after_count： ?已找到在找到n個匹配文檔后終止搜索執行的收集器。 當指定了terminate_after_count查詢參數時，會看到這一點 ?search_min_score:?僅返回具有大于n的分數的匹配文檔的收集器。 這在指定頂級參數min_score時可見。 ?search_multi:?包裝其他收集器的收集器。 當搜索，聚合，全局agg和post_filters的組合在單個搜索中組合時，可以看到這一點。 ?search_timeout:?在指定時間段后停止執行的收集器。 這在指定超時頂級參數時可見。 aggregation:?Elasticsearch用于針對查詢范圍運行聚合的收集器。 單個聚合收集器用于收集所有聚合的文檔，因此您將看到名稱中的聚合列表。 global_aggregation:對全局查詢作用域而不是指定的查詢執行聚合的收集器。 因為全局范圍必須不同于執行的查詢， ? rewrite Section ? ?Lucene中的所有查詢都經歷了“重寫”過程。 查詢（及其子查詢）可以重寫一次或多次，并且該過程繼續，直到查詢停止改變。此過程允許Lucene執行優化，例如刪除冗余子句，替換一個查詢以獲得更有效的執行路徑等。例如，Boolean→Boolean→TermQuery可以重寫為TermQuery，因為在這種情況下所有布爾值都是不必要的 。 ??重寫過程很復雜，難以顯示，因為查詢可能會發生巨大變化。 不是顯示中間結果，而是將總重寫時間簡單地顯示為值（以納秒為單位）。此值是累積的，包含正在重寫的所有查詢的總時間。 ?更復雜例子 ?為了演示稍微更復雜的查詢和相關聯的結果，我們可以對以下查詢進行概要分析： curl -XPOST 'slave1:9200/test/_search?pretty' -d ' { "profile": true, "query": { "term": { "message": { "value": "search" } } }, "aggs": { "non_global_term": { "terms": { "field": "agg" }, "aggs": { "second_term": { "terms": { "field": "sub_agg" } } } }, "another_agg": { "cardinality": { "field": "aggB" } }, "global_agg": { "global": {}, "aggs": { "my_agg2": { "terms": { "field": "globalAgg" } } } } }, "post_filter": { "term": { "my_field": "foo" } } } 此示例具有： * A query * A scoped aggregation * A global aggregation * A post_filter 響應： { "profile": { "shards": [ { "id": "[P6-vulHtQRWuD4YnubWb7A][test][0]", "searches": [ { "query": [ { "type": "TermQuery", "description": "my_field:foo", "time": "0.4094560000ms", "breakdown": { "score": 0, "score_count": 1, "next_doc": 0, "next_doc_count": 2, "match": 0, "match_count": 0, "create_weight": 31584, "create_weight_count": 1, "build_scorer": 377872, "build_scorer_count": 1, "advance": 0, "advance_count": 0 } }, { "type": "TermQuery", "description": "message:search", "time": "0.3037020000ms", "breakdown": { "score": 0, "score_count": 1, "next_doc": 5936, "next_doc_count": 2, "match": 0, "match_count": 0, "create_weight": 185215, "create_weight_count": 1, "build_scorer": 112551, "build_scorer_count": 1, "advance": 0, "advance_count": 0 } } ], "rewrite_time": 7208, "collector": [ { "name": "MultiCollector", "reason": "search_multi", "time": "1.378943000ms", "children": [ { "name": "FilteredCollector", "reason": "search_post_filter", "time": "0.4036590000ms", "children": [ { "name": "SimpleTopScoreDocCollector", "reason": "search_top_hits", "time": "0.006391000000ms" } ] }, { "name": "BucketCollector: [[non_global_term, another_agg]]", "reason": "aggregation", "time": "0.9546020000ms" } ] } ] }, { "query": [ { "type": "MatchAllDocsQuery", "description": "*:*", "time": "0.04829300000ms", "breakdown": { "score": 0, "score_count": 1, "next_doc": 3672, "next_doc_count": 2, "match": 0, "match_count": 0, "create_weight": 6311, "create_weight_count": 1, "build_scorer": 38310, "build_scorer_count": 1, "advance": 0, "advance_count": 0 } } ], "rewrite_time": 1067, "collector": [ { "name": "GlobalAggregator: [global_agg]", "reason": "aggregation_global", "time": "0.1226310000ms" } ] } ] } ] } } 你可以看到，輸出是從前的顯著冗長。 查詢的所有主要部分都表示為： 1、第一個TermQuery（message：search）表示主要術語查詢 2、第二個TermQuery（my_field：foo）表示post_filter查詢 3、有一個MatchAllDocsQuery（*：*）查詢，作為第二個不同的搜索執行。 這不是用戶指定的查詢的一部分，但是由全局聚合自動生成以提供全局查詢作用域 Collector樹是相當簡單的，顯示單個MultiCollector如何包裝一個FilteredCollector來執行post_filter（反過來包裝正常評分SimpleCollector），一個BucketCollector來運行所有作用域聚合。在MatchAll搜索中，有一個GlobalAggregator運行全局聚合。 理解多術語查詢輸出 需要對MultiTermQuery查詢類進行特別說明。 這包括通配符，正則表達式和模糊查詢。 這些查詢發出非常詳細的響應，并且不過度結構化。基本上，這些查詢基于每個段重寫自身。 如果你想象通配符查詢b *，它技術上可以匹配任何以字母“b”開頭的。 它不可能枚舉所有可能的組合，因此Lucene在被評估的段的上下文中重寫查詢。例如。 一個段可以包含標記[bar，baz]，因此查詢重寫為“bar”和“baz”的BooleanQuery組合。另一個細分受眾群可能只有[bakery]，因此查詢將重寫為單個TermQuery for“bakery”。 由于這種動態的，每個段的重寫，樹結構變得混亂，并且不再遵循清晰的“lineage”，顯示一個查詢如何重寫到下一個。?目前，我們沒有實現 表示抱歉，并建議您折疊查詢的children的細節，如果它太混亂了。?幸運的是，所有的時序統計都是正確的，只是不是響應中的物理布局，所以只要分析頂層的MultiTermQuery就可以忽略它的子節點，如果你發現細節太難解釋。 希望這將在未來的迭代中固定，但它是一個棘手的問題，要解決，仍在進行中....) Profiling Aggregations? ? ??aggregations Section ? ?聚合部分包含由特定分片執行的聚合樹的詳細時序。 此聚合樹的總體結構將類似于您的原始Elasticsearch請求。?讓我們考慮以下示例聚合請求： ?curl -XPOST 'slave1:9200/house-prices/_search?pretty' -d '{ "profile": true, "size": 0, "aggs": { "property_type": { "terms": { "field": "propertyType" }, "aggs": { "avg_price": { "avg": { "field": "price" } } } } } } 輸出 "aggregations": [ { "type": "org.elasticsearch.search.aggregations.bucket.terms.GlobalOrdinalsStringTermsAggregator", "description": "property_type", "time": "4280.456978ms", "breakdown": { "reduce": 0, "reduce_count": 0, "build_aggregation": 49765, "build_aggregation_count": 300, "initialise": 52785, "initialize_count": 300, "collect": 3155490036, "collect_count": 1800 }, "children": [ { "type": "org.elasticsearch.search.aggregations.metrics.avg.AvgAggregator", "description": "avg_price", "time": "1124.864392ms", "breakdown": { "reduce": 0, "reduce_count": 0, "build_aggregation": 1394, "build_aggregation_count": 150, "initialise": 2883, "initialize_count": 150, "collect": 1124860115, "collect_count": 900 } } ] } ] 從概要文件結構中，我們可以看到我們的property_type術語聚合，它由GlobalOrdinalsStringTermsAggregator類和由AvgAggregator類在內部表示的子聚合器avg_price內部表示。類型字段顯示內部用于表示聚合的類。 描述字段顯示聚合的名稱。 “time”字段顯示整個聚合需要大約4秒的時間來執行。 記錄的時間包括所有的children。 “breakdown”字段將提供有關時間花費的詳細統計信息，我們稍后將介紹。 最后，“children”數組列出可能存在的任何子聚合。 因為我們有一個avg_price聚合作為property_type聚合的子聚合，我們看到它被列為property_type聚合的子節點。 這兩個聚合輸出具有相同的信息（type，time，breakdown ..）。 children可以有自己的children。 timing Breakdown ??“breakdown”組件列出了有關低級Lucene執行的詳細時序統計信息： "breakdown": { "reduce": 0, "reduce_count": 0, "build_aggregation": 49765, "build_aggregation_count": 300, "initialise": 52785, "initialize_count": 300, "collect": 3155490036, "collect_count": 1800 } ? ? 時序以納秒為單位列出，并且根本沒有標準化。 所有關于整體時間的注意事項適用于此。 ? ??分解的目的是給你一個感覺A）什么機械在Elasticsearch實際上的時間，和B）各種組件之間的時間差異的大小。 像總時間，分解包括所有children時間。 統計的含義如下： initialise：在開始收集文檔之前創建和初始化聚合所需的時間。 collect：這表示在聚集的收集階段中花費的累積時間。 這是將匹配文檔傳遞到聚合的地方，并且基于文檔中包含的信息更新聚合器的狀態。 build_aggregation：這表示在文檔集合完成之后，用于創建準備好傳遞回節點的聚合的分片級結果所花費的時間。 reduce：這當前未使用，將始終報告為0.當前的聚合分析僅次于聚合執行的分片級別部分。 *_count：記錄特定方法的調用數。 例如，“collect_count”：2，表示在兩個不同的文檔上調用了collect（）方法。 Profiling Considerations ? ?Performance Notes(性能說明) ? ? ?和任何分析器一樣，Profile API引入了一個不可忽略的搜索執行開銷。 插入低級方法調用（如collect，advance和next_doc）的行為可能相當費時，因為這些方法在緊密循環中調用。 因此，默認情況下不應在生產設置中啟用分析，并且不應與非分析查詢時間進行比較。 分析只是一個診斷工具。 ? ?還有一些情況下，特殊的Lucene優化被禁用，因為它們不適合進行概要分析。 這可能導致一些查詢報告比他們的非配置文件對應的更大的相對時間，但是通常不應該與配置文件查詢中的其他組件相比。 ? ?局限性 ? ?* 分析統計信息當前不可用，突出顯示，dfs_query_then_fetch ? ?* 聚合的縮減階段的分析當前不可用 ? ?* ?Profiler 仍然是高度實驗性的。 Profiler 是對 Lucene中從未設計過以這種方式暴露的部分進行檢測，因此所有結果都應被視為盡力提供詳細的診斷。 我們希望隨著時間的推移改善這一點。 如果你發現明顯錯誤的數字，奇怪的查詢結構或其他錯誤，請提出! Percolator ? Percolate Query? ? ?Percolate 查詢可以用于匹配存儲在索引中的查詢。 Percolate查詢本身包含將用作與存儲的查詢匹配的查詢的文檔。 ?示例: 創建兩個映射的索引： PUT /my-index { "mappings": { "doctype": { "properties": { "message": { "type": "text" } } }, "queries": { "properties": { "query": { "type": "percolator" } } } } } doctype 映射是用于預處理 Percolator 查詢中定義的文檔之前，它被索引到臨時索引中的映射。 queries 映射是用于索引查詢文檔的映射。 查詢字段將保存表示實際Elasticsearch查詢的json對象。queries 字段已配置為使用percolator field type。?此字段類型理解查詢dsl并以這樣的方式存儲查詢，以便稍后可以將其用于匹配在 percolate 查詢上定義的文檔。 ??在過濾器中注冊查詢： PUT /my-index/queries/1?refresh { "query" : { "match" : { "message" : "bonsai tree" } } } 將文檔與已注冊的過濾器查詢匹配： GET /my-index/_search { "query" : { "percolate" : { "field" : "query", "document_type" : "doctype", "document" : { "message" : "A new bonsai tree in the office" } } } } 上面請求將產生以下響應： { "took": 13, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 1, "max_score": 0.5716521, "hits": [ { （1） "_index": "my-index", "_type": "queries", "_id": "1", "_score": 0.5716521, "_source": { "query": { "match": { "message": "bonsai tree" } } } } ] } } （1）ID為1的查詢與我們的文檔匹配。 過濾器文檔時需要以下參數： ?field：類型 percolator 的字段，并保存索引查詢。 這是必需的參數。 document_type: 過濾器文檔type/mapping 映射，這是必需的參數 document：文檔的來源 ?代替指定正在被執行的文檔的源，還可以從已經存儲的文檔中檢索源。 過濾器查詢然后將在內部執行獲取請求以獲取該文檔。 在這種情況下，文檔參數可以用以下參數替換： index：文檔所在的索引。這是必需的參數。 type ：文檔所在的類型。這是必需的參數。 id：文檔所在的id。這是必需的參數。 routing：可選，用于獲取文檔以進行過濾的路由。 preference：優先使用過濾獲取文檔。 version：提取的文檔的預期版本。 過濾已有的文檔 ? ?為了過濾新索引的文檔，可以使用過濾查詢。 基于來自索引請求的響應，_id和其他元信息可以用于立即過濾新添加的文檔。 eg： 基于前面的例子。 索引要過濾的文檔： PUT /my-index/message/1 { "message" : "A new bonsai tree in the office" } 索引請求 { "_index": "my-index", "_type": "message", "_id": "1", "_version": 1, "_shards": { "total": 2, "successful": 1, "failed": 0 }, "created": true, "result": "created" } 過濾已有文檔 使用索引請求 去查詢 new的請求 GET /my-index/_search { "query" : { "percolate" : { "field": "query", "document_type" : "doctype", "index" : "my-index", "type" : "message", "id" : "1", "version" : 1 （1） } } } 版本是可選的，但在某些情況下有用。 然后，我們可以確保我們試圖過濾我們剛剛建立索引的文檔。在我們建立索引之后可以進行更改，如果是這樣，那么搜索請求將失敗，并出現版本沖突錯誤。 返回的搜索響應與上一個示例中的相同。 過濾查詢和高示顯示 過濾查詢在處理突出顯示時以特殊方式處理。 查詢命中用于突出顯示在 percolate 查詢中提供的文檔。 而定期突出顯示在搜索請求中的查詢用于突出點擊。 eg: 此示例是用第一個示例的映射。 第一個查詢 PUT /my-index/queries/1?refresh { "query" : { "match" : { "message" : "brown fox" } } } 第二個查詢 PUT /my-index/queries/2?refresh { "query" : { "match" : { "message" : "lazy dog" } } } 執行具有過濾查詢和高示顯示的搜索請求： GET /my-index/_search { "query" : { "percolate" : { "field": "query", "document_type" : "doctype", "document" : { "message" : "The quick brown fox jumps over the lazy dog" } } }, "highlight": { "fields": { "message": {} } } } 這將產生以下響應。 { "took": 7, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 2, "max_score": 0.5446649, "hits": [ { "_index": "my-index", "_type": "queries", "_id": "2", "_score": 0.5446649, "_source": { "query": { "match": { "message": "lazy dog" } } }, "highlight": { "message": [ "The quick brown fox jumps over the <em>lazy</em> <em>dog</em>" ] } }, { "_index": "my-index", "_type": "queries", "_id": "1", "_score": 0.5446649, "_source": { "query": { "match": { "message": "brown fox" } } }, "highlight": { "message": [ "The quick <em>brown</em> <em>fox</em> jumps over the lazy dog" ] } } ] } } ? ?代替在搜索請求中的查詢高示顯示滲濾器命中，滲濾器查詢突出顯示在過濾查詢中定義的文檔。 ? ?如果工作的當將文檔索引到配置了 percolator field type 映射的索引時，文檔的查詢部分將被解析為Lucene查詢并存儲到Lucene索引中。?查詢的二進制表示被存儲，而且查詢的項被分析并存儲到索引字段中。 ? ?在搜索時，請求中指定的文檔將被解析為Lucene文檔，并存儲在內存中的臨時Lucene索引中。 這個內存索引只能保存這一個文檔，并為此進行了優化。 此后，基于存儲器內索引中的項來構建特殊查詢，該項基于它們的索引查詢項來選擇候選過濾器查詢。 然后，如果這些查詢實際匹配，則由內存索引評估這些查詢。 ? ? 候選滲濾器查詢匹配的選擇在執行過濾查詢期間是重要的性能優化， ??因為它可以顯著減少存儲器內索引需要評估的候選匹配的數量。過濾查詢可以執行此操作的原因是因為在過濾器查詢的索引期間， 查詢術語正在被提取并用滲濾器查詢索引。 不幸的是，過濾器不能從所有查詢（例如通配符或geo_shape查詢）中提取術語，因此在某些情況下，滲濾器不能進行選擇優化（例如，如果一個不支持的查詢在 布爾查詢或不支持的查詢是滲透文檔中的唯一查詢）。 ? ? 這些查詢由過濾器標記，可以通過運行以下搜索找到： GET /_search { "query": { "term" : { "query.extraction_result" : "failed" } } } Field States API ? ?字段數據 API 允許在不執行搜索的情況下查找字段的統計屬性，但查找Lucene索引中本機可用的度量。 這可以用來探索一個你不確定的數據集。? ? ?例如，這允許基于值的man/min范圍創建具有有意義間隔的直方圖聚集。 ? ?全部索引 curl -XGET "[http://localhost:9200/_field_stats?fields=rating](http://localhost:9200/_field_stats?fields=rating)" 具體索引 curl -XGET "[http://localhost:9200/index1,index2/_field_stats?fields=rating](http://localhost:9200/index1,index2/_field_stats?fields=rating)" 請求的選項 fields：要計算統計信息的字段列表。 字段名稱支持通配符符號。 例如，使用text_ *將導致返回與表達式匹配的所有字段。 level：定義是否應在每個索引級別或群集級別返回字段統計信息。 有效值為索引和集群（默認）。 或者，也可以在請求主體中定義fields選項： curl -XPOST "[http://localhost:9200/_field_stats?level=indices](http://localhost:9200/_field_stats?level=indices)" -d '{ "fields" : ["rating"] }' 字段統計數據 字段stats API支持基于字符串，基于數字和基于日期的字段，并且可以為每個字段返回以下統計信息： max_doc：文檔總數 doc_count：具有此字段至少一個術語的文檔數，如果此度量在一個或多個分片上不可用，則為-1。 density：此字段至少有一個值的文檔的百分比。 這是一個導出的統計信息，基于max_doc和doc_count。 sum_doc_freq：此字段中每個術語的文檔頻率的總和，如果此測量在一個或多個分片上不可用，則為-1。 文檔頻率是包含特定字詞的文檔數。 sum_total_term_freq：所有文檔中此字段中所有術語的術語頻率之和，如果此度量在一個或多個分片上不可用，則為-1。 術語頻率是術語在特定文檔和字段中出現的總數。 is_searchable 如果字段的任何實例可搜索，則為true，否則為false。 is_aggregatable 如果字段的任何實例是可聚合的，則為True，否則為false。 min_value 字段中的最小值。 min_value_as_string 字段中的最低值以可顯示的形式表示。 所有字段，但字符串字段返回此。 （因為字符串字段，表示已經作為字符串的值） max_value 字段中的最高值。 max_value_as_string 字段中的最高值以可顯示的形式表示。 所有字段，但字符串字段返回此。 （因為字符串字段，表示已經作為字符串的值） 集群級別字段數據的例子 請求 curl -XGET "[http://localhost:9200/_field_stats?fields=rating,answer_count,creation_date,display_name](http://localhost:9200/_field_stats?fields=rating,answer_count,creation_date,display_name)" 響應 { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "indices": { "_all": { （1） "fields": { "creation_date": { "max_doc": 1326564, "doc_count": 564633, "density": 42, "sum_doc_freq": 2258532, "sum_total_term_freq": -1, "min_value": "2008-08-01T16:37:51.513Z", "max_value": "2013-06-02T03:23:11.593Z", "is_searchable": "true", "is_aggregatable": "true" }, "display_name": { "max_doc": 1326564, "doc_count": 126741, "density": 9, "sum_doc_freq": 166535, "sum_total_term_freq": 166616, "min_value": "0", "max_value": "???", "is_searchable": "true", "is_aggregatable": "false" }, "answer_count": { "max_doc": 1326564, "doc_count": 139885, "density": 10, "sum_doc_freq": 559540, "sum_total_term_freq": -1, "min_value": 0, "max_value": 160, "is_searchable": "true", "is_aggregatable": "true" }, "rating": { "max_doc": 1326564, "doc_count": 437892, "density": 33, "sum_doc_freq": 1751568, "sum_total_term_freq": -1, "min_value": -14, "max_value": 1277, "is_searchable": "true", "is_aggregatable": "true" } } } } } （1）_all鍵表示它包含集群中所有索引的字段統計信息。 當使用集群級別字段統計時，如果在具有不兼容類型的不同索引中使用相同的字段，則可能存在沖突。 例如，long類型的字段與float或string類型的字段不兼容。 如果出現一個或多個沖突，則會將名為沖突的節添加到響應中。 它包含所有具有沖突的字段和不兼容的原因。 { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "indices": { "_all": { "fields": { "creation_date": { "max_doc": 1326564, "doc_count": 564633, "density": 42, "sum_doc_freq": 2258532, "sum_total_term_freq": -1, "min_value": "2008-08-01T16:37:51.513Z", "max_value": "2013-06-02T03:23:11.593Z", "is_searchable": "true", "is_aggregatable": "true" } } } }, "conflicts": { "field_name_in_conflict1": "reason1", "field_name_in_conflict2": "reason2" } } 索引級別字段例子 請求 curl -XGET "[http://localhost:9200/_field_stats?fields=rating,answer_count,creation_date,display_name&level=indices](http://localhost:9200/_field_stats?fields=rating,answer_count,creation_date,display_name&level=indices)" 響應： { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "indices": { "stack": { （1） "fields": { "creation_date": { "max_doc": 1326564, "doc_count": 564633, "density": 42, "sum_doc_freq": 2258532, "sum_total_term_freq": -1, "min_value": "2008-08-01T16:37:51.513Z", "max_value": "2013-06-02T03:23:11.593Z", "is_searchable": "true", "is_aggregatable": "true" }, "display_name": { "max_doc": 1326564, "doc_count": 126741, "density": 9, "sum_doc_freq": 166535, "sum_total_term_freq": 166616, "min_value": "0", "max_value": "???", "is_searchable": "true", "is_aggregatable": "false" }, "answer_count": { "max_doc": 1326564, "doc_count": 139885, "density": 10, "sum_doc_freq": 559540, "sum_total_term_freq": -1, "min_value": 0, "max_value": 160, "is_searchable": "true", "is_aggregatable": "true" }, "rating": { "max_doc": 1326564, "doc_count": 437892, "density": 33, "sum_doc_freq": 1751568, "sum_total_term_freq": -1, "min_value": -14, "max_value": 1277, "is_searchable": "true", "is_aggregatable": "true" } } } } } stack 鍵意味著它包含 stack 索引的所有字段統計信息。 字段數據索引的約束 ? 字段統計信息索引約束允許省略與約束不匹配的索引的所有字段統計信息。 索引約束可以基于min_value和max_value統計量排除索引的字段統計信息。 此選項僅在level選項設置為indices時有用。 ??例如，索引約束可用于在基于時間的情況下找出數據的特定屬性的最小值和最大值。? ? ?以下請求僅返回2014年創建的問題的索引的answer_count屬性的字段統計信息： curl -XPOST "[http://localhost:9200/_field_stats?level=indices](http://localhost:9200/_field_stats?level=indices)" -d '{ "fields" : ["answer_count"] （1） "index_constraints" : { （2） "creation_date" : { （3） "max_value" : { （4） "gte" : "2014-01-01T00:00:00.000Z" }, "min_value" : {（5） "lt" : "2015-01-01T00:00:00.000Z" } } } }' （1）計算和返回字段統計信息的字段。 （2）設置索引約束。 請注意，可以為未在fields選項中定義的字段定義索引約束。 （3）字段creation_date的索引約束。 （4）字段統計信息的max_value和min_value屬性的索引約束。 ?(5)對于字段，可以在min_value統計量，max_value統計量或兩者上定義索引約束。每個索引約束支持以下比較： ? ? ?gte:大于或等于 ? ? ?gt: 大于 ? ? lte ：小于或等于 ? ? ?lt ：小于 字段統計信息日期字段的索引約束可選地接受格式選項，用于解析約束的值。 如果缺少，則使用字段映射中配置的格式。 curl -XPOST "[http://localhost:9200/_field_stats?level=indices](http://localhost:9200/_field_stats?level=indices)" -d '{ "fields" : ["answer_count"] "index_constraints" : { "creation_date" : { "max_value" : { "gte" : "2014-01-01", "format" : "date_optional_time" （1） }, "min_value" : { "lt" : "2015-01-01", "format" : "date_optional_time" } } } }' 自定義日期格式 ## Percolator ## Field stats API