文件地址：https://www.elastic.co/guide/cn/elasticsearch/guide/current/_finding_exact_values.html

當進行精確值查詢時， 我們會使用過濾器（filters）。過濾器很重要，因為它們執行速度非常快，不會計算相關度（直接跳過了整個評分階段）而且很容易被快取。我們會在本章後面的過濾器快取中討論過濾器的效能優勢，不過現在只要記住：請儘可能多的使用過濾式查詢。

term 查詢數字

我們首先來看最為常用的term查詢， 可以用它處理數字（numbers）、布林值（Booleans）、日期（dates）以及文字（text）。

讓我們以下面的例子開始介紹，建立並索引一些表示產品的文件，文件裡有欄位 `price` 和 `productID` （ `價格` 和 `產品ID` ）：

POST /my_store/products/_bulk
{ "index": { "_id": 1 }}
{ "price" : 10, "productID" : "XHDK-A-1293-#fJ3" }
{ "index": { "_id": 2 }}
{ "price" : 20, "productID" : "KDKE-B-9947-#kL5" }
{ "index": { "_id": 3 }}
{ "price" : 30, "productID" : "JODL-X-1937-#pV7" }
{ "index": { "_id": 4 }}
{ "price" : 30, "productID" : "QQPX-R-3956-#aD8" }
 

我們想要做的是查詢具有某個價格的所有產品，有關係資料庫背景的人肯定熟悉 SQL，如果我們將其用 SQL 形式表達，會是下面這樣：

SELECT document
FROM   products
WHERE  price = 20

在 Elasticsearch 的查詢表示式（query DSL）中，我們可以使用term查詢達到相同的目的。term查詢會查詢我們指定的精確值。作為其本身，term查詢是簡單的。它接受一個欄位名以及我們希望查詢的數值：

{
    "term" : {
        "price" : 20
    }
}

通常當查詢一個精確值的時候，我們不希望對查詢進行評分計算。只希望對文件進行包括或排除的計算，所以我們會使用constant_score

最終組合的結果是一個constant_score查詢，它包含一個term查詢：

GET /my_store/products/_search
{
    "query" : {
        "constant_score" : { 
            "filter" : {
                "term" : { 
                    "price" : 20
                }
            }
        }
    }
}

執行後，這個查詢所搜尋到的結果與我們期望的一致：只有文件 2 命中並作為結果返回（因為只有2的價格是20）:

"hits" : [
    {
        "_index" : "my_store",
        "_type" :  "products",
        "_id" :    "2",
        "_score" : 1.0, 
        "_source" : {
          "price" :     20,
          "productID" : "KDKE-B-9947-#kL5"
        }
    }
]

term 查詢文字

如本部分開始處提到過的一樣 ，使用term查詢匹配字串和匹配數字一樣容易。如果我們想要查詢某個具體 UPC ID 的產品，使用 SQL 表示式會是如下這樣：

SELECT product
FROM   products
WHERE  productID = "XHDK-A-1293-#fJ3"

轉換成查詢表示式（query DSL），同樣使用term查詢，形式如下：

GET /my_store/products/_search
{
    "query" : {
        "constant_score" : {
            "filter" : {
                "term" : {
                    "productID" : "XHDK-A-1293-#fJ3"
                }
            }
        }
    }
}

但這裡有個小問題：我們無法獲得期望的結果。為什麼呢？問題不在term查詢，而在於索引資料的方式。 如果我們使用analyzeAPI (分析 API)，我們可以看到這裡的 UPC 碼被拆分成多個更小的 token ：

GET /my_store/_analyze
{
  "field": "productID",
  "text": "XHDK-A-1293-#fJ3"
}

{
  "tokens" : [ {
    "token" :        "xhdk",
    "start_offset" : 0,
    "end_offset" :   4,
    "type" :         "<ALPHANUM>",
    "position" :     1
  }, {
    "token" :        "a",
    "start_offset" : 5,
    "end_offset" :   6,
    "type" :         "<ALPHANUM>",
    "position" :     2
  }, {
    "token" :        "1293",
    "start_offset" : 7,
    "end_offset" :   11,
    "type" :         "<NUM>",
    "position" :     3
  }, {
    "token" :        "fj3",
    "start_offset" : 13,
    "end_offset" :   16,
    "type" :         "<ALPHANUM>",
    "position" :     4
  } ]
}

