使用場景

我現在有兩個欄位參與索引，檔案名稱和檔案索引，

搜索的時候，一個關鍵字匹配查詢兩個欄位，

思路分析

眾所周知，匹配查詢先分詞再查詢，

單欄位查詢比較簡單，下邊有兩個例子，一個單欄位，一個多欄位布爾匹配查詢，

假如單欄位查詢關鍵字為“萬里長城真偉大”，

注意：

在這個測驗程序中，我沒有使用Kibana進行測驗，我是直接使用java代碼測驗的，結果是一樣的，

為什么不使用Kibana呢？原因如下：

Kibana語法，每次寫的時候，我都是打開Kibana檔案，直接復制粘貼，改改就用，不是我吹，應該沒幾個人能背的下來吧，而且Kibana的格式要求很嚴格，純手寫能寫出來的都是秀兒，所以我不想再看檔案了，反正手頭上有代碼，直接寫完事兒，

查詢第一步：分詞

{
  "tokens": [
    {
      "token": "萬里長城",
      "start_offset": 0,
      "end_offset": 4,
      "type": "CN_WORD",
      "position": 0
    },
    {
      "token": "萬里",
      "start_offset": 0,
      "end_offset": 2,
      "type": "CN_WORD",
      "position": 1
    },
    {
      "token": "萬",
      "start_offset": 0,
      "end_offset": 1,
      "type": "TYPE_CNUM",
      "position": 2
    },
    {
      "token": "里長",
      "start_offset": 1,
      "end_offset": 3,
      "type": "CN_WORD",
      "position": 3
    },
    {
      "token": "里",
      "start_offset": 1,
      "end_offset": 2,
      "type": "COUNT",
      "position": 4
    },
    {
      "token": "長城",
      "start_offset": 2,
      "end_offset": 4,
      "type": "CN_WORD",
      "position": 5
    },
    {
      "token": "真",
      "start_offset": 4,
      "end_offset": 5,
      "type": "CN_CHAR",
      "position": 6
    },
    {
      "token": "偉大",
      "start_offset": 5,
      "end_offset": 7,
      "type": "CN_WORD",
      "position": 7
    }
  ]
}

查詢第二步：匹配

匹配查詢中要用到兩個引數，

operator：默認為or，

minimumShouldMatch：默認為1，

重點API：operator

在上邊萬里長城真偉大這個查詢中，如果operator為or，為and會有什么不同的區別呢，

為or時：

索引庫中，只要檔案的content這個欄位內容包含“萬里長城”，“里”，“真”，“偉大”等任何一個分詞，該條檔案就會被索引到，

為and時：

索引庫中，檔案的content這個欄位必須包含“萬里長城”，“里”，“真”，“偉大”等所有分詞，這就是and，

看下邊的測驗，多欄位匹配兼布爾should查詢，很明顯and時候，更加準確，

在這里插入圖片描述

重點API：minimumShouldMatch

在上邊萬里長城真偉大這個查詢中，如果minimumShouldMatch為0，為1，為10會有什么不同的區別呢，

明確兩點：

第一：

只有operator為or時，minimumShouldMatch才有效，

畢竟operator為and時，要求全部都匹配上，都要滿足，minimumShouldMatch這邊你又設定了只要滿足兩個詞條就可以回傳，兩個條件沖突了，

第二：

minimumShouldMatch這個api的主要目的是為了避免搜索不精確，比如萬里長城真偉大，

如果索引庫中一個檔案的內容中，包含“真”字就回傳了，這就不科學了，

為0時：

是不是猜測，為0的時候，一個都不用匹配到，就可以回傳，

然而結果是殘酷的，我設定了為0，并不是全部回傳，還是要有一個匹配的詞條才會回傳，

? ES對這個api還是有所限制的，畢竟如果回傳全部內容的話，ES檢索沒有意義，

為1時：

正常默認情況下，就是為1，

為10時：

你的關鍵字能分為10個詞條嗎，欄位里的內容如果分詞后能有10個詞條，可以回傳，

設定為10的時候，很多東西會搜索不出來，回傳結果數量為0，

關于這個測驗，我將測驗結果，截圖放在這里，

最左側是搜索關鍵字，僅僅搜索檔案內容這一個欄位，設定不同minimumShouldMatch的大小，看不同的結果，

在這里插入圖片描述
觀察發現：

1、為1和為0都一樣，ES對這個API有處理，

2、為10時，我發現很多關鍵字都搜索不出來結果，所以我縮小為4，縮小為2，結果慢慢就出來了，慎用，

3、我發現金融兩個字，都是125條資料，很納悶，一開始我以為因為是法規庫，所以欄位內容金融兩字確實比較多，所以顯示出來，然后我又試了將大小調整為100,1000，還是125條資料，我就悟了，

我對金融進行分詞，看看金融的分詞結果，金融不參與分詞，分詞詞條數量這個API對它無效，

在這里插入圖片描述
··········································································
一家之言，當不得真，有錯誤的地方，感謝指出，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/229426.html

標籤：其他

上一篇：軟體工程師的自白：真希望自己從沒學過編碼

下一篇：輝太郎看前端(手寫深拷貝遞回)