SolrConfig中的IndexConfig

solrconfig.xml的<indexConfig>部分定義了Lucene索引編寫器的低級行為。

默認(rèn)情況下，這些設(shè)置在Solr包含的示例solrconfig.xml中注釋掉，這意味著使用默認(rèn)值。在大多數(shù)情況下，默認(rèn)值是好的。

<indexConfig>
  ...
</indexConfig>

編寫新的段

ramBufferSizeMB

一旦累積的文檔更新超過了這么多的內(nèi)存空間（以兆字節(jié)為單位），那么待完成的更新就會被刷新。這也可以創(chuàng)建新的段或觸發(fā)合并。通常使用這個(gè)設(shè)置對于maxBufferedDocs是可取的。如果同時(shí)在solrconfig.xml中設(shè)置了maxBufferedDocs與ramBufferSizeMB的話，當(dāng)?shù)竭_(dá)任何一個(gè)限制時(shí)，就會出現(xiàn)一個(gè)刷新。默認(rèn)值是100Mb。

<ramBufferSizeMB>100</ramBufferSizeMB>

maxBufferedDocs

將文檔更新的數(shù)量設(shè)置為內(nèi)存中的緩沖區(qū)，然后再刷新為新段。這也可能觸發(fā)合并。默認(rèn)的 Solr 配置集由 RAM 使用量 (ramBufferSizeMB) 刷新。

<maxBufferedDocs>1000</maxBufferedDocs>

useCompoundFile

控制新寫入的（還沒有合并的）索引段是否應(yīng)該使用復(fù)合文件段格式。默認(rèn)值是false。

<useCompoundFile>false</useCompoundFile>

合并索引段

mergePolicyFactory

定義合并分段的完成方式。

Solr中的默認(rèn)值是使用 TieredMergePolicy，它將合并大小相同的段，并受到每層允許的段數(shù)限制。

其他可用的政策是LogByteSizeMergePolicy、LogDocMergePolicy和UninvertDocValuesMergePolicy。有關(guān)這些策略的更多信息，請參閱MergePolicy javadocs。

<mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
  <int name="maxMergeAtOnce">10</int>
  <int name="segmentsPerTier">10</int>
</mergePolicyFactory>

控制段大?。汉喜⒁蛩?a rel="external nofollow" target="_blank" >

用戶對配置TieredMergePolicy（或LogByteSizeMergePolicy）所做的最常見的調(diào)整是“合并因素”，以一次更改應(yīng)合并的段數(shù)。

對于TieredMergePolicy，這是通過設(shè)置<int name="maxMergeAtOnce">和<int name="segmentsPerTier">選項(xiàng)來控制的，而LogByteSizeMergePolicy只有一個(gè)<int name="mergeFactor">選項(xiàng)（全部默認(rèn)值為10）。

要理解這些選項(xiàng)的重要性，請考慮使用LogByteSizeMergePolicy對索引進(jìn)行更新時(shí)會發(fā)生什么情況：文檔始終添加到最近打開的段中。當(dāng)某個(gè)段填滿時(shí)，會創(chuàng)建一個(gè)新分段，并隨后進(jìn)行更新。

如果創(chuàng)建新的段會導(dǎo)致最低層段的數(shù)量超過mergeFactor值，那么所有這些段被合并在一起形成一個(gè)大的段。因此，如果合并因子為10，則每次合并都會創(chuàng)建一個(gè)單獨(dú)的段，該段大約是其十個(gè)成分中的每一個(gè)的十倍。當(dāng)有10個(gè)這些較大的段時(shí)，他們又被合并成一個(gè)更大的單個(gè)段。這個(gè)過程可以無限期地繼續(xù)下去。

當(dāng)使用TieredMergePolicy時(shí)，過程是相同的，但不是一個(gè)單一的mergeFactor值，該segmentsPerTier設(shè)置被用作閾值來決定是否應(yīng)該發(fā)生合并，并且該maxMergeAtOnce設(shè)置確定合并中應(yīng)該包括多少段。

選擇最佳的合并因素通常是索引速度與搜索速度的權(quán)衡。在索引中有更少的段通常會加速搜索，因?yàn)椴檎业奈恢酶?。它也可以?dǎo)致磁盤上的物理文件更少。但是為了保持低段的數(shù)量，合并會更頻繁地發(fā)生，這會給系統(tǒng)增加負(fù)載并且減慢對索引的更新。

相反，保留更多的段可以加快索引，因?yàn)楹喜l(fā)生的次數(shù)少，使得更新不太可能觸發(fā)合并。但是搜索的計(jì)算成本更高，并且可能會變慢，因?yàn)樗阉鳁l件必須在更多的索引段中查找。更快的索引更新也意味著更短的提交周轉(zhuǎn)時(shí)間，這意味著更及時(shí)的搜索結(jié)果。

定制合并策略

如果內(nèi)置合并策略的配置選項(xiàng)不完全適合您的用例，則可以對它們進(jìn)行自定義：通過創(chuàng)建您在配置中指定的自定義合并策略工廠，或者配置使用wrapped.prefix配置選項(xiàng)用于控制將如何配置其包裝的工廠：

<mergePolicyFactory class="org.apache.solr.index.SortingMergePolicyFactory">
  <str name="sort">timestamp desc</str>
  <str name="wrapped.prefix">inner</str>
  <str name="inner.class">org.apache.solr.index.TieredMergePolicyFactory</str>
  <int name="inner.maxMergeAtOnce">10</int>
  <int name="inner.segmentsPerTier">10</int>
</mergePolicyFactory>

