天天看點
傳回

ES_權威指南

time_out

time_out 值告訴我們查詢逾時與否。一般的，搜尋請求不會逾時。如果響應速度比完整的結果更重要，你可以定義 timeout 參數為10 或者10ms（10毫秒），或者1s（1秒）

GET /_search?timeout=ms

Elasticsearch将傳回在請求逾時前收集到的結果。

逾時不是一個斷路器（circuit breaker）（譯者注：關于斷路器的了解請看警告）。

警告：

需要注意的是 timeout 不會停止執行查詢，它僅僅告訴你目前順利傳回結果的節點然後關閉連接配接。在背景，其他分片可能依舊執行查詢，盡管結果已經被發送。

使用逾時是因為對于你的業務需求（譯者注：SLA，Service-Level Agreement服務等級協定，在此我翻譯為業務需求）來說非常重要，而不是因為你想中斷執行長時間運作的查詢。

在叢集系統中深度分頁

為了了解為什麼深度分頁是有問題的，讓我們假設在一個有5個主分片的索引中搜尋。當我們請求結果的第一頁（結果1到10）時，每個分片産生自己最頂端10個結果然後傳回它們給請求節點(requesting node)，它再排序這所有的50個結果以選出頂端的10個結果。

現在假設我們請求第1000頁——結果10001到10010。工作方式都相同，不同的是每個分片都必須産生頂端的10010個結果。然後請求節點排序這50050個結果并丢棄50040個！

你可以看到在分布式系統中，排序結果的花費随着分頁的深入而成倍增長。這也是為什麼網絡搜尋引擎中任何語句不能傳回多于1000個結果的原因。

搜尋

1.查詢字元串（query string）：将所有參數通過查詢字元串定義；

适合在指令行下運作點對點查詢；

優點：簡潔明快的表示複雜查詢，對于指令行下一次性查詢或開發模式下非常有用；

缺點：簡潔帶來了隐晦、調試困難、脆弱（一個細小的文法錯誤就會導緻傳回錯誤而不是結果）；允許任意使用者在索引中任何一個字段上運作潛在的慢查詢語句，可能暴露私有資訊甚至使叢集癱瘓（是以不建議直接暴露查詢字元串搜尋給使用者）。

2.結構化查詢（DSL）：使用JSON完整的表示請求體（request body）

映射(mapping)機制用于進行字段類型确認，将每個字段比對為一種确定的資料類型。

分析(analysis)機制用于進行全文文本(Full Text)的分詞，以建立供搜尋用的反向索引。

确切值(Exact values) vs. 全文文本(Full text)

反向索引

Elasticsearch使用一種叫做反向索引(inverted index)的結構來做快速的全文搜尋。反向索引由在文檔中出現的唯一的單詞清單，以及對于每個單詞在文檔中的位置組成。

為了建立反向索引，我們首先切分每個文檔的 content 字段為單獨的單詞（我們把它們叫做詞(terms)或者表征(tokens)），把所有的唯一詞放入清單并排序

表征化和标準化的過程叫做分詞(analysis)

分析和分析器

分析（analysis）：

首先，表征化一個文本塊為适用于反向索引單獨的詞（term）；

然後，标準化這些詞為标準形式，提高它們的“可搜尋性”或“查全率”。

這個工作由分析器（analyzer）完成。一個分析器隻是一個包裝用于将三個功能放到一個包裡：

字元過濾器（character filter）：

字元串先經過字元過濾器，在表征化（斷詞）前處理字元串，可去除HTML标記或轉換“&”為“and”

分詞器（tokenizer）：

字元串通過分詞器被表征化（斷詞）為獨立的詞。一個簡單的分詞器可根據空格或逗号将單詞分開（不适用中文）

表征過濾（token filters）：

每個詞都通過所有表征過濾，它可以修改詞（如将“Quick”轉換為小寫），去掉詞（如停用詞像“a"、"and"、”the"等），或增加詞（如同義詞像“jump”和“leap”）

ES内置分析器

"Set the shape to semi-transparent by calling set_trans(5)"

标準分析器：（standard）

