solrconfig.xml 應用解析調優

solrconfig.xml配置文件主要定義了SOLR的一些處理規則，包括索引數據的存放位置，更新，刪除，查詢的一些規則配置。
下面將對solrconfig進行詳細描述：
1 <luceneMatchVersion>4.8</luceneMatchVersion> 表示solr底層使用的是lucene4.8
2 <lib dir="../../../contrib/extraction/lib" regex=".*\.jar" /> 表示solr引用包的位置,當dir對應的目錄不存在時候，會忽略此屬性
3 <dataDir>${solr.data.dir:}</dataDir> 定義了索引數據和日誌文件的存放位置
4 directoryFactory
索引存儲方案，共有如下存儲方案：
1)、solr.StandardDirectoryFactory 這是一個基於文件系統存儲目錄的工廠，它會試圖選擇最好的實現基於你當前的操做系統和Java虛擬機版本。
2)、solr.SimpleFSDirectoryFactory 適用於小型應用程序，不支持大數據和多線程。
3)、solr.NIOFSDirectoryFactory 適用於多線程環境，可是不適用在windows平臺（很慢），是由於JVM還存在bug。
4)、solr.MMapDirectoryFactory 這個是solr3.1到4.0版本在linux64位系統下默認的實現。它是經過使用虛擬內存和內核特性調用
mmap去訪問存儲在磁盤中的索引文件。它容許lucene或solr直接訪問I/O緩存。若是不須要近實時搜索功能，使用此工廠是個不錯的方案。
5)、solr.NRTCachingDirectoryFactory 此工廠設計目的是存儲部分索引在內存中，從而加快了近實時搜索的速度。
6)、solr.RAMDirectoryFactory 這是一個內存存儲方案，不能持久化存儲，在系統重啓或服務器crash時數據會丟失。且不支持索引複製

<directoryFactory name="DirectoryFactory" 
                    class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}">
    <str name="solr.hdfs.home">${solr.hdfs.home:}</str>
    <str name="solr.hdfs.confdir">${solr.hdfs.confdir:}</str>
    <str name="solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</str>
    <str name="solr.hdfs.blockcache.global">${solr.hdfs.blockcache.global:true}</str>

  </directoryFactory>

5 <codecFactory class="solr.SchemaCodecFactory"/>
<schemaFactory class="ClassicIndexSchemaFactory"/>
編解碼容許使用自定義的編解碼器。例如：若是想啓動per-field DocValues格式, 能夠在solrconfig.xml裏面設置SchemaCodecFactory：
docValuesFormat="Lucene42": 這是默認設置，全部數據會被加載到堆內存中。
docValuesFormat="Disk": 這是另一個實現，將部分數據存儲在磁盤上。
docValuesFormat="SimpleText": 文本格式，很是慢，用於學習。

6 <indexConfig>
用於設置索引的低級別的屬性
1） <filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/> //限制token最大長度
2） <writeLockTimeout>1000</writeLockTimeout> //IndexWriter等待解鎖的最長時間（毫秒）
3） <maxIndexingThreads>12</maxIndexingThreads> //生成索引時使用的最大線程數.
4） <useCompoundFile>false</useCompoundFile>
//solr默認爲false。若是爲true,索引文件減小,檢索性能下降,追求平衡。經過將不少 Lucene 內部文件整合到單一一個文件來減小使用中的文件的數量。這可有助於減小 Solr 使用的文件句柄數目，代價是下降了性能。除非是應用程序用完了文件句柄
5） <ramBufferSizeMB>100</ramBufferSizeMB> //緩存
6） <maxBufferedDocs>1000</maxBufferedDocs> //緩存。兩個同時定義時命中較低的那個。在合併內存中文檔和建立新段以前，定義所需索引的最小文檔數。段是用來存儲索引信息的 Lucene 文件。較大的值可以使索引時間變快但會犧牲較多的內存。
7）