上面的例子顯示了 Solr 的 SortingMergePolicyFactory 被配置為通過 "timestamp desc" 對合并段中的文檔進(jìn)行排序，并將 TieredMergePolicyFactory 配置為使用 maxMergeAtOnce=10 和 segmentsPerTier=10 的值，通過SortingMergePolicyFactory的wrapped.prefix選項(xiàng)定義的inner前綴。有關(guān)使用 SortingMergePolicyFactory 的詳細(xì)信息, 請參閱 segmentTerminateEarly 參數(shù)。

mergeScheduler

合并調(diào)度程序控制如何執(zhí)行合并。默認(rèn)ConcurrentMergeScheduler使用單獨(dú)的線程在后臺執(zhí)行合并。替代方法是SerialMergeScheduler，不執(zhí)行與單獨(dú)線程的合并。

<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/>

mergedSegmentWarmer

使用Solr進(jìn)行近實(shí)時(shí)搜索合并段時(shí)，可以配置為在合并提交之前在新合并的段上預(yù)熱讀取器。這對于近乎實(shí)時(shí)的搜索并不是必需的，但是在合并完成之后將減少在打開新的近實(shí)時(shí)閱讀器時(shí)的搜索延遲。

<mergedSegmentWarmer class="org.apache.lucene.index.SimpleMergedSegmentWarmer"/>

復(fù)合文件段

每個(gè)Lucene段通常由十幾個(gè)文件組成?？梢詫ucene配置為將一個(gè)段的所有文件打包成單個(gè)復(fù)合文件，其文件擴(kuò)展名為.cfs；它是復(fù)合文件段的縮寫。

由于各種原因，CFS 段可能會受到輕微的性能影響，具體取決于運(yùn)行時(shí)環(huán)境。例如，文件系統(tǒng)緩沖區(qū)通常與打開的文件描述符關(guān)聯(lián)，這可能會限制每個(gè)索引可用的總緩存空間。

在每個(gè)進(jìn)程允許的打開文件數(shù)量有限的系統(tǒng)上，CFS可能會避免達(dá)到該限制。打開的文件限制也可以通過Linux / Unix ulimit命令對您的操作系統(tǒng)進(jìn)行調(diào)整，或者其他操作系統(tǒng)的類似操作。

注意：CFS: 新段與合并段：要配置新寫入的段是否應(yīng)使用 CFS, 請參閱上面描述的 useCompoundFile 設(shè)置。要配置合并段是否使用 CFS, 請查看 mergePolicyFactory 的 Javadocs。

許多合并策略實(shí)現(xiàn)都支持 noCFSRatio 和 maxCFSSegmentSizeMB 設(shè)置, 并使用默認(rèn)值防止復(fù)合文件被用于大段, 但對于小段, 也要用復(fù)合文件。

索引鎖

鎖定類型

LockFactory選項(xiàng)指定要使用的鎖定實(shí)現(xiàn)。

這組有效的鎖定類型選項(xiàng)取決于您配置的DirectoryFactory。以下列出的值受StandardDirectoryFactory（默認(rèn)）支持：

• native（默認(rèn)）使用NativeFSLockFactory指定本機(jī)操作系統(tǒng)文件鎖定。如果第二個(gè)Solr進(jìn)程試圖訪問該目錄，它將會失敗。當(dāng)多個(gè)Solr Web應(yīng)用程序試圖共享單個(gè)索引時(shí)，請勿使用它們。
• simple 使用 SimpleFSLockFactory 指定一個(gè)純文件進(jìn)行鎖定。
• single（專家）使用SingleInstanceLockFactory。用于只讀索引目錄的特殊情況，或者當(dāng)不可能有多個(gè)進(jìn)程嘗試修改索引（甚至是連續(xù)的）時(shí)。這種類型將防止同一個(gè) JVM 內(nèi)的多個(gè)內(nèi)核試圖訪問相同的索引。警告！如果不同JVM中的多個(gè)Solr實(shí)例修改索引，則此類型不會防止索引損壞。
• hdfs使用HdfsLockFactory支持將索引和事務(wù)日志文件讀寫到HDFS文件系統(tǒng)。有關(guān)使用此功能的更多詳細(xì)信息，請參閱HDFS上的運(yùn)行Solr部分。

有關(guān)每個(gè)LockFactory的細(xì)微差別的更多信息，請參閱http://wiki.apache.org/lucene-java/AvailableLockFactories。

<lockType>native</lockType>

writeLockTimeout

在IndexWriter上等待寫入鎖定的最長時(shí)間。缺省值是1000，以毫秒表示。

<writeLockTimeout>1000</writeLockTimeout>

其他索引設(shè)置

還有一些其他參數(shù)可能對您的實(shí)現(xiàn)配置很重要。這些設(shè)置會影響對索引進(jìn)行更新的方式或時(shí)間。

• reopenReaders
  

  控制是否重新打開IndexReader，而不是關(guān)閉然后打開，這通常效率較低。默認(rèn)值是true。

• deletionPolicy
  

  控制在回滾情況下如何保留提交。默認(rèn)值是SolrDeletionPolicy，其中有最大提交數(shù)量（maxCommitsToKeep）的子參數(shù)，要保留的最優(yōu)化提交數(shù)（maxOptimizedCommitsToKeep），以及任何提交保留（maxCommitAge）的最大保留期限，它支持DateMathParser語法。

• infoStream
  

  InfoStream設(shè)置指示底層Lucene類從索引過程中編寫詳細(xì)的調(diào)試信息作為Solr日志消息。

<reopenReaders>true</reopenReaders>
<deletionPolicy class="solr.SolrDeletionPolicy">
  <str name="maxCommitsToKeep">1</str>
  <str name="maxOptimizedCommitsToKeep">0</str>
  <str name="maxCommitAge">1DAY</str>
</deletionPolicy>
<infoStream>false</infoStream>