标準分析器是Elasticsearch預設使用的分析器。對于文本分析，它對于任何語言都是最佳選擇（譯者注：就是沒啥特殊需求，對于任何一個國家的語言，這個分析器就夠用了）。它根據Unicode Consortium的定義的單詞邊界(word boundaries)來切分文本，然後去掉大部分标點符号。最後，把所有詞轉為小寫。産生的結果為：

set, the, shape, to, semi, transparent, by, calling, set_trans, 5

簡單分析器：（simple）

簡單分析器将非單個字母的文本切分，然後把每個詞轉為小寫。産生的結果為：

set, the, shape, to, semi, transparent, by, calling, set, trans

空格分析器：（whitespace）

空格分析器依據空格切分文本。它不轉換小寫。産生結果為：

Set, the, shape, to, semi-transparent, by, calling, set_trans(5)

語言分析器：（english）

特定語言分析器适用于很多語言。它們能夠考慮到特定語言的特性。例如， english 分析器自帶一套英語停用詞庫——像 and 或 the 這些與語義無關的通用詞。這些詞被移除後，因為文法規則的存在，英語單詞的主體含義依舊能被了解。english 分析器将會産生以下結果：

set, shape, semi, transpar, call, set_tran, 5

注意 "transparent" 、 "calling" 和 "set_trans" 是如何轉為詞幹的。

當分析器被使用

當我們索引(index)一個文檔，全文字段會被分析為單獨的詞來建立反向索引。不過，當我們在全文字段搜尋(search)時，我們要讓查詢字元串經過同樣的分析流程處理，以確定這些詞在索引中存在。

當你查詢全文(full text)字段，查詢将使用相同的分析器來分析查詢字元串，以産生正确的詞清單。

當你查詢一個确切值(exact value)字段，查詢将不分析查詢字元串，但是你可以自己指定。

index

index 參數控制字元串以何種方式被索引。它包含以下三個值當中的一個：

analyzed：首先分析這個字元串，然後索引（即 以全文形式索引此字段）；

not_analyzed：索引這個字段使之可以被搜尋，但索引内容和指定值一樣。不分析此字段；

no：不索引這個字段。這個字段不能被搜尋到。

2.x以上版本，想要檢視索引中某個字段的分析内容，分詞結果：

GET /index/type/id/_termvectors?fields=your_type1,your_type2....

空字段

Lucene沒法存放 null 值，是以一個 null 值的字段被認為是空字段

這四個字段将被識别為空字段而不被索引：

"empty_string": " ",

"null_value": null,

"empty_array": [ ],

"array_with_null_value": [ null ]

查詢與過濾

結構化查詢（Query DSL） 結構化過濾（Filter DSL）

一條過濾語句會詢問每個文檔的字段值是否包含着特定值；

一條查詢語句會詢問每個文檔的字段值與特定值的比對程度如何。

一條查詢語句會計算每個文檔與查詢語句的相關性，會給出一個相關性評分 _score ，并且按照相關性對比對到的文檔進行排序。這種評分方式非常适用于一個沒有完全配置結果的全文本搜尋。

性能差異

使用過濾語句得到的結果集---一個簡單的文檔清單，快速比對運算并存入記憶體是十分友善的，每個文檔僅需要1個位元組。這些緩存的過濾結果集與後續請求的結合使用是非常高效的。

查詢語句不僅要查找相比對的文檔，還需要計算每個文檔的相關性，是以一般來說查詢語句要比過濾語句更耗時，并且查詢結果也不可緩存。

幸虧有了反向索引，一個隻比對少量文檔的簡單查詢語句在百萬級文檔中的查詢效率會與一條經過緩存的過濾語句旗鼓相當，甚至略占上風。 但是一般情況下，一條經過緩存的過濾查詢要遠勝一條查詢語句的執行效率。

過濾語句的目的就是縮小比對的文檔結果集，是以需要仔細檢查過濾條件。

原則上講，做全文本搜尋或其他需要進行相關性評分的時候使用查詢語句，剩下的全部用過濾語句

term 過濾

term 主要用于精确比對哪些值，比如數字，日期，布爾值或 not_analyzed 的字元串(未經分析的文本資料類型)

terms 過濾

terms跟 term有點類似，但 terms允許指定多個比對條件。如果某個字段指定了多個值，那麼文檔需要一起去做比對

range 過濾

exists 和 missing 過濾

