本文主要介紹 ElasticSearch 搜索相關的知識，首先會介紹下 URI Search 和 Request Body Search，同時也會學習什麼是搜索的相關性，如何衡量相關性。 Search API 我們可以把 ES 的 Search API 分為兩大類，第一類是 URI Search ， ...

本文主要介紹 ElasticSearch 搜索相關的知識，首先會介紹下 URI Search 和 Request Body Search，同時也會學習什麼是搜索的相關性，如何衡量相關性。

Search API

我們可以把 ES 的 Search API 分為兩大類，第一類是 URI Search，用 HTTP GET 的方式在 URL 中使用查詢參數已達到查詢的目的；另一類為 Request Body Search，可以使用 ES 提供的基於 JSON 格式的格式更加完備的查詢語言 Query DSL（Domain Specific Language）

語法	範圍
/_search	集群上所有的索引
/jvm/_search	jvm
/jvm,sql/_search	jvm 和 sql
/jvm*/_search	以 jvm 開頭的索引

在查詢的時候需要通過 _search 來標明這個請求為搜索請求，同時可以指定 index，也可以指定多個 index，也可以使用通配符的方式對 index 進行搜索。

下麵來看下 URI Search：

URI Search

GET /users/_search?q=username:wupx

URI Search 使用的是 GET 方式，其中 q 指定查詢語句，語法為 Query String Syntax，是 KV 鍵值對的形式；上面的請求表示對 username 欄位進行查詢，查詢包含 wupx 的所有文檔。

URI Search 有很多參數可以指定，除了 q 還有如下參數：

df：預設欄位，不指定時會對所有欄位進行查詢
sort：根據欄位名排序
from：返回的索引匹配結果的開始值，預設為 0
size：搜索結果返回的條數，預設為 10
timeout：超時的時間設置
fields：只返回索引中指定的列，多個列中間用逗號分開
analyzer：當分析查詢字元串的時候使用的分詞器
analyze_wildcard：通配符或者首碼查詢是否被分析，預設為 false
explain：在每個返回結果中，將包含評分機制的解釋
_source：是否包含元數據，同時支持 _source_includes 和 _source_excludes
lenient：若設置為 true，欄位類型轉換失敗的時候將被忽略，預設為 false
default_operator：預設多個條件的關係，AND 或者 OR，預設為 OR
search_type：搜索的類型，可以為 dfs_query_then_fetch 或 query_then_fetch，預設為 query_then_fetch

在瞭解了基本的查詢參數後，讓我們先來看下什麼是指定欄位查詢和什麼是泛查詢？

比如 GET /movies/_search?q=2012&df=title 這個例子就是指定欄位查詢，同樣 GET /movies/_search?q=title:2012 也可以達到指定欄位查詢的目的。

再舉一個泛查詢的例子 GET /movies/_search?q=2012，會對所有欄位進行查詢。

接下來，看下什麼是 Term Query 和 Phrase Query：

比如：Beautiful Mind 等效於 Beautiful OR Mind；"Beautiful Mind"等效於 Beautiful AND Mind，另外還要求前後順序保存一致。

當為 Term Query 的時候，就需要把這兩個詞用括弧括起來，請求為 GET /movies/_search?q=title:(Beautiful Mind)，意思就是查詢 title 中包括 Beautiful 或者 Mind。

當為 Phrase Query 的時候就需要用引號包起來，請求為 GET /movies/_search?q=title:"Beautiful Mind"。

另外還支持布爾操作，比如 AND（&&）、OR（||）、NOT（！），需要註意大寫，不能小寫。

在這裡舉一個 NOT 的例子：GET /movies/_search?q=title:(Beautiful NOT Mind)，這個請求表示查詢 title 中必須包括 Beautiful 不能包括 Mind 的文檔。

URI Search 還包括一些範圍查詢和數學運算符號，比如指定電影的年份大於 1994：GET /movies/_search?q=year:>=1994。

URI Search 還支持通配符查詢（查詢效率低，占用記憶體大，不建議使用，特別是放在最前面），還支持正則表達式，以及模糊匹配和近似查詢。

URI Search 好處就是操作簡單，只要寫個 URI 就可以了，方便測試，但是 URI Search 只包含一部分查詢語法，不能覆蓋所有 ES 支持的查詢語法。