`<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
        <int name="maxMergeAtOnce">20</int>
        <int name="segmentsPerTier">20</int>
        </mergePolicy>`

//合併策略。
8） <mergeFactor>10</mergeFactor> //合併因子,每次合併多少個segments。決定低水平的 Lucene 段被合併的頻率。較小的值（最小爲 2）使用的內存較少但致使的索引時間也更慢。較大的值可以使索引時間變快但會犧牲較多的內存。
9） <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/> //合併調度器。
10） <lockType>${solr.lock.type:native}</lockType> //鎖。
11） <unlockOnStartup>false</unlockOnStartup> //unlockOnStartup告知Solr 忽略在多線程環境中用來保護索引的鎖定機制。在某些狀況下，索引可能會因爲不正確的關機或其餘錯誤而一直處於鎖定，這就妨礙了添加和更新。將其設置爲 true 能夠禁用啓動鎖定，進而容許進行添加和更新。
12） <termIndexInterval>128</termIndexInterval> //Lucene loads terms into memory 間隔
13） <reopenReaders>true</reopenReaders> //從新打開,替代先關閉-再打開。
14） <deletionPolicy class="solr.SolrDeletionPolicy"> //提交刪除策略,必須實現org.apache.lucene.index.IndexDeletionPolicy
15） <str name="maxCommitsToKeep">1</str> //最多持有提交點的數量
16） <str name="maxOptimizedCommitsToKeep">0</str> //最多持有優化提交點的數量
17） <str name="maxCommitAge">2MINUTES</str> OR <str name="maxCommitAge">1DAY</str><br>　//一旦達到指定的時間刪除全部的提交點　　
18） <infoStream file="INFOSTREAM.txt">false</infoStream>//至關於把建立索引時的日誌輸出。
<lockType>${solr.lock.type:native}</lockType>
設置索引庫的鎖方式，主要有三種：
⑴.single：適用於只讀的索引庫，即索引庫是定死的，不會再更改
⑵.native：使用本地操做系統的文件鎖方式，不能用於多個solr服務共用同一個索引庫。Solr3.6 及後期版本使用的默認鎖機制。
⑶.simple：使用簡單的文件鎖機制
19) <maxMergeDocs> 2147483647 </maxMergeDocs> //控制可由 Solr 合併的 Document 的最大數。較小的值 (< 10,000) 最適合於具備大量更新的應用程序。
20) <maxFieldLength> 10000 </maxFieldLength>
//對於給定的 Document，控制可添加到 Field 的最大條目數，進而截斷該文檔。若是文檔可能會很大，就須要增長這個數值。然而，若將這個值設置得太高會致使內存不足錯誤。
（默認設置 <filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/>）

7 updateHandler節點
<updateLog>
<str name="dir">${solr.ulog.dir:}</str>
</updateLog>
設置索引庫更新日誌，默認路徑爲solr home下面的data/tlog。隨着索引庫的頻繁更新，tlog文件會愈來愈大，因此建議提交索引時採用硬提交方式，即批量提交。

`<autoCommit>
   <maxDocs>10000</maxDocs>
   <maxTime>${solr.autoCommit.maxTime:5000}</maxTime>
   <openSearcher>true</openSearcher>
 </autoCommit>`
