這些設(shè)置都是在 solrconfig. xml 中的 <query> 元素的子元素中配置的。

<query>
  ...
</query>

高速緩存

Solr緩存與索引搜索器的特定實例關(guān)聯(lián)，索引的特定視圖在該搜索器的生命周期內(nèi)不發(fā)生變化。只要索引搜索器正在被使用，其緩存中的任何項目都將是有效的并可供重用。Solr中的緩存與許多其他應(yīng)用程序中的緩存不同，因為緩存的Solr對象在一段時間間隔后不會過期；相反，它們在索引檢索器的整個生命周期內(nèi)仍然有效。

當(dāng)新的搜索器被打開時，當(dāng)前的搜索器將繼續(xù)服務(wù)請求，而新的搜索者則 auto-warms 其緩存。新的搜索器使用當(dāng)前搜索的緩存預(yù)先填充自己的緩存。當(dāng)新的搜索器準備好時，它被注冊為當(dāng)前的搜索器，并開始處理所有新的搜索請求。一旦完成了所有的請求，舊的搜索器將被關(guān)閉。

在Solr中，有三個緩存實現(xiàn)：solr.search.LRUCache，solr.search.FastLRUCache和solr.search.LFUCache。

縮寫詞LRU代表最近最少的使用。當(dāng)LRU緩存填滿時，具有最早的最后訪問時間戳的條目被驅(qū)逐，以為新條目騰出空間。最終的結(jié)果是被頻繁訪問的條目傾向于停留在緩存中，而那些不經(jīng)常訪問的條目傾向于退出，并且如果需要的話將會從索引中重新獲取。

Solr 1.4中引入的這個FastLRUCache函數(shù)被設(shè)計成無鎖的，所以它非常適合于在請求中多次觸發(fā)的緩存。

LRUCache和FastLRUCache都使用 auto-warm 計數(shù)來支持整數(shù)和百分比，當(dāng) warm 發(fā)生時，它會相對于緩存的當(dāng)前大小進行評估。

該LFUCache指最不常用的緩存。這與LRU緩存的工作方式類似，不同之處在于當(dāng)緩存填滿時，已經(jīng)被使用的條目被刪除。

Solr Admin UI中的Statistics頁面將顯示有關(guān)所有活動緩存的性能的信息。這些信息可以幫助您針對特定應(yīng)用程序適當(dāng)調(diào)整各種緩存的大小。當(dāng)搜索器終止時，其緩存使用情況的摘要也被寫入日志。

每個緩存都有設(shè)置來定義它的初始大?。╥nitialSize），最大大?。╯ize）和項目的數(shù)量，以用于warm（autowarmCount）。LRU和FastLRU緩存實現(xiàn)可以采取一個百分比，而不是autowarmCount的絕對值。

FastLRUCache和LFUCache支持showItems屬性。這是要在緩存的統(tǒng)計信息頁面中顯示的緩存項目的數(shù)量。這是為了調(diào)試。

下面介紹每個緩存的詳細信息。

filterCache

SolrIndexSearcher使用此緩存用于對所有匹配查詢的所有文檔的無序集進行篩選。數(shù)字屬性控制緩存中條目的數(shù)量。

Solr使用filterCache最典型的方法是緩存每個fq搜索參數(shù)的結(jié)果，盡管還有一些其他的情況。隨后的查詢使用相同的參數(shù)過濾器查詢導(dǎo)致緩存命中并快速返回結(jié)果。請參閱搜索fq參數(shù)的詳細討論。使用此緩存的另一個Solr功能是filter(…?)語法在默認Lucene查詢解析器中。

當(dāng)配置參數(shù)facet.method設(shè)置為fc時，Solr也使用這個高速緩存進行faceting。有關(guān)faceting的討論，請參見搜索。

<filterCache class="solr.LRUCache"
             size="512"
             initialSize="512"
             autowarmCount="128"/>

queryResultCache

該緩存保存以前搜索的結(jié)果：基于查詢、排序和所請求的文檔范圍的文檔ID（DocList）的有序列表。

queryResultCache具有使用了附加的（可選的）設(shè)置，以限制使用的最大RAM（maxRamMB）。這使您可以指定此緩存內(nèi)容使用的最大堆大小（以兆字節(jié)為單位）。當(dāng)緩存增長超過此大小時，最早訪問的查詢將被逐出，直到緩存的堆使用率降至指定的限制以下。

<queryResultCache class="solr.LRUCache"
                  size="512"
                  initialSize="512"
                  autowarmCount="128"
                  maxRamMB="1000"/>

documentCache

這個緩存包含Lucene文檔對象（每個文檔的存儲字段）。由于Lucene的內(nèi)部文檔ID是暫時的，所以這個緩存不是自動加熱的。為了確保Solr在請求期間不需要重新獲取文檔，documentCache應(yīng)該始終大于max_resultstimes乘以max_concurrent_queries。您存儲在文檔中的字段越多，此緩存的內(nèi)存使用率就越高。

<documentCache class="solr.LRUCache"
               size="512"
               initialSize="512"
               autowarmCount="0"/>

用戶定義的高速緩存

您也可以為您自己的應(yīng)用程序代碼定義指定的緩存來使用。您可以找到并通過名字調(diào)用使用緩存對象SolrIndexSearcher的方法getCache()，cacheLookup()和cacheInsert()。

