閱讀(8.6k) 書簽贊(0) 我要糾錯

Solr：suggest組件使用大全

2018-11-28 17:31 更新

Suggester

Solr 中的 SuggestComponent 為用戶提供查詢 term 的自動建議。

您可以使用此功能在搜索應(yīng)用程序中實現(xiàn)強大的自動建議功能。

盡管可以使用拼寫檢查功能為自動建議行為提供支持，但 Solr 為此功能專門設(shè)計了一個 SuggestComponent。

這種方法利用了 Lucene 的 Suggester 實現(xiàn)，并支持 lucene 中所有可用的查找實現(xiàn)。

這個 Suggester 的主要特點是：

查找實現(xiàn)可插入性
term 字典可插入性，使您可以靈活地選擇詞典實現(xiàn)
分布式支持

在 Solr 的 "techproducts" 示例中找到的 solrconfig.xml 已經(jīng)配置了一個 Suggester 實現(xiàn)。有關(guān)搜索組件的更多信息，請參閱 SolrConfig 中的 RequestHandlers 和SearchComponents 部分。

該 techproducts 示例 solrconfig.xml 有一個 suggest 搜索組件和一個已經(jīng)配置的 /suggest 請求處理程序。您可以將其用作您的配置的基礎(chǔ)，或者從頭開始創(chuàng)建它，如下所述。

添加建議搜索組件

第一步是將搜索組件添加到 solrconfig. xml，并告訴它使用 SuggestComponent。下面是一些可以使用的示例代碼：

<searchComponent name="suggest" class="solr.SuggestComponent">
  <lst name="suggester">
    <str name="name">mySuggester</str>
    <str name="lookupImpl">FuzzyLookupFactory</str>
    <str name="dictionaryImpl">DocumentDictionaryFactory</str>
    <str name="field">cat</str>
    <str name="weightField">price</str>
    <str name="suggestAnalyzerFieldType">string</str>
    <str name="buildOnStartup">false</str>
  </lst>
</searchComponent>

建議搜索組件參數(shù)

建議搜索組件采用多個配置參數(shù)。

查找實現(xiàn)的選擇（lookupImpl，在建議字典中如何找到 term）和字典實現(xiàn)（dictionaryImpl，term 如何存儲在建議字典中）將決定所需的一些參數(shù)。

下面是無論使用什么查找或詞典實現(xiàn)，都可以使用的主要參數(shù)。在下面的部分中提供了每個實現(xiàn)的附加參數(shù)。

searchComponent name 參數(shù)

搜索組件的任意名稱。
name 參數(shù)

這個建議的象征性名稱。您可以在 URL 參數(shù)和 SearchHandler 配置中引用此名稱。一個solrconfig.xml文件中可能有多個這樣的字符。
lookupImpl 參數(shù)

查找實現(xiàn)。有幾種可能的實現(xiàn)，在下面的查找實現(xiàn)一節(jié)中描述。如果沒有設(shè)置，默認查找是JaspellLookupFactory。
dictionaryImpl 參數(shù)

要使用的字典實現(xiàn)。有幾種可能的實現(xiàn)，在“ 字典實現(xiàn) ”一節(jié)中有描述。

如果沒有設(shè)置，默認的字典實現(xiàn)是HighFrequencyDictionaryFactory。但是，如果使用 sourceLocation，字典的實現(xiàn)將會是FileDictionaryFactory。
field 參數(shù)

從索引中使用的字段作為建議 term 的基礎(chǔ)。如果sourceLocation為空（表示除了 FileDictionaryFactory 以外的任何字典實現(xiàn)），則將使用來自索引中的該字段的 term。
作為建議的依據(jù)，必須存儲該字段。您可能希望使用 copyField 規(guī)則來創(chuàng)建由文檔中其他字段的 term 組成的特殊“建議”字段。無論如何，您很可能只需要對該字段進行最少量的分析，因此另外一個選擇是在架構(gòu)中創(chuàng)建一個只使用基本標記或過濾器的字段類型。這里顯示了這種字段類型的一個選項：
```
<fieldType class="solr.TextField" name="textSuggest" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StandardFilterFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>
```
但是，如果您想要根據(jù) term 進行更多的分析，則不需要進行這種最低限度的分析。但是，如果使用AnalyzingLookupFactory作為 lookupImpl，則可以選擇定義用于索引和查詢時間分析的字段類型規(guī)則。
sourceLocation 參數(shù)

