第08篇-Elasticsearch中的分析和分析器應用方式

個人Elasticsearch系列文章，逐漸更新中，歡迎關注
0A.關於Elasticsearch及實例應用
00.Solr與ElasticSearch對比
01.ElasticSearch能作什麼？
02.Elastic Stack功能介紹
03.如何安裝與設置Elasticsearch API
04.若是經過elasticsearch的head插件創建索引_CRUD操做
05.Elasticsearch多個實例和head plugin使用介紹
06.當Elasticsearch進行文檔索引時，它是如何工做的?
07.Elasticsearch中的映射方式—簡潔版教程
08.Elasticsearch中的分析和分析器應用方式

另外ES入門，我強烈推薦這篇Elasticsearch權威搭建指南給你，很是想盡的指南手冊。

介紹
在本系列的第一個博客中，咱們看到了在Elasticsearch中對文檔創建索引時的反向索引計算，而在第二個博客中，咱們看到了Elasticsearch中的映射基礎。如今，在此博客中，咱們將詳細介紹Elasticsearch的分析部分，如何完成以及如何定製分析。
1.分析過程說明
爲了瞭解Elasticsearch中的分析過程及其需求，咱們須要對
inverted index

Elasticsearch中的建立進行更深刻的瞭解。咱們在階段02的博客01中討論的關於
inverted index

建立的內容是基本版本，在這裏讓我爲倒排索引建立場景添加一些複雜性。
當咱們將這些文檔索引到Elasticsearch時，流程以下：

如今讓我解釋反向索引建立以前的每一個階​​段：
1.1字符過濾器
字符過濾器具備對提供給他們的輸入文本執行添加，刪除或替換操做的能力。爲了更清楚地理解它，若是輸入字符串包含重複出現的拼寫錯誤的單詞，而咱們須要用正確的單詞替換它，那麼咱們可使用字符過濾器對此進行相同的處理。此過濾器最多見的應用之一是
html

從輸入文本中剝離標籤。
讓咱們看看使用Elasticsearch的Analyze API進行字符過濾的工做。在這裏，咱們將使用字符過濾器「 html_strip」從文本中刪除html標籤。捲曲請求以下：
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d '{
"tokenizer": "standard",
"char_filter": [

"html_strip"

],
"text": "The Auto-generation is a success"
}'
生成的令牌以下所示：

「The」,」Auto」,」generation」,」is」,」a」,」success」

在這裏咱們能夠看到令牌中沒有html標記。一樣，嘗試不帶的上述curl請求，
「char_filter」:[「html_strip」]

而後看看有什麼不一樣。
1.2分詞器
從「字符」過濾器轉換後的輸入文本將傳遞到令牌處理程序。令牌生成器會將輸入文本拆分爲特定字符處的單個令牌（或術語）。elasticsearch中的默認標記器是「標準標記器」，它使用基於語法的標記化技術，該技術不只能夠擴展到英語，還能夠擴展到許多其餘語言。
讓咱們在下面看到一個標準令牌生成器的示例：

curl -XPOST ‘localhost:9200/_analyze?pretty’ -H ‘Content-Type: application/json’ -d '{
「tokenizer」: 「standard」,
「text」: 「The Auto-generation is a success」
}'

在響應中，您能夠看到文本分爲如下標記：
「 The」，「 Auto」，「 Generation」，「 is」，「 a」，「 success」

在這裏，只要有空格和連字符（-），單詞就會被拆分。
注意：有不一樣類型的標記器，用於不一樣的目的。在某些用例中，咱們可能不須要拆分特殊字符（例如，在使用電子郵件ID或url的狀況下），所以爲了知足此類需求，咱們可使用「 UAX URL Email Tokenizer」等標記器。能夠在此處找到Elasticsearch提供的標記器列表

1.3 令牌過濾器
將輸入文本拆分爲標記/術語後，將其移至分析的最後階段，即標記過濾。令牌過濾器能夠做用於由令牌生成器生成的令牌，並能夠對其進行修改，添加或刪除。讓咱們嘗試以上示例的令牌過濾器。咱們將在這裏嘗試使用的令牌過濾器是小寫的令牌過濾器，它將全部進入其中的令牌都小寫。如下curl請求使用analyst API進行演示：
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d'{
"tokenizer": "standard",
"filter": [

"lowercase"

],
"text": "The Auto-generation is a success"
}'

響應中生成的令牌以下所示：
「 the」，「 auto」，「 generation」，「 is」，「 a」，「 success」

請注意，每一個標記如今都小寫了。這就是小寫令牌過濾器對令牌的做用。
有關Elasticsearch隨附的令牌過濾器的列表
在Elasticsearch中，令牌過濾器最多見的用例之一是向單詞添加同義詞。從本質上講，這意味着可使用此過濾器將單詞映射到其同義詞，而且每當咱們搜索同義詞時，都會出現包含基礎單詞的文檔。咱們將在之後的博客中看到此方法的應用。