這裡有幾點需要注意：

• Elasticsearch 用 4 個不同的 token 而不是單個 token 來表示這個 UPC 。
• 所有字母都是小寫的。
• 丟失了連字元和雜湊符（#）。

所以當我們用term查詢查詢精確值XHDK-A-1293-#fJ3的時候，找不到任何文件，因為它並不在我們的倒排索引中，正如前面呈現出的分析結果，索引裡有四個 token 。

顯然這種對 ID 碼或其他任何精確值的處理方式並不是我們想要的。

為了避免這種問題，我們需要告訴 Elasticsearch 該欄位具有精確值，要將其設定成not_analyzed無需分析的。 我們可以在自定義欄位對映中檢視它的用法。為了修正搜尋結果，我們需要首先刪除舊索引（因為它的對映不再正確）然後建立一個能正確對映的新索引：

DELETE /my_store 

PUT /my_store 
{
    "mappings" : {
        "products" : {
            "properties" : {
                "productID" : {
                    "type" : "string",
                    "index" : "not_analyzed" 
                }
            }
        }
    }

}

現在我們可以為文件重建索引：

POST /my_store/products/_bulk
{ "index": { "_id": 1 }}
{ "price" : 10, "productID" : "XHDK-A-1293-#fJ3" }
{ "index": { "_id": 2 }}
{ "price" : 20, "productID" : "KDKE-B-9947-#kL5" }
{ "index": { "_id": 3 }}
{ "price" : 30, "productID" : "JODL-X-1937-#pV7" }
{ "index": { "_id": 4 }}
{ "price" : 30, "productID" : "QQPX-R-3956-#aD8" }

此時，term查詢就能搜尋到我們想要的結果，讓我們再次搜尋新索引過的資料（注意，查詢和過濾並沒有發生任何改變，改變的是資料對映的方式）：

GET /my_store/products/_search
{
    "query" : {
        "constant_score" : {
            "filter" : {
                "term" : {
                    "productID" : "XHDK-A-1293-#fJ3"
                }
            }
        }
    }
}

因為productID欄位是未分析過的，term查詢不會對其做任何分析，查詢會進行精確查詢並返回文件 1 。成功！

內部過濾器的操作

在內部，Elasticsearch 會在執行非評分查詢的時執行多個操作：

1. 查詢匹配文件.

   term查詢在倒排索引中查詢XHDK-A-1293-#fJ3然後獲取包含該 term 的所有文件。本例中，只有文件 1 滿足我們要求。

2. 建立 bitset.

   過濾器會建立一個bitset（一個包含 0 和 1 的陣列），它描述了哪個文件會包含該 term 。匹配文件的標誌位是 1 。本例中，bitset 的值為[1,0,0,0]。在內部，它表示成一個"roaring bitmap"，可以同時對稀疏或密集的集合進行高效編碼。

3. 迭代 bitset(s)

   一旦為每個查詢生成了 bitsets ，Elasticsearch 就會迴圈迭代 bitsets 從而找到滿足所有過濾條件的匹配文件的集合。執行順序是啟發式的，但一般來說先迭代稀疏的 bitset （因為它可以排除掉大量的文件）。

4. 增量使用計數.

   Elasticsearch 能夠快取非評分查詢從而獲取更快的訪問，但是它也會不太聰明地快取一些使用極少的東西。非評分計算因為倒排索引已經足夠快了，所以我們只想快取那些我們知道在將來會被再次使用的查詢，以避免資源的浪費。

   為了實現以上設想，Elasticsearch 會為每個索引跟蹤保留查詢使用的歷史狀態。如果查詢在最近的 256 次查詢中會被用到，那麼它就會被快取到記憶體中。當 bitset 被快取後，快取會在那些低於 10,000 個文件（或少於 3% 的總索引數）的段（segment）中被忽略。這些小的段即將會消失，所以為它們分配快取是一種浪費。

實際情況並非如此（執行有它的複雜性，這取決於查詢計劃是如何重新規劃的，有些啟發式的演算法是基於查詢代價的），理論上非評分查詢先於評分查詢執行。非評分查詢任務旨在降低那些將對評分查詢計算帶來更高成本的文件數量，從而達到快速搜尋的目的。

從概念上記住非評分計算是首先執行的，這將有助於寫出高效又快速的搜尋請求。