關(guān)于elasticsearch的match_phrase_prefix查詢詳解
match_phrase
match_phrase_prefix可以認為是match_phrase的增強版本,所以先了解一下match_phrase。
match_phrase詞組匹配會先解析檢索詞,并且標(biāo)注出每個的token相對位置,搜索匹配的字段的必須包含所有的檢索詞的token,并且他們的相對位置也要和檢索詞里面相同。
在《系統(tǒng)學(xué)習(xí)ElasticSearch》中,有很好的例子:
# DSL語句
GET /tehero_index/_doc/_search
{
"query":{
"match_phrase":{
"content.ik_smart_analyzer":"系統(tǒng)編程"
}
}
DSL執(zhí)行步驟分析:
1)檢索詞“系統(tǒng)編程”被分詞為兩個Token【系統(tǒng),Position=0】【編程,Position=1】;
2)倒排索引檢索時,等價于sql:【where Token = 系統(tǒng) and 系統(tǒng)_Position=0 and Token = 編程 and 編程_Position=1】;
如果我們不要求這兩個單詞相鄰,希望放松一點條件,可以添加slop參數(shù),slop代表兩個token之間相隔的最多的距離(最多需要移動多少次才能相鄰)。
match_phrase_prefix
與match_phrase查詢類似,但是會對最后一個Token在倒排序索引列表中進行通配符搜索。
# DSL語句
GET /tehero_index/_doc/_search
{
"query":{
"match_phrase":{
"content.ik_smart_analyzer":"我編程系"
}
}
這個分詞的結(jié)果會是“我”、“編程”、“系”。
“我”和“編程”是精確匹配,“系”是前綴匹配,等價于sql:【where Token = ‘我’ and 我_Position=0 and Token = ‘編程’ and 編程_Position=1 and (Token_Position=2 and Token like ‘系%’)】
需要注意的點
elasticsearch的官網(wǎng)文檔上,有match_phrase_prefix的完整參數(shù)結(jié)構(gòu):

query,查詢的關(guān)鍵字analyer,對關(guān)鍵字使用的分詞器max_expansions,最后一個term做前綴匹配時的最大拓展數(shù),默認是50slop,與match_phrase的slop相同,允許term之間的最大間隔zero_terms_query,經(jīng)過analyer解析后,沒有任何term時,不返回數(shù)據(jù),還是返回全部數(shù)據(jù)。默認返回全部數(shù)據(jù)。
max_expansions是非常重要的一個參數(shù),需要留意下,不然很容易出現(xiàn)與我們期望不符合的情況。
- 在工作中,我試過使用match_phrase_prefix來匹配手機號,但是出現(xiàn)了一些奇怪的現(xiàn)象:
- 測試的手機號是“123454688885555”,使用match_phrase_prefix,關(guān)鍵字是“12345”來查詢指定租戶下的數(shù)據(jù),沒有返回任何文檔。把關(guān)鍵字換成“1234546”,正確返回了對應(yīng)的文檔。
為什么會這樣呢?為什么12345就不返回,1234546就返回了?
個人是這樣覺得的:
- 手機號雖然存在es中是字符串,但是字符串的內(nèi)容是數(shù)字,分詞器并不會對它進行分詞,也就是一個手機號就是一個term
- 在測試數(shù)據(jù)中,數(shù)據(jù)有5000條,每條數(shù)據(jù)的手機號碼都是不一樣的,也就是說,手機號這樣的term有5000個。
- max_expansions默認是50,也就是說,會把12345拓展出以12345為開頭的額外50個term,例如123456、1234546、123456898…
- 最后將拓展出來的term也用于查詢
為什么我會認為是這樣的過程呢?
elasticsearch除了會構(gòu)建倒排索引之外,還會在所有的term構(gòu)建一個term dictionary (詞典)和term index(詞索引,印象是跳躍表結(jié)構(gòu)),幫助查找。
當(dāng)出現(xiàn)前綴匹配的時候,可以在term index和term dictionary中快速找到對應(yīng)開通的term。
根據(jù)max_expansions的值,拿到指定個數(shù)的term。
12345查不到數(shù)據(jù),1234546能查找,明顯是1234546更精確,1234546拓展出來的term中包含了那個完整的手機號碼123454688885555。
在查詢這個參數(shù)相關(guān)的文章的時候,發(fā)現(xiàn):
- 有的人認為這個數(shù)值是值通配符,值是50,就能模糊匹配多關(guān)鍵字之后50的字符的term。有的人認為這個數(shù)值是匹配的文檔數(shù),值是50,則匹配50個文檔,返回這50個文檔中命中的部分。
- 這都是不對的,明顯與手機號的實驗不符。
- 《系統(tǒng)學(xué)習(xí)ElasticSearch》中對max_expansions的描述就像是占位符…
總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
Java字符串拼接的五種方法及性能比較分析(從執(zhí)行100次到90萬次)
字符串拼接一般使用“+”,但是“+”不能滿足大批量數(shù)據(jù)的處理,Java中有以下五種方法處理字符串拼接及性能比較分析,感興趣的可以了解一下2021-12-12
解決Idea報錯There is not enough memory
在使用Idea開發(fā)過程中,可能會遇到因內(nèi)存不足導(dǎo)致的閃退問題,出現(xiàn)"There is not enough memory to perform the requested operation"錯誤時,可以通過調(diào)整Idea的虛擬機選項來解決,方法是在Idea的Help菜單中選擇Edit Custom VM Options2024-11-11
SpringMVC使用@Valid注解進行數(shù)據(jù)驗證的方法
本篇文章主要介紹了SpringMVC使用@Valid注解進行數(shù)據(jù)驗證的方法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-02-02
記錄jdk21連接SQLServer因為TLS協(xié)議報錯問題
在使用Druid連接池連接SQL Server時,可能會遇到因TLS版本不匹配導(dǎo)致的連接失敗問題,具體表現(xiàn)為客戶端使用TLS1.3或TLS1.2,而SQL Server僅支持TLS1.0,導(dǎo)致無法建立安全連接,解決方法是修改JDK的安全配置,啟用TLS1.02024-10-10
spring-Kafka中的@KafkaListener深入源碼解讀
本文主要通過深入了解源碼,梳理從spring啟動到真正監(jiān)聽kafka消息的這套流程,從spring啟動開始處理@KafkaListener,本文結(jié)合實例流程圖給大家講解的非常詳細,需要的朋友參考下2023-02-02
深入理解Spring注解@Async解決異步調(diào)用問題
這篇文章主要介紹了深入理解Spring注解@Async解決異步調(diào)用問題,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-07-07