<cache name="myUserCache" class="solr.LRUCache"
                          size="4096"
                          initialSize="1024"
                          autowarmCount="1024"
                          regenerator="org.mycompany.mypackage.MyRegenerator" />

如果要auto-warming緩存，請包含一個regenerator屬性的具有實現(xiàn)solr.search.CacheRegenerator類的完全限定名稱。您也可以使用NoOpRegenerator，它只是簡單地重新填充舊項目的緩存。使用regenerator參數(shù)來定義它，比如：regenerator =“solr.NoOpRegenerator”。

查詢大小和 Warm

maxBooleanClauses

這設(shè)置了布爾查詢中允許的最大子句數(shù)。這可能會影響擴展到具有大量布爾項的查詢的范圍或前綴查詢。如果超出此限制，則會引發(fā)異常。

<maxBooleanClauses>1024</maxBooleanClauses>

此選項修改影響所有Solr核心的全局屬性。如果多個solrconfig.xml文件在這個屬性上不一致，則任何時候的值都將基于初始化的最后一個Solr核心。

enableLazyFieldLoading

如果此參數(shù)設(shè)置為true，則不直接請求的字段將根據(jù)需要延遲加載。這可以提高性能，如果最常見的查詢只需要一小部分的字段，特別是在不經(jīng)常訪問的字段大小較大的情況下。

<enableLazyFieldLoading>true</enableLazyFieldLoading>

useFilterForSortedQuery

此參數(shù)將Solr配置為使用篩選器來滿足搜索。如果所請求的排序不包括“score”，filterCache則將檢查與查詢匹配的過濾器。對于大多數(shù)情況，這只有在經(jīng)常用不同的排序選項請求相同的搜索并且沒有使用“score”時才是有用的。

<useFilterForSortedQuery>true</useFilterForSortedQuery>

queryResultWindowSize

與queryResultCache一起使用時，將緩存請求數(shù)量的文檔ID的超集。例如，如果響應(yīng)于特定查詢的搜索請求文檔10到19，并且queryWindowSize是50，則文檔0到49將被高速緩存。

<queryResultWindowSize>20</queryResultWindowSize>

queryResultMaxDocsCached

該參數(shù)將文檔的最大數(shù)量設(shè)置為在queryResultCache中任何條目的緩存。

<queryResultMaxDocsCached>200</queryResultMaxDocsCached>

useColdSearcher

此設(shè)置控制是否有當(dāng)前沒有注冊的搜索器的搜索請求應(yīng)等待新的搜索器warm（false）或立即執(zhí)行（true）。當(dāng)設(shè)置為“false”時，請求將被阻塞，直到搜索器已經(jīng)warm其緩存為止。

<useColdSearcher>false</useColdSearcher>

maxWarmingSearchers

此參數(shù)設(shè)置在任何給定時間可能在后臺預(yù)熱的搜索器的最大數(shù)量。超過這個限制會引發(fā)錯誤。對于只讀，值為2是合理的。

<maxWarmingSearchers>2</maxWarmingSearchers>

與查詢相關(guān)的監(jiān)聽器

如緩存部分所述，新索引搜索器被緩存?？梢允褂帽O(jiān)聽器的觸發(fā)器執(zhí)行與查詢有關(guān)的任務(wù)。最常見的用途是定義查詢，以便在索引搜索器啟動時進一步“warm”索引搜索器。這種方法的一個好處是，可以預(yù)先填充字段緩存以進行更快的排序。

良好的查詢選擇對于這種類型的監(jiān)聽器是關(guān)鍵的。最好選擇最常見或最重的查詢，不僅包括使用的關(guān)鍵字，還包括任何其他參數(shù)，如排序或過濾請求。

有兩種類型的事件可以觸發(fā)監(jiān)聽器。正在準備一個新的搜索時，會發(fā)生firstSearcher事件，但沒有當(dāng)前注冊搜索來處理請求或獲得從auto-warming的數(shù)據(jù)（例如，Solr上的啟動）。每當(dāng)有新的搜索器準備好時，就會觸發(fā)一個newSearcher事件，并有一個當(dāng)前的搜索器處理請求。

下面的（注釋掉的）例子可以在Solr sample_techproducts_configs 配置集的solrconfig.xml的文件中找到，并且演示如何使用這個solr.QuerySenderListener類來warm一組顯式查詢：

<listener event="newSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
  <!--
    <lst><str name="q">solr</str><str name="sort">price asc</str></lst>
    <lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
   -->
  </arr>
</listener>

<listener event="firstSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
    <lst><str name="q">static firstSearcher warming in solrconfig.xml</str></lst>
  </arr>
</listener>

上面的代碼來自一個solrconfig . xml示例。

一個關(guān)鍵的最佳實踐是在將應(yīng)用程序應(yīng)用到生產(chǎn)之前修改這些默認值，但是請注意：當(dāng)示例查詢在“newSearcher”部分被注釋掉的時候，示例查詢并沒有被注釋為“firstSearcher”事件。

如果與您的搜索應(yīng)用程序無關(guān)，使用查詢字符串“static firstSearcher在solrconfig.xml中warm”來auto-warming索引搜索器是毫無意義的。