字典文件的路徑，如果使用FileDictionaryFactory。如果這個值是空的，那么主索引將被用作 term 和權(quán)重的來源。
storeDir 參數(shù)

存儲字典文件的位置。
buildOnCommit 和 buildOnOptimize 參數(shù)

如果true，則將在 soft-commit 后重建查找數(shù)據(jù)結(jié)構(gòu)。如果為false默認情況下，查詢數(shù)據(jù)將僅在 URL 參數(shù)suggest.build=true請求時才被構(gòu)建。使用buildOnCommit可以用每個 soft-commit 來重建字典，或buildOnOptimize僅在索引被優(yōu)化時才建立字典。

一些查找實現(xiàn)可能需要很長時間才能構(gòu)建，特別是對于大型索引。在這種情況下，不建議使用buildOnCommit或buildOnOptimize特別是使用高頻率的 softCommits 。建議使用suggest.build=true手動發(fā)出請求，以較低的頻率構(gòu)建建議。
buildOnStartup 參數(shù)

如果true,那么當(dāng) Solr 啟動或內(nèi)核被重新加載時，查找數(shù)據(jù)結(jié)構(gòu)將被建立。如果未指定此參數(shù)，則建議程序?qū)z查查找數(shù)據(jù)結(jié)構(gòu)是否存在于磁盤上，如果未找到，則進行構(gòu)建。

如果將其設(shè)置為true可能會導(dǎo)致核心花費時間較長（或重新加載），因為建議數(shù)據(jù)結(jié)構(gòu)需要建立，有時可能需要很長時間。通常首選將此設(shè)置設(shè)置為false默認設(shè)置，而使用suggest.build=true發(fā)出請求來手動構(gòu)建建議。

查找實現(xiàn)（Lookup Implementations）

該 lookupImpl 參數(shù)定義用于在建議索引中查找 term 的算法。有幾種可能的實現(xiàn)可供選擇，有些需要額外的參數(shù)進行配置：

AnalyzingLookupFactory

首先分析傳入的文本并將分析后的表格添加到加權(quán)的 FST，然后在查找時執(zhí)行相同的操作。

該實現(xiàn)使用以下附加屬性：

suggestAnalyzerFieldType 屬性

用于查詢時間和構(gòu)建時期建議分析的字段類型。
exactMatchFirst 屬性

如果為true首先返回默認的確切建議，即使它們是前綴或 FST 中有較大權(quán)重的其他字符串。
preserveSep 屬性

如果true（默認），那么令牌之間的分隔符被保留。這意味著建議對標記化非常敏感（例如，baseball 與 base ball 不同）。
preservePositionIncrements 屬性

如果true，建議將保留位置增量。這意味著，在構(gòu)建建議時，會保留標記過濾器（例如，當(dāng) StopFilter 匹配停用詞時）留下空隙的位置。默認是false。

FuzzyLookupFactory

這是一個 suggester，它是 AnalyzingSuggester 的延伸，但本質(zhì)上是模糊的。相似性由 Levenshtein 算法測量。

它的實現(xiàn)使用以下附加屬性：

exactMatchFirst 屬性

如果true（默認），則首先返回確切建議，即使它們是前綴或 FST 中權(quán)重較大的其他字符串。
preserveSep 屬性

如果true（默認），那么令牌之間的分隔符被保留。這意味著建議對標記化非常敏感（例如，baseball 與 base ball 不同）。
maxSurfaceFormsPerAnalyzedForm 屬性

為單個分析表單保留的最大表面形式數(shù)量。當(dāng)表面形式太多時，我們丟棄最低的權(quán)重。
maxGraphExpansions 屬性

在構(gòu)建 FST（“索引時間”）時，我們將每個通過令牌流圖的路徑作為單獨的條目添加。這就為一個建議添加了多少擴展的上限。默認是-1這意味著沒有限制。
preservePositionIncrements 屬性