exists和missing過濾可以用于查找文檔中是否包含指定字段或沒有某個字段，類似于SQL語句中的 IS_NULL 條件；這兩個過濾隻是針對已經查出一批資料來，但是想區分出某個字段是否存在的時候使用。

bool 過濾

bool 過濾可以用來合并多個過濾條件查詢結果的布爾邏輯，它包含一下操作符：

must :: 多個查詢條件的完全比對,相當于 and 。

must_not :: 多個查詢條件的相反比對，相當于 not 。

should :: 至少有一個查詢條件比對, 相當于 or 。

這些參數可以分别繼承一個過濾條件或者一個過濾條件的數組 。

bool 查詢

bool 查詢與 bool過濾相似，用于合并多個查詢子句。不同的是， bool 過濾可以直接給出是否比對成功， 而 bool查詢要計算每一個查詢子句的 _score（相關性分值）。

must :: 查詢指定文檔一定要被包含。

must_not :: 查詢指定文檔一定不要被包含。

should :: 查詢指定文檔，有則可以為文檔相關性加分。

字段值排序

對結果按時間排序，date字段在内部被轉為毫秒；

計算 _score是比較消耗性能的,而且通常主要用作排序--我們不是用相關性進行排序的時候，就不需要統計其相關性。如果你想強制計算其相關性，可以設定 track_scores 為 true。

多級排序

e.g.

     
  1.  "sort": [       
    2.       
  2.  {       
    3.       
  3.  "time": {           "order":           "desc" },       
    4.       
  4.  "_score": {           "order":           "desc" }       
    5.       
  5.  }       
    6.       
  6.  ]       
    7.

先按時間倒序排序，時間一樣時再按評分倒序排序

相關性簡介

查詢語句會為每個文檔添加一個_score字段。評分的計算方式取決于不同的查詢類型--不同的查詢語句用于不同的目的： fuzzy查詢會計算與關鍵詞的拼寫相似程度， terms 查詢會計算找到的内容與關鍵詞組成部分比對的百分比，但是一般意義上我們說的全文本搜尋是指計算内容與關鍵詞的類似程度。

ElasticSearch的相似度算法被定義為TF/IDF，即檢索詞頻率/反向文檔頻率

資料字段

當搜尋的時候，我們需要用檢索詞去周遊所有的文檔。

當排序的時候，我們需要周遊文檔中所有的值，我們需要做反倒序排列操作。

為了提高排序效率，ElasticSearch 會将所有字段的值加載到記憶體中，這就叫做"資料字段"。

重要：ElasticSearch将所有字段資料加載到記憶體中并不是比對到的那部分資料，而是索引下所有文檔中的值，包括所有類型。

将所有字段資料加載到記憶體中是因為從硬碟反向反向索引是非常緩慢的。盡管你這次請求需要的是某些文檔中的部分資料，但你下個請求卻需要另外的資料，是以将所有字段資料一次性加載到記憶體中是十分必要的。

ElasticSearch中的字段資料常被應用到以下場景：

  • 對一個字段進行排序
  • 對一個字段進行聚合
  • 某些過濾，比如地理位置過濾
  • 某些與字段相關的腳本計算

毫無疑問，這會消耗掉很多記憶體，尤其是大量的字元串資料。

記憶體不足可以通過橫向擴充解決，我們可以增加更多的節點到叢集。

分布式搜尋

注：可增加對系統如何工作的了解，不必淹沒在細節裡。

搜尋的執行過程分兩個階段，查詢 和 取回 （query then fetch ）

查詢：找到所有比對文檔；

取回：來自多個分片的結果被組合放到一個有序清單中。

查詢階段

在初始化查詢階段（query phase），查詢被向索引中的每個分片副本（原本或副本）廣播。每個分片在本地執行搜尋并且建立了比對document的優先隊列（priority queue）。

一個優先隊列（priority queue is）隻是一個存有前n個（top-n）比對document的有序清單。這個優先隊列的大小由分頁參數from和size決定。

ES_權威指南

