掌握 analyze API,一舉搞定 Elasticsearch 分詞難題

初次接觸 Elasticsearch 的同學經常會遇到分詞相關的難題,比如如下這些場景:

  1. 為什么命名有包含搜索關鍵詞的文檔,但結果里面就沒有相關文檔呢?
  2. 我存進去的文檔到底被分成哪些詞(term)了?
  3. 我得自定義分詞規則,但感覺好麻煩呢,無從下手

如果你遇到過類似的問題,希望本文可以解決你的疑惑。

1. 上手

讓我們從一個實例出發,如下創建一個文檔:

PUT test/doc/1
{
  "msg":"Eating an apple a day keeps doctor away"
}

然后我們做一個查詢,我們試圖通過搜索 eat這個關鍵詞來搜索這個文檔

POST test/_search
{
  "query":{
    "match":{
      "msg":"eat"
    }
  }
}

ES的返回結果為0。這不太對啊,我們用最基本的字符串查找也應該能匹配到上面新建的文檔才對啊!

各位不要急,我們先來看看什么是分詞。

2. 分詞

搜索引擎的核心是倒排索引(這里不展開講),而倒排索引的基礎就是分詞。所謂分詞可以簡單理解為將一個完整的句子切割為一個個單詞的過程。在 es 中單詞對應英文為 term。我們簡單看個例子:

image

ES 的倒排索引即是根據分詞后的單詞創建,即 北京天安門這4個單詞。這也意味著你在搜索的時候也只能搜索這4個單詞才能命中該文檔。

實際上 ES 的分詞不僅僅發生在文檔創建的時候,也發生在搜索的時候,如下圖所示:

image

讀時分詞發生在用戶查詢時,ES 會即時地對用戶輸入的關鍵詞進行分詞,分詞結果只存在內存中,當查詢結束時,分詞結果也會隨即消失。而寫時分詞發生在文檔寫入時,ES 會對文檔進行分詞后,將結果存入倒排索引,該部分最終會以文件的形式存儲于磁盤上,不會因查詢結束或者 ES 重啟而丟失。

ES 中處理分詞的部分被稱作分詞器,英文是Analyzer,它決定了分詞的規則。ES 自帶了很多默認的分詞器,比如StandardKeywordWhitespace等等,默認是 Standard。當我們在讀時或者寫時分詞時可以指定要使用的分詞器。

3. 寫時分詞結果

回到上手階段,我們來看下寫入的文檔最終分詞結果是什么。通過如下 api 可以查看:

POST test/_analyze
{
  "field": "msg",
  "text": "Eating an apple a day keeps doctor away"
}

其中 test為索引名,_analyze 為查看分詞結果的 endpoint,請求體中 field 為要查看的字段名,text為具體值。該 api 的作用就是請告訴我在 test 索引使用 msg 字段存儲一段文本時,es 會如何分詞。

返回結果如下:

{
  "tokens": [
    {
      "token": "eating",
      "start_offset": 0,
      "end_offset": 6,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "an",
      "start_offset": 7,
      "end_offset": 9,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "apple",
      "start_offset": 10,
      "end_offset": 15,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "a",
      "start_offset": 16,
      "end_offset": 17,
      "type": "<ALPHANUM>",
      "position": 3
    },
    {
      "token": "day",
      "start_offset": 18,
      "end_offset": 21,
      "type": "<ALPHANUM>",
      "position": 4
    },
    {
      "token": "keeps",
      "start_offset": 22,
      "end_offset": 27,
      "type": "<ALPHANUM>",
      "position": 5
    },
    {
      "token": "doctor",
      "start_offset": 28,
      "end_offset": 34,
      "type": "<ALPHANUM>",
      "position": 6
    },
    {
      "token": "away",
      "start_offset": 35,
      "end_offset": 39,
      "type": "<ALPHANUM>",
      "position": 7
    }
  ]
}

返回結果中的每一個 token即為分詞后的每一個單詞,我們可以看到這里是沒有 eat 這個單詞的,這也解釋了在上手中我們搜索 eat 沒有結果的情況。如果你去搜索 eating ,會有結果返回。

寫時分詞器需要在 mapping 中指定,而且一經指定就不能再修改,若要修改必須新建索引。如下所示我們新建一個名為ms_english 的字段,指定其分詞器為 english

PUT test/_mapping/doc
{
  "properties": {
    "msg_english":{
      "type":"text",
      "analyzer": "english"
    }
  }
}

4. 讀時分詞結果

由于讀時分詞器默認與寫時分詞器默認保持一致,拿 上手 中的例子,你搜索 msg 字段,那么讀時分詞器為 Standard ,搜索 msg_english 時分詞器則為 english。這種默認設定也是非常容易理解的,讀寫采用一致的分詞器,才能盡最大可能保證分詞的結果是可以匹配的。