自動硬提交方式:maxTime：設置多長時間提交一次maxDocs：設置達到多少文檔提交一次openSearcher：文檔提交後是否開啓新的searcher，
若是false，文檔只是提交到index索引庫，搜索結果中搜不到這次提交的文檔；若是true，既提交到index索引庫，也能在搜索結果中搜到這次提交的內容。

 `<autoSoftCommit>`
   `<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>` 
 `</autoSoftCommit>` //軟提交；
 一、把內存文件fsync到磁盤，但不建立index descriptor。也就是說原索引和如今的索引還互不感知，因此若是jvm崩潰，那這部分索引就沒了。
 二、能夠從新打開searcher，使得新的索引能夠被查找到。

 `<listener event="postCommit" class="solr.RunExecutableListener">`  
    `<str name="exe">solr/bin/snapshooter</str>`   //exe--可執行的文件類型 
    `<str name="dir">.</str>`//dir--能夠用該目錄作爲當前的工做目錄。默認爲 "." 
    `<bool name="wait">true</bool>`                //wait--調用線程要等到可執行的返回值 
    `<arr name="args"> <str>arg1</str> <str>arg2</str> </arr>`   //args--傳遞給程序的參數 默認nothing  
    `<arr name="env"> <str>MYVAR=val1</str> </arr>`              //env--環境變量的設置 默認nothing 
 `</listener>`  
 //一個postCommit的事件被觸發當每個提交以後，    

 PS：本身的一些看法，solr提交索引的方式共有三種，經過solr api去提交的方式性能不好，不建議採用；我的建議仍是採用autocommit的自動提交，雖然比較消耗資源，可是能最大限度保存意外形成的索引丟失的狀況；

 更多信息，請查看https://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/

8 Query查詢節點
<maxBooleanClauses>1024</maxBooleanClauses>
設置boolean 查詢中，最大條件數。在範圍搜索或者前綴搜索時，會產生大量的 boolean 條件，
若是條件數達到這個數值時，將拋出異常，限制這個條件數，能夠防止條件過多查詢等待時間過長。
緩存方法http://www.cnblogs.com/phinecos/archive/2012/05/24/2517018.html

`<!-- 過濾器緩存 --> 
 <filterCache class="solr.FastLRUCache"
             size="32768"
             initialSize="32768"
             autowarmCount="512"/>`

 `<!-- 查詢結果緩存 -->
 <queryResultCache class="solr.FastLRUCache"
             size="8192"
             initialSize="8192"
             autowarmCount="512"/>`

 `<!-- 查詢文檔緩存 --> 
 <documentCache class="solr.FastLRUCache"
             size="4096"
             initialSize="4096"
             autowarmCount="0"/>`

 `<!-- 自定義緩存 --> 
 <cache name="perSegFilter"
             class="solr.search.LRUCache"
             size="4096"
             initialSize="4096"
             autowarmCount="4096"
             regenerator="solr.NoOpRegenerator" />`

 `<!-- 字段值緩存 --> 
 <fieldValueCache class="solr.FastLRUCache"
             size="512"
             autowarmCount="128"
             showItems="32" />`


 1）size：cache中可保存的最大的項數，默認是1024

 2）initialSize：cache初始化時的大小，默認是1024。

 3）autowarmCount：當切換SolrIndexSearcher時，能夠對新生成的SolrIndexSearcher作autowarm（預熱）處理。autowarmCount表示從舊的SolrIndexSearcher中取多少項來在新的SolrIndexSearcher中被從新生成，如何從新生成由CacheRegenerator實現。在當前的1.4版本的Solr中，這個autowarmCount只能取預熱的項數，未來的4.0版本能夠指定爲已有cache項數的百分比，以便能更好的平衡autowarm的開銷及效果。若是不指定該參數，則表示不作autowarm處理。

 實現上，LRUCache直接使用LinkedHashMap來緩存數據，由initialSize來限定cache的大小，淘汰策略也是使用LinkedHashMap的內置的LRU方式，讀寫操做都是對map的全局鎖，因此併發性效果方面稍差。

 `<enableLazyFieldLoading>true</enableLazyFieldLoading>`   //某些字段延時加載，以提升性能，例如內容較多的壓縮文件
 `<queryResultWindowSize>50</queryResultWindowSize>`       //Result Window Size 優化queryResultCache結果cache
 `<queryResultMaxDocsCached>800</queryResultMaxDocsCached>`  //查詢結果文檔的最大緩存數

 `<!-- 與請求相關的監聽器 -->  
 <!-- QuerySenderListener使用NamedList的數組和每一個序列NamedList的執行一個本地查詢請求。--> 
 <listener event="newSearcher" class="solr.QuerySenderListener">
 <arr name="queries">
       </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>
 <useColdSearcher>true</useColdSearcher>`   //使用雲搜索 
 `<maxWarmingSearchers>8</maxWarmingSearchers>`
 //該參數用於設置最大的 searcher 數量，這些 searcher 實現預熱好的，隨時能夠調用。若是超過這個數量，將會報錯。在一個只讀的索引庫中，2個預熱的 searcher 是相對合理的，若是是讀寫的索引庫中，根據內存和cpu的大小能夠給一個相對大一點的值。