2.分析儀
上一節介紹了Elasticsearch分析文檔中字段內容的過程。正如在上一節中提到的，有幾種類型的字符過濾器，令牌化器和令牌過濾器可用，咱們應該根據遇到的用例明智地選擇它們。這三個組件（字符過濾器，令牌生成器和令牌過濾器）的組合稱爲分析器。Elasticsearch提供了幾種類型的內置分析器，用於處理最多見的用例。例如，Elasticsearch的默認分析器標準分析器是標準令牌生成器和兩個令牌過濾器（標準令牌過濾器，小寫和中止令牌過濾器）的組合。一樣，根據字符過濾器的組合，可使用多種分析儀，
分析儀的整體結構以下所示：

咱們還能夠經過選擇所需的過濾器和標記器來製做自定義分析器。咱們將在本系列的下一個博客中看到定製分析器的製做。
3.分析階段
如今咱們對什麼是分析以及什麼是分析器有了清晰的瞭解，讓咱們進入在Elasticsearch中發生的分析的兩個階段，即索引時間分析和搜索時間分析。
3.1索引時間分析
讓咱們考慮如下文檔進行索引

curl -XPOST localhost:9200/testindex-0203/testtype/1 -d '{
"text": "My name is Arun"
}'

因爲咱們沒有使用分析器，所以Elasticsearch對此應用了默認的分析器「標準分析器」。讓咱們在分析API的幫助下，查看上述文檔與Standard Analyser一塊兒使用時的最終標記
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d'{
"analyzer": "standard",
"text": "My name is Arun"
}'
用於存儲在倒排索引中的令牌是：
「個人」，「姓名」，「是」，「阿倫」
倒排的索引以下表所示：

這整個過程發生在索引時間中，所以發生在名稱索引時間分析中。
3.2搜索時間分析
顧名思義，搜索時間分析將在搜索時發生。可是有一個區別，就是這種分析是在查詢上進行的，具體取決於所使用的查詢。
3.2.1術語查詢-狀況1
考慮如下查詢：
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「term」: {
  「text」: 「name」
}

}
}'
若是咱們對索引「 testindex-0203」運行此查詢，它將返回被索引的文檔做爲結果。標記「名稱」存在於反向索引中，並再次映射到文檔1。所以，當咱們搜索術語「名稱」時，它將查找反向索引，而且因爲找到了該術語，所以相應的文檔被提取爲結果。
3.2.2術語查詢-案例2
如今考慮具備相同「條件」查詢的另外一種狀況，以下所示：
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「term」: {
  「text」: 「Name」
}

}
}'
在這裏，咱們使用相同的術語查詢來進行查詢，可是對於搜索關鍵字使用不一樣的大小寫，其如今是「名稱」而不是「名稱」。如今發生了一些有趣的事情，此搜索不會給咱們找到任何文件。這種奇怪行爲的緣由是，倒排索引中不存在「名稱」，所以沒有要顯示的文檔。
所以，對於「術語」查詢，不容許對搜索關鍵字進行任何分析。
3.2.3術語查詢-狀況3
讓咱們考慮術語查詢的另外一種狀況以查看此行爲，這是查詢
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「term」: {
  「text」: 「My name」
}

}
}'
在上述狀況下，沒有分析搜索關鍵字，所以，Elasticsearch在反向索引中尋找令牌「個人名字」。而且因爲此類術語不存在，所以針對上述查詢，elasticsearch也將返回零結果。
在Elasticsearch中就是「條件」查詢的狀況。讓咱們嘗試一個不一樣的查詢，稱爲match query並檢查輸出。
3.2.4匹配查詢-狀況1
考慮如下查詢：
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「term」: {
  「text」: 「My name」
}

}
}'
這將返回帶有索引文檔的響應，由於反向索引中存在「名稱」令牌。
3.2.5匹配查詢-狀況2
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「match」: {
  「text」: 「Name」
}

}
}'
在這裏，當咱們對案例2使用「條件」查詢時，沒有任何響應。可是，對於匹配查詢，不管在索引編制時將什麼分析應用於要查詢的字段（文本），都將對搜索關鍵字（「名稱」）進行徹底相同的分析。這使搜索關鍵字經歷「標準分析」，而且搜索關鍵字「名稱」更改成「名稱」（因爲標準分析器中的小寫標記過濾器）。這個新的搜索關鍵字「名稱」存在於反向索引中，而且響應也將具備相應的文檔。
3.2.6匹配查詢-狀況3
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{
「query」: {

「match」: {
  「text」: 「My name」
}

}}'這裏給出的搜索關鍵字是「My name」，通過標準分析後，它將轉換爲關鍵字「個人名字」和「名字」。這兩個關鍵字都存在於反向索引中，所以將文檔做爲響應返回。所以，根據查詢類型，搜索關鍵字將在搜索時間內進行分析（與查詢的字段相同）。這稱爲搜索時間分析。結論在此博客中，我介紹了分析器的基本組成部分以及Elasticsearch中發生的分析類型。在下一個博客中，咱們將看到如何針對很是特定的用例構建本身的自定義分析器。