如果true，建議將保留位置增量。這意味著，在構(gòu)建建議時，會保留標記過濾器（例如，當(dāng) StopFilter 匹配停用詞時）留下空隙的位置。默認是false。
maxEdits 屬性

允許的字符串編輯的最大數(shù)量。系統(tǒng)的硬性限制是2。默認是1。
transpositions 屬性

如果true默認，則默認的對換應(yīng)視為原始編輯操作。
nonFuzzyPrefix 屬性

必須匹配建議的通用非模糊前綴匹配的長度。默認是1。
minFuzzyLength 屬性

在任何字符串編輯之前，查詢的最小長度將被允許。默認是3。
unicodeAware 屬性

如果true，則maxEdits、minFuzzyLength、transpositions和nonFuzzyPrefix參數(shù)將在 Unicode 代碼點（實際字母），而不是字節(jié)來測量。默認是false。

AnalyzingInfixLookupFactory

分析輸入文本，然后根據(jù)索引文本中的任何標記的前綴匹配建議匹配。這為它的字典使用 Lucene 索引。

它的實現(xiàn)使用以下附加屬性。

indexPath 屬性

使用AnalyzingInfixSuggester時，您可以提供自己的路徑，索引將在其中生成。默認值是analyzingInfixSuggesterIndexDir，并將在您的集合的data/目錄中創(chuàng)建。
minPrefixChars 屬性

使用 PrefixQuery 之前的最小字符數(shù)（默認值是4）。比這更短的前綴被索引為字符 ngrams（增加索引大小，但查找速度更快）。
allTermsRequired 屬性

多個 term 的布爾選項。默認是true，所有的 term 將是必需的。
highlight 屬性

突出顯示 term。默認是true。

這個實現(xiàn)支持上下文過濾。

BlendedInfixLookupFactory

AnalyzingInfixSuggester 的擴展，它為匹配的文檔中的權(quán)重前綴匹配提供附加功能。您可以將其分數(shù)提高，如果命中是接近開始的建議，反之亦然。

該實現(xiàn)使用以下附加屬性：

blenderType 屬性

用于使用第一個匹配詞的位置計算權(quán)重系數(shù)。可以是以下之一：
- position_linear
  
  weightFieldValue*(1 - 0.10*position)：匹配開始將獲得更高的分數(shù)。這是默認的。
- position_reciprocal
  
  weightFieldValue/(1+position)：匹配結(jié)束將獲得更高的分數(shù)。
  
  exponent：position_reciprocal blenderType 的可選配置變量，用于控制分數(shù)增加或減少的速度。默認2.0。
numFactor 屬性

要將結(jié)果修剪的搜索元素數(shù)乘以的系數(shù)。默認值為 10。
indexPath 屬性

使用BlendedInfixSuggester時，您可以提供自己的路徑，索引將在其中生成。默認的目錄名稱是blendedInfixSuggesterIndexDir，將在您的集合數(shù)據(jù)目錄中創(chuàng)建。
minPrefixChars 屬性

使用 PrefixQuery 之前的最小字符數(shù)（默認值是4）。比這更短的前綴被索引為字符 ngrams（增加索引大小，但查找速度更快）。

這個實現(xiàn)支持上下文過濾。

FreeTextLookupFactory

它會查看最后一個標記以及用戶輸入的任何最終標記的前綴（如果存在），以預(yù)測最有可能的下一個標記。還可以指定需要考慮的以前標記的數(shù)目。當(dāng)主要建議未能找到任何建議時，此suggester 只能用作后備。

該實現(xiàn)使用以下附加屬性：

suggestFreeTextAnalyzerFieldType

分析器用于“查詢時間”和“建立時間”來分析建議。該參數(shù)是必需的。
ngrams

最大數(shù)量的標記數(shù)，其中超出的單個將被作為字典。默認值是2。如果增加這個數(shù)字，意味著在提出建議時，要比以前的兩個標記考慮的要多。

FSTLookupFactory

基于自動機的查找。此實現(xiàn)的生成速度較慢，但是提供了最低的內(nèi)存成本。除非您需要更復(fù)雜的匹配結(jié)果，否則我們推薦使用此實現(xiàn)，在這種情況下，您應(yīng)該使用 Jaspell 實現(xiàn)。