查詢階段包含以下三步：

  • 1.用戶端發送一個 search（搜尋） 請求給 Node3 , Node3 建立了一個長度為from+size的空優先級隊列。
  • 2. Node3 轉發這個搜尋請求到索引中每個分片的原本或副本。每個分片在本地執行這個查詢并且将結果彙總到一個大小為 from+size 的有序本地優先隊列裡去。
  • 3.每個分片傳回document的ID和它優先隊列裡所有document的排序值給協調節點Node3。 Node3把這些值合并到自己的優先隊列裡産生全局排序結果。

當一個搜尋請求被發送到一個節點Node，這個節點就變成了協調節點。這個節點的工作是向所有相關的分片廣播搜尋請求并且把它們的響應整合成一個全局的有序結果集。這個結果集會被傳回給用戶端。

第一步是向索引裡的每個節點的分片副本廣播請求。就像document的GET 請求一樣，搜尋請求可以被每個分片的原本或任意副本處理。這就是更多的副本（當結合更多的硬體時）如何提高搜尋的吞吐量的方法。對于後續請求，協調節點會輪詢所有的分片副本以分攤負載。

每一個分片在本地執行查詢和建立一個長度為 from+size 的有序優先隊列——這個長度意味着它自己的結果數量就足夠滿足全局的請求要求。分片傳回一個輕量級的結果清單給協調節點。隻包含documentID值和排序需要用到的值，例如 _score 。

協調節點将這些分片級的結果合并到自己的有序優先隊列裡。這個就代表了最終的全局有序結果集。到這裡，查詢階段結束。

注意：一個索引可以由一個或多個原始分片組成，是以一個對于單個索引的搜尋請求也需要能夠把來自多個分片的結果組合起來。一個對于多（multiple）或全部（all）索引的搜尋的工作機制和這完全一緻——僅僅是多了一些分片而已。

取回階段

查詢階段辨識出那些滿足搜尋請求的document，但我們仍然需要取回那些document本身。這就是取回階段的工作，如圖分布式搜尋的取回階段所示。

ES_權威指南

分發階段由以下步驟構成：

  • 1.協調節點辨識出哪個document需要取回，并且向相關分片發出GET 請求。
  • 2.每個分片加載document并且根據需要豐富（enrich）它們，然後再将document傳回協調節點。
  • 3.一旦所有的document都被取回，協調節點會将結果傳回給用戶端。

協調節點先決定哪些document是實際（actually）需要取回的。例如，我們指定查詢 {"from": 90, "size":10} ，那麼前90條将會被丢棄，隻有之後的10條會需要取回。這些document可能來自與原始查詢請求相關的某個、某些或者全部分片。

協調節點為每個持有相關document的分片建立多點get請求然後發送請求到處理查詢階段的分片副本。

分片加載document主體——source field。如果需要，還會根據中繼資料豐富結果和高亮搜尋片斷。一旦協調節點收到所有結果，會将它們彙集到單一的回答響應裡，這個響應将會傳回給用戶端。

深分頁

根據document數量，分片數量以及所用硬體，對10,000到50,000條結果（1000到5000頁）深分頁是可行的（一般控制最多分頁數1000）；

如果确實需要從叢集裡擷取大量documents，可設定搜尋類型scan禁用排序，來高效地做這件事。

preference（偏愛）

preference參數允許你控制使用哪個分片或節點來處理搜尋請求。她接受如下一些參數_primary，_primary_first，_local， _only_node:xyz， _prefer_node:xyz和 _shards:2,3。這些參數在文檔搜尋偏好（search preference）裡有較長的描述。

然而通常最有用的值是一些随機字元串，它們可以避免結果震蕩問題（the bouncing results problem）。

結果震蕩（Bouncing Results）：

想像一下，你正在按照timestamp 字段來對你的結果排序，并且有兩個document有相同timestamp。由于搜尋請求是在所有有效的分片副本間輪詢的，這兩個document可能在原始分片裡是一種順序，在副本分片裡是另一種順序。

這就是被稱為結果震蕩（bouncing results）的問題：使用者每次重新整理頁面，結果順序會發生變化。避免這個問題方法是對于同一個使用者總是使用同一個分片。方法就是使用一個随機字元串例如使用者的會話ID（session ID）來設定 preference參數。

分析器

