Elasticsearch-精確查找_ZenDei技術網路在線

轉譯：（https://www.elastic.co/guide/en/elasticsearch/guide/current/_finding_exact_values.html#_finding_exact_values）當進行精確值查找時，我們會使用過濾器（filters）。過濾器很重要， ...

轉譯：（https://www.elastic.co/guide/en/elasticsearch/guide/current/_finding_exact_values.html#_finding_exact_values）

當進行精確值查找時，我們會使用過濾器（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
                }
            }
        }
    }
}

	我們用 `constant_score` 將 `term` 查詢轉化成為過濾器
	我們之前看到過的 `term` 查詢

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

"hits" : [
    {
        "_index" : "my_store",
        "_type" :  "products",
        "_id" :    "2",
        "_score" : 1.0,

        "_source" : {
          "price" :     20,
          "productID" : "KDKE-B-9947-#kL5"
        }
    }
]

查詢置於 filter 語句內不進行評分或相關度的計算，所以所有的結果都會返回一個預設評分 1 。

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"

執行順序說明：

	刪除索引是必須的，因為我們不能更新已存在的映射。
	在索引被刪除後，我們可以創建新的索引併為其指定自定義映射。
	這裡我們告訴 Elasticsearch ，我們不想對 `productID` 做任何分析。

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

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 會在運行非評分查詢的時執行多個操作：

查找匹配文檔.

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

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

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

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

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