然后 ES 允許讀時分詞器單獨設置,如下所示:

POST test/_search
  {
    "query":{
      "match":{
        "msg":{
          "query": "eating",
          "analyzer": "english"
        }
      }
    }
  }

如上 analyzer 字段即可以自定義讀時分詞器,一般來講不需要特別指定讀時分詞器。

如果不單獨設置分詞器,那么讀時分詞器的驗證方法與寫時一致;如果是自定義分詞器,那么可以使用如下的 api 來自行驗證結果。

POST _analyze
  {
    "text":"eating",
    "analyzer":"english"
  }

返回結果如下:

{
  "tokens": [
    {
      "token": "eat",
      "start_offset": 0,
      "end_offset": 6,
      "type": "<ALPHANUM>",
      "position": 0
    }
  ]
}

由上可知 english分詞器會將 eating處理為 eat,大家可以再測試下默認的 standard分詞器,它沒有做任何處理。

5. 解釋問題

現在我們再來看下 上手 中所遇問題的解決思路。

  1. 查看文檔寫時分詞結果
  2. 查看查詢關鍵詞的讀時分詞結果
  3. 匹對兩者是否有命中

我們簡單分析如下:

image

由上圖可以定位問題的原因了。

6. 解決需求

由于 eating只是 eat的一個變形,我們依然希望輸入 eat時可以匹配包含 eating的文檔,那么該如何解決呢?

答案很簡單,既然原因是在分詞結果不匹配,那么我們就換一個分詞器唄~ 我們可以先試下 ES 自帶的 english分詞器,如下:

# 增加字段 msg_english,與 msg 做對比
PUT test/_mapping/doc
{
  "properties": {
    "msg_english":{
      "type":"text",
      "analyzer": "english"
    }
  }
}

# 寫入相同文檔
PUT test/doc/1
{
  "msg":"Eating an apple a day keeps doctor away",
  "msg_english":"Eating an apple a day keeps doctor away"
}

# 搜索 msg_english 字段
POST test/_search
{
  "query": {
    "match": {
      "msg_english": "eat"
    }
  }
}

執行上面的內容,我們會發現結果有內容了,原因也很簡單,如下圖所示:

image

由上圖可見 english分詞器會將 eating分詞為 eat,此時我們搜索 eat或者 eating肯定都可以匹配對應的文檔了。至此,需求解決。

7. 深入分析

最后我們來看下為什么english分詞器可以解決我們遇到的問題。一個分詞器由三部分組成:char filter、tokenizer 和 token filter。各部分的作用我們這里就不展開了,我們來看下 standardenglish分詞器的區別。

image

從上圖可以看出,english分詞器在 Token Filter 中和 Standard不同,而發揮主要作用的就是 stemmer,感興趣的同學可以自行去看起它的作用。

8. 自定義分詞

如果我們不使用 english分詞器,自定義一個分詞器來實現上述需求也是完全可行的,這里不詳細講解了,只給大家講一個快速驗證自定義分詞器效果的方法,如下:

POST _analyze
{
  "char_filter": [], 
  "tokenizer": "standard",
  "filter": [
    "stop",
    "lowercase",
    "stemmer"
  ],
  "text": "Eating an apple a day keeps doctor away"
}

通過上面的 api 你可以快速驗證自己要定制的分詞器,當達到自己需求后,再將這一部分配置加入索引的配置。

至此,我們再看開篇的三個問題,相信你已經心里有答案了,趕緊上手去自行測試下吧!

image
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • Solr&ElasticSearch原理及應用 一、綜述 搜索 http://baike.baidu.com/it...
    樓外樓V閱讀 7,331評論 1 17
  • 倒排索引 正排索引:文檔id到單詞的關聯關系 倒排索引:單詞到文檔id的關聯關系 示例:對以下三個文檔去除停用詞后...
    小旋鋒的簡書閱讀 4,639評論 1 11
  • 表面的你可能就是一根草,但不為人知的另一面,卻隱藏著巨大的寶藏。所以不要忘記生長,當你被發現的那一刻,驚喜與努力將...
    sunnyinkfish閱讀 121評論 0 0
  • 真相并沒有什么可怕的。 理解、接受并且知道應該如何處理現實問題是至關重要的。 為什么會害怕真相,恐懼事實? 因為事...
    lamanda閱讀 532評論 0 0
  • 生活就是一直摸索前進,慢慢的撥開云霧,發現自己想要的,從前我不知道目標是什么,突然的,就發現了自己是個什么樣的人,...
    LU小Y閱讀 177評論 0 0