結構化搜尋

結構化搜尋（Structured search） 是指有關探詢那些具有內在結構資料的過程。比如日期、時間和數字都是結構化的：它們有精確的格式，我們可以對這些格式進行邏輯操作。比較常見的操作包括比較數字或時間的範圍，或判定兩個值的大小。

文字也可以是結構化的。如彩色筆可以有離散的顏色集合： 紅（red） 、 綠（green） 、 藍（blue） 。一個部落格可能被標記了關鍵詞 分散式（distributed） 和 搜尋（search） 。電商網站上的商品都有 UPCs（通用產品碼 Universal Product Codes）或其他的唯一標識，它們都需要遵從嚴格規定的、結構化的格式。

在結構化查詢中，我們得到的結果 總是 非是即否，要麼存於集合之中，要麼存在集合之外。結構化查詢不關心檔案的相關度或評分；它簡單的對文件包括或排除處理。

這在邏輯上是能說通的，因為一個數字不能比其他數字 更 適合存於某個相同範圍。結果只能是：存於範圍之中，抑或反之。同樣，對於結構化文字來說，一個值要麼相等，要麼不等。沒有 更似 這種概念。

精確值查詢

當進行精確值查詢時， 我們會使用過濾器（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 查詢以非評分模式來執行 term 查詢並以一作為統一評分。

最終組合的結果是一個 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 查詢，而在於索引資料的方式。如果我們使用 analyze API (分析 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）中被忽略。這些小的段即將會消失，所以為它們分配快取是一種浪費。

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

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