該實現(xiàn)使用以下附加屬性：

exactMatchFirst

如果true（默認的）首先返回確切建議，即使它們是前綴或 FST 中權(quán)重較大的其他字符串。
weightBuckets

在建立詞典時，建議將使用的權(quán)重的單獨的 bucket 的數(shù)量。

TSTLookupFactory

一種簡單的基于三元線索的查找。

WFSTLookupFactory

一個加權(quán)自動機表示，這是一個替代 FSTLookup 的更細致的排序。WFSTLookup不使用 bucket，而是使用最短路徑算法。

請注意，它期望權(quán)重是整數(shù)。如果重量不足，則認為是1.0。權(quán)重在 spellcheck.onlyMorePopular=true 時影響匹配建議的排序：權(quán)重被視為“受歡迎程度”分數(shù)，較高的權(quán)重優(yōu)先于權(quán)重較低的建議。

JaspellLookupFactory

基于 JaSpell 項目的三元樹查找更復(fù)雜的查找。如果您需要更復(fù)雜的匹配結(jié)果，請使用此實現(xiàn)。

字典實現(xiàn)

字典實現(xiàn)定義 term 的存儲方式。有幾個選項，如果需要，可以在單個請求中使用多個字典。

DocumentDictionaryFactory

包含 term、權(quán)重和從索引中提取的可選有效負載的字典。

除了通常為 Suggester 描述的參數(shù)以及查找實現(xiàn)之外，該字典實現(xiàn)還采用以下參數(shù)：

weightField

存儲的字段或數(shù)字 DocValue 字段。該參數(shù)是可選的。
payloadField

該payloadField應(yīng)存儲的字段。該參數(shù)是可選的。
contextField

用于上下文過濾的字段。請注意，只有一些查找實現(xiàn)支持過濾。

DocumentExpressionDictionaryFactory

此字典實現(xiàn)與 DocumentDictionaryFactory 相同，但允許用戶將任意表達式指定到 weightExpression 標記中。
除了通常為 Suggester 描述的參數(shù)和查找實現(xiàn)之外，此字典實現(xiàn)還采用以下參數(shù):

payloadField

該payloadField應(yīng)存儲的字段。該參數(shù)是可選的。
weightExpression

用于對建議進行評分的任意表達式。使用的字段必須是數(shù)字字段。此參數(shù)是必需的。
contextField

用于上下文過濾的字段。請注意，只有一些查找實現(xiàn)支持過濾。

HighFrequencyDictionaryFactory

這個字典的實現(xiàn)允許在非常常見的 term 可能壓倒其他 term 的情況下，添加閾值以減少不常用的 term。

除了通常為 Suggester 描述的參數(shù)和查找實現(xiàn)之外，此字典實現(xiàn)還需要一個參數(shù)：

threshold

介于0和1之間的值，表示為了添加到查閱字典而應(yīng)出現(xiàn)的文檔總數(shù)的最小部分。

FileDictionaryFactory

這個字典實現(xiàn)允許使用包含建議條目的外部文件。權(quán)重和有效載荷也可以使用。

如果使用字典文件，它應(yīng)該是 UTF-8 編碼的純文本文件。您可以在詞典文件中同時使用單個 term 和短語。如果添加權(quán)重或有效負載，則應(yīng)使用與 fieldDelimiter 屬性一起定義的分隔符（默認值為“\ t”，即制表符）將其與 term 分開。如果使用有效載荷，則文件中的第一行必須指定有效載荷。

除了通常為 Suggester 描述的參數(shù)和查找實現(xiàn)之外，此字典實現(xiàn)還需要一個參數(shù)：

fieldDelimiter

指定分隔條目、權(quán)重和有效載荷的分隔符。默認是tab（\t）。
示例文件：
```
acquire
accidentally    2.0
accommodate 3.0
```

多個詞典

可以在單個 SuggestComponent 定義中包含多個 dictionaryImpl 定義。
為此，只需定義單獨的 suggesters，如以下示例所示:

<searchComponent name="suggest" class="solr.SuggestComponent">
  <lst name="suggester">
    <str name="name">mySuggester</str>
    <str name="lookupImpl">FuzzyLookupFactory</str>
    <str name="dictionaryImpl">DocumentDictionaryFactory</str>
    <str name="field">cat</str>
    <str name="weightField">price</str>
    <str name="suggestAnalyzerFieldType">string</str>
  </lst>
  <lst name="suggester">
    <str name="name">altSuggester</str>
    <str name="dictionaryImpl">DocumentExpressionDictionaryFactory</str>
    <str name="lookupImpl">FuzzyLookupFactory</str>
    <str name="field">product_name</str>
    <str name="weightExpression">((price * 2) + ln(popularity))</str>
    <str name="sortField">weight</str>
    <str name="sortField">price</str>
    <str name="storeDir">suggest_fuzzy_doc_expr_dict</str>
    <str name="suggestAnalyzerFieldType">text_en</str>
  </lst>
</searchComponent>

在查詢中使用這些 Suggesters 時，您可以在請求中定義多個 suggest.dictionary 參數(shù)，引用在搜索組件定義中為每個 Suggester 指定的名稱。響應(yīng)將包括每個提示的章節(jié)中的 term。有關(guān)示例請求和響應(yīng)，請參見下面的示例使用部分。

添加 Suggest 請求處理程序

添加搜索組件后，必須添加一個請求處理程序到 solrconfig.xml 中。這個請求處理程序與任何其他請求處理程序一樣工作，并允許您為服務(wù)建議請求配置默認參數(shù)。請求處理程序定義必須包含之前定義的“建議”搜索組件。

<requestHandler name="/suggest" class="solr.SearchHandler" startup="lazy">
  <lst name="defaults">
    <str name="suggest">true</str>
    <str name="suggest.count">10</str>
  </lst>
  <arr name="components">
    <str>suggest</str>
  </arr>
</requestHandler>

建議請求處理程序參數(shù)

以下參數(shù)允許您為建議請求處理程序設(shè)置默認值：

suggest=true

這個參數(shù)應(yīng)該總是true，因為我們總是想運行提交給這個處理程序的查詢的 Suggester。
suggest.dictionary

在搜索組件中配置的字典組件的名稱。這是一個強制參數(shù)。它可以在請求處理程序中設(shè)置，或者在查詢時作為參數(shù)發(fā)送。
suggest.q

用于建議查找的查詢。
suggest.count

指定 Solr 返回的建議數(shù)量。
suggest.cfq

上下文過濾器查詢，用于根據(jù)上下文字段篩選建議 (如果 suggester 支持)。
suggest.build

如果true，它會建立建議索引。這可能只對最初的請求有用；您可能不想在每個請求上建立字典，特別是在生產(chǎn)系統(tǒng)中。如果您想保持您的字典是最新的，您應(yīng)該使用buildOnCommit或buildOnOptimize參數(shù)搜索組件。
suggest.reload

如果true它將重新加載建議索引。
suggest.buildAll

如果true，它會建立所有的建議索引。
suggest.reloadAll

如果true它將重新加載所有的建議索引。

這些屬性也可以在查詢時被覆蓋，或者根本不在請求處理器中設(shè)置，并且總是在查詢時發(fā)送。

上下文過濾：上下文過濾（suggest.cfq）目前只支持AnalyzingInfixLookupFactory和BlendedInfixLookupFactory，并且只有在Document*Dictionary支持的情況下。所有其他的實現(xiàn)將返回未經(jīng)過濾的匹配，就好像沒有請求過濾一樣。

使用示例

通過權(quán)重獲取建議

這是使用單個字典和單個 Solr 核心的基本建議。

示例查詢：

http://localhost:8983/solr/techproducts/suggest?suggest=true&suggest.build=true&suggest.dictionary=mySuggester&suggest.q=elec

在這個例子中，我們簡單地使用 suggest.q 參數(shù)請求了字符串 “elec”，并要求建立字典 suggest.build（但是，注意，您可能不想在每個查詢上建立索引 - 那么如果你經(jīng)常更換文件，則應(yīng)該使用 buildOnCommit 或者buildOnOptimize ）。

響應(yīng)示例：

