6、ElasticSearch-精確查找

轉譯：（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 查詢，形式如下：

 

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

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

 

但這里有個小問題：我們無法獲得期望的結果。為什么呢？問題不在 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 會在運行非評分查詢的時執行多個操作：

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）中被忽略。這些小的段即將會消失，所以為它們分配緩存是一種浪費。

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

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

 

原文轉自：https://www.cnblogs.com/wenBlog/p/8510152.html