standard分析器是用于全文字段的預設分析器，對于大部分西方語系來說是一個不錯的選擇。它考慮了以下幾點：

  • standard 分詞器，在詞層級上分割輸入的文本。
  • standard 表征過濾器，被設計用來整理分詞器觸發的所有表征（但是目前什麼都沒做）。
  • lowercase 表征過濾器，将所有表征轉換為小寫。
  • stop 表征過濾器，删除所有可能會造成搜尋歧義的停用詞，如 a，he， and ， is 。

預設情況下，停用詞過濾器是被禁用的。如需啟用它，你可以通過建立一個基于 standard分析器的自定義分析器，并且設定 stopwords參數。可以提供一個停用詞清單，或者使用一個特定語言的預定停用詞清單。

e.g.建立一個新分析器 new_std ，并使用預定義的停用詞 stop ：

     
  1.  PUT /es_standard_test       
    2.       
  2.  {       
    3.       
  3.  "settings": {       
    4.       
  4.  "analysis": {       
    5.       
  5.  "analyzer": {       
    6.       
  6.  "new_std":{       
    7.       
  7.  "type":          "standard",       
    8.       
  8.  "stopwords":          "stop"       
    9.       
  9.  }       
    10.       
  10.  }       
    11.       
  11.  }       
    12.       
  12.  }       
    13.       
  13.  }       
    14.

new_std 分析器不是全局的，它僅存在于定義的 es_standard_test 索引中，是以測試它需使用特定的索引名：

     
  1.  GET /es_standard_test/_analyze       
    2.       
  2.  {       
    3.       
  3.  "text": [          "test stop es"],       
    4.       
  4.  "analyzer":           "new_std"       
    5.       
  5.  }       
    6.

響應結果如下：

     
  1.  {       
    2.       
  2.  "tokens": [       
    3.       
  3.  {       
    4.       
  4.  "token":           "test",       
    5.       
  5.  "start_offset":           ,       
    6.       
  6.  "end_offset":           ,       
    7.       
  7.  "type":           "<ALPHANUM>",       
    8.       
  8.  "position":       
    9.       
  9.  },       
    10.       
  10.  {       
    11.       
  11.  "token":           "es",       
    12.       
  12.  "start_offset":           ,       
    13.       
  13.  "end_offset":           ,       
    14.       
  14.  "type":           "<ALPHANUM>",       
    15.       
  15.  "position":       
    16.       
  16.  }       
    17.       
  17.  ]       
    18.       
  18.  }       
    19.

别名

兩種管理别名的途徑： _alias 用于單個操作， _aliases 用于原子化多個操作

假設你的應用采用一個叫 my_index 的索引。而事實上， my_index 是一個指向目前真實索引的别名。真實的索引名将包含一個版本号： my_index_v1 , my_index_v2 等

首先，建立一個索引 my_index_v1 ， 然後将别名 my_index 指向它：

     
  1.  PUT my_index_v1       
    2.           
  2.  PUT my_index_v1/_alias/my_index       
    3.

可以檢測這個别名指向哪個索引：