因此讓我們來看下 Request Body Search：

Request Body Search

在 ES 中一些高階用法只能在 Request Body 里做，所以我們儘量使用 Request Body Search，它支持 GET 和 POST 方式對索引進行查詢，需要指定操作的索引名稱，同樣也要通過 _search 來標明這個請求為搜索請求，我們可以在請求體中使用 ES 提供的 DSL，下麵這個例子就是簡單的 Query DSL：

POST /users/_search
{
    "query": {
        "match_all": {}
    }
}

上面的請求的意思就是把所以的結果都返回。

也可以在 Request Body 中加入 from 和 size 參數以達到分頁的效果：

POST /movies/_search
{
  "from":10,
  "size":20,
  "query":{
    "match_all": {}
  }
}

預設 from 從 0 開始，返回 10 個結果，獲取靠後的翻頁成本較高。

如果想對搜索的結果排序也可以在請求體中加上 sort 參數：

POST /movies/_search
{
  "sort":[{"year":"desc"}],
  "query":{
    "match_all": {}
  }
}

最好在“數字型”與“日期型”欄位上排序，因為對於多值類型或者分析過的欄位排序，系統會選一個值，無法得知該值。

如果 _source 的數據量比較大，有些欄位也不需要拿到這個信息，那麼就可以對它的 _source 進行過濾，把需要的信息加到 _source 中，比如以下請求就是 _source 中只返回 title：

POST /movies/_search
{
  "_source":["title"],
  "query":{
    "match_all": {}
  }
}

如果 _source 沒有存儲，那就只返回匹配的文檔的元數據，同時 _source 也支持使用通配符。

接下來介紹下腳本欄位，腳本欄位可以使用 ES 中的 painless 的腳本去算出一個新的欄位結果。

GET /movies/_search
{
  "script_fields": {
    "new_field": {
      "script": {
        "lang": "painless",
        "source": "doc['year'].value+'_hello'"
      }
    }
  },
  "query": {
    "match_all": {}
  }
}

這個例子中就使用 painless 把電影的年份和 _hello 進行拼接形成一個新的欄位 new_field。

在上面我們剛介紹了在 URI Search 中的 Term Query 和 Phrase Query，接下來讓我們看下 Request Body 中是怎麼做的吧！

在此之前先來插播一條小知識-欄位類查詢，欄位類查詢主要包括以下兩類：

全文匹配：針對 text 類型的欄位進行全文檢索，會對查詢語句先進行分詞處理，如 match，match_phrase 等 query 類型
單詞匹配：不會對查詢語句做分詞處理，直接去匹配欄位的倒排索引，如 term，terms，range 等 query 類型

好了，現在我們來接著往下看。

可以在 Request Body 中使用在 query match 的方式把信息填在裡面，我們先來看下 Match Query，比如下麵這個例子，填入兩個單詞，預設是 wupx or huxy 的查詢條件，如果想查詢兩者同時出現，可以通過加 "operator": "and" 來實現。

POST /users/_search
{
  "query": {
    "match": {
      "title": "wupx huxy"
      "operator": "and"
    }
  }
}

我們通過一張圖來看下 Match Query 的流程：

首先對查詢語句進行分詞，分成 wupx 和 huxy 兩個 Term，然後 ES 會拿到 username 的倒排索引，對 wupx 和 huxy 去進行匹配的算分，比如 wupx 對應的文檔是 1 和 2，huxy 對應的文檔為 1，然後 ES 會利用算分演算法（比如 TF/IDF 和 BM25，BM25 模型 5.x 之後的預設模型）列出文檔跟查詢的匹配得分，然後 ES 會對 wupx huxy 的文檔的得分結果做一個彙總，最終根據得分排序，返回匹配文檔。

Request Body 中還支持 Match Phrase 查詢，但在 query 條件中的詞必須順序出現的，可以通過 slop 參數控制單詞間的間隔，比如加上 "slop" :1，表示中間可以有一個其他的字元。

POST /movies/_search
{
  "query": {
    "match_phrase": {
      "title":{
        "query": "one love"
        "slop":1
      }
    }
  }
}

瞭解完 Match Query，讓我們再來看下 Term Query：

