solr 模糊匹配

搜索引擎都是關于查找字符串的。 用戶輸入一個查詢詞，然后從反向索引中檢索它。 有時，用戶正在尋找的值只是索引中值的子字符串，并且用戶可能也對這些匹配感興趣。 對于德語這樣的包含復合詞（如Semmelkn?del）的語言，這尤其重要，其中Kn?del表示餃子，而Semmel專門針對這種詞。

通配符

為了演示方法，我使用了非常簡單的模式。 文檔由一個文本字段和一個ID組成。 Github上也可以進行配置和單元測試。

<fields><field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" /><field name="text" type="text_general" indexed="true" stored="false"/> </fields> <uniqueKey>id</uniqueKey> <types><fieldType name="string" class="solr.StrField" sortMissingLast="true" /><fieldType name="text_general" class="solr.TextField" positionIncrementGap="100"><analyzer><tokenizer class="solr.StandardTokenizerFactory"/><filter class="solr.LowerCaseFilterFactory"/></analyzer></fieldType> </types>

在進行前綴或后綴匹配時非常流行的一種方法是在查詢時使用通配符。 這可以通過編程方式完成，但是您需要注意，然后正確轉義任何用戶輸入。 假設您在索引中包含術語餃子 ，并且用戶輸入了術語dump 。 如果要確保查詢詞與索引中的文檔匹配，您可以在應用程序代碼中向用戶查詢添加通配符，以便將生成的查詢轉儲為* 。

通常，在執行此類過多操作時應格外小心：如果用戶實際上正在尋找包含dump單詞的文檔，那么她可能對包含餃子的文檔不感興趣。 您需要自己決定是只希望對用戶感興趣的匹配項（精確）還是向用戶顯示盡可能多的可能匹配項（調用）。 這在很大程度上取決于您的應用程序的用例。

您可以通過提高與您的學期的完全匹配來增加用戶體驗。 您需要創建一個更復雜的查詢，但是這樣，包含完全匹配項的文檔將獲得更高的分數：

dump^2 OR dump*

在創建這樣的查詢時，您還應注意用戶不能添加會使查詢無效的字詞。 escapeQueryChars類的SolrJ方法escapeQueryChars可用于轉義用戶輸入。

如果現在考慮后綴匹配，則查詢可能會變得相當復雜，并且在客戶端創建這樣的查詢并不適合每個人。 根據您的應用程序，另一種方法可能是更好的解決方案：您可以在索引期間創建另一個包含NGram的字段。

前綴與NGrams匹配

NGrams是索引術語的子字符串，您可以將其放在其他字段中。 這些子字符串可用于查找，因此不需要任何通配符。 使用（e）dismax處理程序，您可以在字段上自動設置用于完全匹配的提升，從而獲得與上述相同的行為。

對于前綴匹配，我們可以使用為其他字段配置的EdgeNGramFilter ：

...<field name="text_prefix" type="text_prefix" indexed="true" stored="false"/> ...<copyField source="text" dest="text_prefix"/> ... <fieldType name="text_prefix" class="solr.TextField" positionIncrementGap="100"><analyzer type="index"><tokenizer class="solr.LowerCaseTokenizerFactory"/><filter class="solr.EdgeNGramFilterFactory" minGramSize="3" maxGramSize="15" side="front"/></analyzer><analyzer type="query"><tokenizer class="solr.LowerCaseTokenizerFactory"/></analyzer></fieldType>

在索引期間，文本字段值將復制到text_prefix字段，并使用EdgeNGramFilter進行分析。 從字符串的開頭開始，將為3到15之間的任何長度創建克。 當為術語餃子建立索引時，它將是：

• 啞巴
• 傾倒
• 垃圾堆
• 杜普利
• 杜普林
• 餃子

在查詢期間，該詞不會再次拆分，因此可以使用與子字符串完全匹配的詞。 與往常一樣，Solr管理員后端的分析視圖對于查看實際的分析過程可能會很有幫助。

現在，您可以使用dismax處理程序按原樣傳遞用戶查詢，并通過添加參數qf=text^2,text_prefix來建議它在您的字段中進行搜索。

后綴匹配

對于具有復合詞的語言，通常也需要進行后綴匹配。 如果用戶查詢術語Kn?del （水餃），則包含術語Semmelkn?del的文檔也應匹配。

使用Solr版本高達4.3，這沒問題。 您可以使用EdgeNGramFilterFactory從字符串的后面開始創建克。

...<field name="text_suffix" type="text_suffix" indexed="true" stored="false"/> ... <copyField source="text" dest="text_suffix"/> ...<fieldType name="text_suffix" class="solr.TextField" positionIncrementGap="100"><analyzer type="index"><tokenizer class="solr.StandardTokenizerFactory"/><filter class="solr.LowerCaseFilterFactory"/><filter class="solr.EdgeNGramFilterFactory" minGramSize="3" maxGramSize="15" side="back"/></analyzer><analyzer type="query"><tokenizer class="solr.KeywordTokenizerFactory"/><filter class="solr.LowerCaseFilterFactory"/></analyzer></fieldType> ...

這將創建索引詞的后綴，其中也包含詞kn?del，因此我們的查詢有效。

但是，使用較新版本的Solr時，在建立索引期間會遇到問題：

java.lang.IllegalArgumentException: Side.BACK is not supported anymore as of Lucene 4.4, use ReverseStringFilter up-front and afterwardat org.apache.lucene.analysis.ngram.EdgeNGramTokenFilter.(EdgeNGramTokenFilter.java:114)at org.apache.lucene.analysis.ngram.EdgeNGramTokenFilter.(EdgeNGramTokenFilter.java:149)at org.apache.lucene.analysis.ngram.EdgeNGramFilterFactory.create(EdgeNGramFilterFactory.java:52)at org.apache.lucene.analysis.ngram.EdgeNGramFilterFactory.create(EdgeNGramFilterFactory.java:34)

您不能再將EdgeNGramFilterFactory用作后綴ngram。 但是幸運的是，堆棧跟蹤還建議我們如何解決此問題。 我們必須將其與ReverseStringFilter結合使用：

<fieldType name="text_suffix" class="solr.TextField" positionIncrementGap="100"><analyzer type="index"><tokenizer class="solr.LowerCaseTokenizerFactory"/><filter class="solr.ReverseStringFilterFactory"/><filter class="solr.EdgeNGramFilterFactory" minGramSize="3" maxGramSize="15" side="front"/><filter class="solr.ReverseStringFilterFactory"/></analyzer><analyzer type="query"><tokenizer class="solr.LowerCaseTokenizerFactory"/></analyzer> </fieldType>

現在這將產生與以前相同的結果。

結論

是否要通過添加通配符來處理查詢，或者是否應該使用NGram方法，在很大程度上取決于您的用例，也取決于您的口味。 我個人大部分時間都在使用NGrams，因為磁盤空間通常與我正在從事的項目無關。 Lucene 4中的通配符搜索變得更快了，所以我懷疑那里是否還有真正的好處。 不過，我傾向于在索引期間進行盡可能多的處理。

翻譯自: https://www.javacodegeeks.com/2014/05/prefix-and-suffix-matches-in-solr.html

solr 模糊匹配

總結

以上是生活随笔為你收集整理的solr 模糊匹配_Solr中的前缀和后缀匹配的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。