GET /*/_alias/my_index

或哪些别名指向這個索引：

GET my_index_v1/_alias/*

上述操作均傳回結果：

     
  1.  {       
    2.       
  2.  "my_index_v1": {       
    3.       
  3.  "aliases": {       
    4.       
  4.  "my_index": {}       
    5.       
  5.  }       
    6.       
  6.  }       
    7.       
  7.  }       
    8.

然後，我們決定修改索引中一個字段的映射。當然我們不能修改現存的映射，索引我們需要重新索引資料。首先，我們建立有新的映射的索引 my_index_v2 。

     
  1.  PUT my_index_v2       
    2.       
  2.  {       
    3.       
  3.  "mappings": {       
    4.       
  4.  "test":{       
    5.       
  5.  "properties":{       
    6.       
  6.  "tags":{       
    7.       
  7.  "type":          "keyword"       
    8.       
  8.  }       
    9.       
  9.  }       
    10.       
  10.  }       
    11.       
  11.  }       
    12.       
  12.  }       
    13.

然後我們從将資料從 my_index_v1 遷移到 my_index_v2 ，一旦我們認為資料已經被正确的索引了，我們就将别名指向新的索引。

     
  1.  POST _reindex       
    2.       
  2.  {       
    3.       
  3.  "source": {       
    4.       
  4.  "index":           "my_index_v1"       
    5.       
  5.  },       
    6.       
  6.  "dest": {       
    7.       
  7.  "index":           "my_index_v2"       
    8.       
  8.  }       
    9.       
  9.  }       
    10.

别名可以指向多個索引，是以我們需要在新索引中添加别名的同時從舊索引中删除它。這個操作需要原子化，是以我們需要用 _aliases 操作：

     
  1.  POST _aliases       
    2.       
  2.  {       
    3.       
  3.  "actions": [       
    4.       
  4.  {       
    5.       
  5.  "remove": {       
    6.       
  6.  "index":           "my_index_v1",       
    7.       
  7.  "alias":           "my_index"       
    8.       
  8.  }       
    9.       
  9.  },       
    10.       
  10.  {       
    11.       
  11.  "add": {       
    12.       
  12.  "index":           "my_index_v2",       
    13.       
  13.  "alias":           "my_index"       
    14.       
  14.  }       
    15.       
  15.  }       
    16.       
  16.  ]       
    17.       
  17.  }       
    18.

這樣，你的應用就從舊索引遷移到了新的，而沒有停機時間

查找準确值

對于準确值，你需要使用過濾器。過濾器的重要性在于它們非常的快。它們不計算相關性（避過所有計分階段）而且很容易被緩存。

用于數字的 term 過濾器

這個過濾器旨在處理數字，布爾值，日期，和文本；

過濾器不會執行計分和計算相關性。分值由 match_all 查詢産生，所有文檔一視同仁，所有每個結果的分值都是 1；

用于文本的 term 過濾器

not_indexed、

keyword

查詢多個準确值 - terms 過濾器

了解 term 和 terms 是包含操作，而不是相等操作

term 過濾器是怎麼工作的：它檢查反向索引中所有具有短語的文檔，然後組成一個位元組集。

提示：反向索引的特性讓完全比對一個字段變得非常困難。你将如何确定一個文檔隻能包含你請求的短語？你将在索引中找出這個短語，解出所有相關文檔 ID，然後掃描索引中每一行來确定文檔是否包含其他值。由此可見，這将變得非常低效和開銷巨大。是以，term和 terms 是必須包含操作，而不是必須相等

範圍

日期範圍

用于日期字段時，range 過濾器支援日期數學操作。例如，我們想找到所有最近一個小時的文檔：

     
  1.  "range":{       
    2.       
  2.  "timestamp":{            "gt":           "now-1h"   }       
    3.       
  3.  }       
    4.

這個過濾器将始終能找出所有時間戳大于目前時間減 1 小時的文檔，讓這個過濾器像移窗一樣通過你的文檔。

日期計算也能用于實際的日期，而不是僅僅是一個像 now 一樣的占位符。隻要在日期後加上雙豎線 || ，就能使用日期數學表達式了:

     
  1.  "range":{       
    2.       
  2.  "timestamp":{       
    3.       
  3.  "gt" :           "2018-01-01 00:00:00",       
    4.       
  4.  "lt" :           "2018-01-01 00:00:00 || +1M"       
    5.       
  5.  }       
    6.       
  6.  }       
    7.

早于2018年1月1号加一個月（即大于2018年1月1号小于2018年2月1号）

字元串範圍

反向索引中的短語按照字典順序排序，也是為什麼字元串範圍使用這個順序

假如我們想讓範圍從 a開始而不包含 b ，我們可以用類似的 range過濾器文法：

     
  1.  "range":{       
    2.       
  2.  "title":{       
    3.       
  3.  "gte":          "a",       
    4.       
  4.  "lt":          "b"       
    5.       
  5.  }       
    6.       
  6.  }       
    7.

當心基數：

數字和日期字段的索引方式讓他們在計算範圍時十分高效。但對于字元串來說卻不是這樣。為了在字元串上執行範圍操作，Elasticsearch會在這個範圍内的每個短語執行 term 操作。這比日期或數字的範圍操作慢得多。

字元串範圍适用于一個基數較小的字段，一個唯一短語個數較少的字段。你的唯一短語數越多，搜尋就越慢。

處理Null值

反向索引是表征和包含它們的文檔的一個簡單清單。假如一個字段不存在，它就沒有任何表征，也就意味着它無法被反向索引的資料結構表達出來。

本質上來說，null， [] （空數組）和 [null] 是相等的。它們都不存在于反向索引中！

為應對資料缺失字段，或包含空值或空數組，ES有一些工具來處理空值或缺失字段。

  • exists過濾器： 傳回任何包含這個字段的文檔
  • missing過濾器： 傳回沒有特定字段值的文檔

緩存

過濾器的核心是一個位元組集來表示哪些文檔符合這個過濾器。Elasticsearch主動緩存了這些位元組集留作以後使用。一旦緩存後，當遇到相同的過濾時，這些位元組集就可以被重用，而不需要重新運算整個過濾。

緩存的位元組集很“聰明”：他們會增量更新。你索引中添加了新的文檔，隻有這些新文檔需要被添加到已存的位元組集中，而不是一遍遍重新計算整個緩存的過濾器。過濾器和整個系統的其他部分一樣是實時的，你不需要關心緩存的過期時間。

獨立的過濾緩存

每個過濾器都被獨立計算和緩存，而不管它們在哪裡使用。如果兩個不同的查詢使用相同的過濾器，則會使用相同的位元組集。同樣，如果一個查詢在多處使用同樣的過濾器，隻有一個位元組集會被計算和重用。

控制緩存

大部分直接處理字段的枝葉過濾器（例如 term ）會被緩存，而像 bool 這類的組合過濾器則不會被緩存。

提示：

枝葉過濾器需要在硬碟中檢索反向索引，是以緩存它們是有意義的。另一方面來說，組合過濾器使用快捷的位元組邏輯來組合它們内部條件生成的位元組集結果，是以每次重新計算它們也是很高效的。

然而，有部分枝葉過濾器，預設不會被緩存，因為它們這樣做沒有意義：

  • 腳本過濾器
  • Geo過濾器
  • 日期範圍

有時候預設的緩存測試并不正确。可能你希望一個複雜的 bool 表達式可以在相同的查詢中重複使用，或你想要禁用一個 date 字段的過濾器緩存。你可以通過 _cache 标記來覆寫幾乎所有過濾器的預設緩存政策：

     
  1.  "range":{       
    2.       
  2.  "timestamp":{       
    3.       
  3.  "gt":          "2018-01-02 16:15:14"       
    4.       
  4.  },       
    5.       
  5.  "_cache"：          false	          //在這個過濾器上禁用緩存       
    6.       
  6.  }       
    7.           
  7.  “_cache” ： ES           .X版本；          .X版本起已經棄用，改用如下方式：       
    8.           
  8.  GET gaoyh/_search?request_cache=          false       
    9.       
  9.  {       
    10.       
  10.  "query": {       
    11.       
  11.  "range": {       
    12.       
  12.  "time": {       
    13.       
  13.  "lt":           "now-1h"       
    14.       
  14.  }       
    15.       
  15.  }       
    16.       
  16.  }       
    17.       
  17.  }       
    18.

監控緩存使用情況

可以通過索引檢視緩存的大小（以位元組為機關）和驅逐的數量，使用indices-statsAPI：

GET /_stats/request_cache?human

或者通過nodes-statsAPI 的節點：

GET /_nodes/stats/indices/request_cache?human

可以使用clear-cacheAPI手動過期緩存：

     
  1.  POST /index_name/_cache/clear?          request=          true       
    2.

預設情況下啟用緩存，但在建立新索引時可以禁用緩存：

PUT /my_index { "settings": { "index.requests.cache.enable": false } }

也可以使用update-settingsAPI 在現有索引上動态啟用或禁用 ：

PUT /my_index/_settings { "index.requests.cache.enable": true }

過濾順序

在bool條件中過濾器的順序對性能有很大的影響。更詳細的過濾條件應該被放置在其他過濾器之前，以便在更早的排除更多的文檔。

假如條件 A比對1000萬個文檔，而B隻比對100個文檔，那麼需要将B放在A前面。

緩存的過濾器非常快，是以它們需要被放在不能緩存的過濾器之前。

聲明：本部落格根據《ES權威指南》内容總結整理而成，轉載出處：https://blog.csdn.net/qingmou_csdn

</div>
elasticsearch6.0
上一篇: JS學習第十二天總結
下一篇: ES性能調優權威指南（篇二）