9 Request Dispatcher（請求轉發器）
<!-- Request Dispatcher 主要是介紹當有請求訪問SolrCore時SolrDispatchFilter如何處理。 handleSelect是一個之前版本中遺留下來的屬性,會影響請求的對應行爲（好比/select?qt=XXX）。 當handleSelect="true"時致使SolrDispatchFilter將請求轉發給qt指定的處理器（前提是/select已經註冊）。 當handleSelect="false"時會直接訪問/select,若/select未註冊則爲404。 -->
<requestDispatcher handleSelect="false" >

`<!-- Request Parsing：請求解析  
 這些設置說明Solr Requests如何被解析,以及對ContentStreams有什麼限制。  
 enableRemoteStreaming - 是否容許使用stream.file和stream.url參數來指定遠程streams。  
 multipartUploadLimitInKB - 指定多文件上傳時Solr容許的最大的size,設置了經過多部分（multi-part）的HTTP POST請求提交的文檔大小的上限，單位是Kb。這個值指定爲1024的倍數來肯定Bytes的大小
 formdataUploadLimitInKB - 表單經過POST請求發送的最大size,設置了一個用Kb表示的限制，用以限制HTTP POST請求中提交的表單數據的大小，這個大小能夠用來傳遞請求的參數但並不適合（寫入）URL中
 addHttpRequestToContext - 用來聲明原始的HttpServletRequest對象應該被包括在使用httpRequest的SolrQueryRequest的上下文集合（context map）中。
 這個HttpServletRequest不會用於任何Solr的組成部分，但在開發自定義的插件是會頗有用
 -->` 
 `<requestParsers enableRemoteStreaming="true" 
                 multipartUploadLimitInKB="2048000"
                 formdataUploadLimitInKB="20480"
                 addHttpRequestToContext="false"/>`

 `<httpCaching>`元素控制了HTTP緩存控制頭（HTTP cache control headers）。不要將這些設置和Solr內部的緩存配置混淆。這個元素控制了W3C HTTP規格定義的HTTP響應的緩存過程。這個元素容許三個屬性和一個下級元素。
 `<httpCaching>`元素的屬性決定了是否容許對一個GET請求進行304響應，若是能夠，它應該是什麼響應類別（sort）。當一個HTTP用戶程序生成一個GET請求，若是資源從上一次被取得後尚未被修改，那麼它能夠可選擇地指定一個可接受的304響應。

 never304
 若是將這個值設置爲true，那麼即便請求的資源尚未被修改，一個GET請求也永遠不會獲得一個304響應。若是這個屬性被設置爲true，那麼接下來的兩個屬性會被忽略。將這個屬性設置爲true對於開發來講是方便的，由於當經過支持緩存頭的web瀏覽器或者其餘用戶修補Solr的響應時，304響應可能會令人混淆。

 lastModFrom 這個屬性能夠設置爲openTime（默認值）或者dirLastMod。openTime指示了最後更改時間，相對於客戶發送的If-Modified-Since頭，
 它應該在搜索器開始的時候計算。若是當索引在硬盤上更新時你須要精確同步，那麼使用dirLastMod。

 etagSeed
 這個屬性的值被做爲ETag頭的值。改變這個值能夠有助於強制用戶從新取得內容，即便索引沒有被改變。例如，當你修改了配置的時候。

 `<httpCaching never304="false"
 lastModFrom="openTime"
 etagSeed="Solr">
 <cacheControl>max-age=30, public</cacheControl>
 </httpCaching>`