如果不希望 ES 對輸入語句作分詞處理的話，可以用 Term Query，將查詢語句作為整個單詞進行查詢，使用方法和 Match 類似，只需要把 match 換為 term 就可以了，如下所示：

POST /users/_search
{
  "query": {
    "term": {
        "username":"wupx"
    }
  }
}

Terms Query 顧名思義就是一次可以傳入多個單詞進行查詢，關鍵詞是 terms，如下所示：

POST /users/_search
{
  "query": {
    "terms": {
      "username": [
        "wupx",
        "huxy"
      ]
    }
  }
}

另外 DSL 還支持特定的 Query String 的查詢，比如指定預設查詢的欄位名 default_field 就和前面介紹的 df 是一樣的，在 query 中也可以使用 AND 來實現一個與的操作。

POST users/_search
{
  "query": {
    "query_string": {
      "default_field": "username",
      "query": "wupx AND huxy"
    }
  }
}

下麵來看下 Simple Query String Query，它其實和 Query String 類似，但是會忽略錯誤的查詢語法，同時只支持部分查詢語法，不支持 AND OR NOT，會當作字元串處理，Term 之間預設的關係是 OR，可以指定 default_operator 來實現 AND 或者 OR，支持用 + 替代 AND，用 | 替代 OR，用 - 替代 NOT。

下麵這個例子就是查詢 username 欄位中同時包含 wu 和px 的請求：

{
  "query": {
    "simple_query_string": {
      "query": "wu px",
      "fields": ["username"],
      "default_operator": "AND"
    }
  }
}

到此為止，我們就對 DSL 做了個簡單介紹，更高階的 DSL 會在以後的文章中進行介紹。

然後，我們來看下請求後返回的結果 Response 長什麼樣吧！

Response

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 0.9808292,
    "hits" : [
      {
        "_index" : "users",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 0.9808292,
        "_source" : {
          "username" : "wupx",
          "age" : "18"
        }
      }
    ]
  }
}

其中 took 表示花費的時間；total 表示符合條件的總文檔數；hits 為結果集，預設是前 10 個文檔；_index 為索引名；_id 為文檔 id；_score 為相關性評分；_source 為文檔的原始信息。

搜索的相關性（Relevance）

那麼我們平時在搜索的時候，比如輸入小米手機，會返回很多結果，從用戶角度關心的有：是否找到所有相關的內容，有多少不相關的內容被返回了，比如輸入的小米手機的時候不應該返回糧食的小米給用戶，同時文檔應該按照打分的方式進行排序，也就是搜索結果中的 _score，另外，搜索引擎需要結合業務需求，平衡結果排名。

如何評估相關性？

在信息檢索學中對相關性是有指標去評估的，第一個是查準率（Precision），具體含義是儘可能返回較少的無關文檔給用戶；第二個為查全率（Recall），也就是儘量返回較多的相關文檔；第三個為是否能夠按照相關度進行排序（Ranking）。

下麵通過一張圖來對查準率和查全率有一個更形象的理解：

其中黃色的三角形代表不相關的內容，綠色的圓代表相關的內容；在搜索結果中，黃色的三角形起名為 False Positive（納偽，簡寫 fp），通常稱作誤報，綠色的圓起名為 True Positive（納真，簡寫 tp）；在沒有被搜索到的範圍中，綠色的圓的起名為 False Negatives（去真，簡寫 fn），也常稱作漏報，黃色的三角形起名為 True Negative（去偽，簡寫 tn）。

那麼我們可以得到：

查準率等於正確的搜索結果除以全部返回的結果，即 Precision = tp / ( tp + fp )
查全率等於正確的搜索結果除以所有應該返回的結果，即 Recall = tp / ( tp + fn )

在 ES 中提供了許多的查詢相關參數來改善搜索的 Precision 和 Recall。

總結

本文主要簡單介紹了 ES Search API 的兩種形式，學習了 URI Search 的基本方法，還學習了 Term Search 和 Phrase Search 的區別，同時介紹了什麼叫搜索相關性，以及如何評估相關性。

參考文獻

《Elasticsearch技術解析與實戰》

Elastic Stack從入門到實踐

Elasticsearch頂尖高手系列

Elasticsearch核心技術與實戰

https://www.elastic.co/guide/en/elasticsearch/reference/7.1/search.html

看完這篇還不會 Elasticsearch 搜索,那我就哭了！