{
  "responseHeader": {
    "status": 0,
    "QTime": 35
  },
  "command": "build",
  "suggest": {
    "mySuggester": {
      "elec": {
        "numFound": 3,
        "suggestions": [
          {
            "term": "electronics and computer1",
            "weight": 2199,
            "payload": ""
          },
          {
            "term": "electronics",
            "weight": 649,
            "payload": ""
          },
          {
            "term": "electronics and stuff2",
            "weight": 279,
            "payload": ""
          }
        ]
      }
    }
  }
}

使用多個詞典

如果您已經(jīng)定義了多個字典，您可以在查詢中使用它們。

示例查詢：

http://localhost:8983/solr/techproducts/suggest?suggest=true&suggest.dictionary=mySuggester&suggest.dictionary=altSuggester&suggest.q=elec

在這個例子中，我們發(fā)送了字符串 'elec' 作為 suggest.q 參數(shù)，并命名了兩個要使用的 suggest.dictionary 定義。

響應(yīng)示例：

{
  "responseHeader": {
    "status": 0,
    "QTime": 3
  },
  "suggest": {
    "mySuggester": {
      "elec": {
        "numFound": 1,
        "suggestions": [
          {
            "term": "electronics and computer1",
            "weight": 100,
            "payload": ""
          }
        ]
      }
    },
    "altSuggester": {
      "elec": {
        "numFound": 1,
        "suggestions": [
          {
            "term": "electronics and computer1",
            "weight": 10,
            "payload": ""
          }
        ]
      }
    }
  }
}

上下文過濾

上下文過濾允許您通過單獨的上下文字段（如類別、部門或任何其他標記）來過濾建議。AnalyzingInfixLookupFactory 與 BlendedInfixLookupFactory 目前支持此功能，當(dāng)支持 DocumentDictionaryFactory。

添加 contextField 到您的 suggester 配置中。這個例子將建議名稱，并允許按類別過濾：

在 solrconfig.xml 中：

<searchComponent name="suggest" class="solr.SuggestComponent">
  <lst name="suggester">
    <str name="name">mySuggester</str>
    <str name="lookupImpl">AnalyzingInfixLookupFactory</str>
    <str name="dictionaryImpl">DocumentDictionaryFactory</str>
    <str name="field">name</str>
    <str name="weightField">price</str>
    <str name="contextField">cat</str>
    <str name="suggestAnalyzerFieldType">string</str>
    <str name="buildOnStartup">false</str>
  </lst>
</searchComponent>

示例-上下文過濾建議查詢：

http://localhost:8983/solr/techproducts/suggest?suggest=true&suggest.build=true&suggest.dictionary=mySuggester&suggest.q=c&suggest.cfq=memory

suggester 只會帶回標記為“cat = memory”的產(chǎn)品的建議。

以上內(nèi)容是否對您有幫助：

在文檔使用的過程中是否遇到以下問題：

內(nèi)容錯誤
更新不及時
鏈接錯誤
缺少代碼/圖片示列
太簡單/步驟待完善
其他

更多建議：

提交建議

← Solr文檔轉(zhuǎn)換器

MoreLikeThis搜索組件介紹 →

寫筆記

我要補充

查看完整版筆記

99re热这里只有精品视频,7777色鬼xxxx欧美色妇,国产成人精品一区二三区在线观看,内射爽无广熟女亚洲,精品人妻av一区二区三区

Solr：suggest組件使用大全

Suggester

添加建議搜索組件

建議搜索組件參數(shù)

查找實現(xiàn)（Lookup Implementations）

AnalyzingLookupFactory

FuzzyLookupFactory

AnalyzingInfixLookupFactory

BlendedInfixLookupFactory

FreeTextLookupFactory

FSTLookupFactory

TSTLookupFactory

WFSTLookupFactory

JaspellLookupFactory

字典實現(xiàn)

DocumentDictionaryFactory

DocumentExpressionDictionaryFactory

HighFrequencyDictionaryFactory

FileDictionaryFactory

多個詞典

添加 Suggest 請求處理程序

建議請求處理程序參數(shù)

使用示例

通過權(quán)重獲取建議

使用多個詞典

上下文過濾