10 requestHandler（請求處理器）
提供了相似webservice的功能，能夠經過http請求solr搜索
Configuration
<requestHandler name="/select" class="solr.SearchHandler"> <lst name="defaults"> <str name="echoParams">explicit</str> <int name="rows">10</int> //顯示數量- <str name="df">text</str> //默認搜索字段 </lst>

`<requestHandler name="/query" class="solr.SearchHandler">
   <lst name="defaults">
     <str name="echoParams">explicit</str>
     <str name="wt">json</str>     //顯示格式
     <str name="indent">true</str>
     <str name="df">text</str>
   </lst>
  </requestHandler>`

   這些參數定義了須要返回多少結果（定義值爲10），經過參數df定義了搜索的域默認爲「text」域。echoParams參數定義了查詢中的在調試信息返回的客戶端請求中的參數。
   另外還要注意在列表中這些默認值定義方法的 變化：當參數是String，integer或其餘類型時，定義類型是不一樣的。

   更多信息，請查看https://wiki.apache.org/solr/CoreQueryParameters?action=fullsearch&context=180&value=echoParams&titlesearch=Titles

   全部這些在搜索部分描述的參數能夠在任何SearchHandlers中定義爲默認值（這些參數的細節信息請參考搜索部分）

   除了這些默認值，還有一些選擇可用於SearchHandler，包括了下面的這些內容：

   appends：這個設置容許在用戶查詢中添加參數的定義。這些參數多是過濾查詢，或者其餘能夠被加入每個查詢的查詢規則。在Solr中沒有機制容許客戶端覆蓋這些添加，因此你應當肯定你老是須要在查詢中加入這些參數。

    `<lst name="appends">
     <str name="fq">inStock:true</str>
    </lst>`

   在這個例子中，過濾查詢「inStock:true」會添加到每個查詢上。

   Invariants：這個設置容許定義不會被客戶端覆蓋的參數。在invariants部分定義的值老是會被使用，而不考慮用戶或客戶端默認的或添加的值。

     `<lst name="invariants">
     <str name="facet.field">cat</str>
     <str name="facet.field">manu_exact</str>
     <str name="facet.query">price:[* TO 500]</str>
     <str name="facet.query">price:[500 TO *]</str>
     </lst>`

   在這個例子中，facet域被定義，這個定義會限制Solr返回的facets。若是客戶端請求facets，那麼他們只會看到和這個配置的相同的facets。

   在request handler最後部分，是組件（component）的定義，它定義了能夠被用於一個request

   Handler的搜索組件的列表。它們僅在request handler中註冊。對搜索組件的更進一步的討論在搜索組件部分。搜索組件元素只能被用於SearchHandler。

   Handler Resolution

   客戶端能夠經過帶有「gt」這個參數的「/select/ url」請求，也能夠經過在solrconfig.xml配置的方式來決定要訪問的SolrRequestHandler。

   Solr是經過下面的步驟去選擇一個handler並處理請求的.....
   尋找name屬性跟請求中的qt參數匹配的handler
   尋找在配置文件中「default=true」的handler
   尋找在配置文件中name屬性爲「standad」的handler
   使用StandardRequestHandler的默認實例

   若是你的配置文件solrconfig.xml 包含有name屬性爲"/select", "/update", 或"/admin"，那麼你的程序將不會沿用標準的請求處理過程，而將會是你本身自定義的邏輯。

   擴展本身的Handler

   實現一個SolrRequestHandler 最簡單的方法是去擴展 RequestHandlerBase 類。
   更多信息，請參考http://wiki.apache.org/solr/SolrRequestHandler#head-3dfff37b7cc549669ba241eb6050ffdbc80d7e78