目錄

• 1 solrconfig.xml文件詳細說明
  • 1.1 lib標簽配置擴展jar包
  • 1.2 dataDir標簽指定data目錄
  • 1.3 indexConfig標簽配置索引
  • 1.4 query標簽配置查詢處理
  • 1.5 requestHandler標簽

1 solrconfig.xml文件詳細說明

solrconfig.xml文件位於SolrCore的conf目錄下, 通過solrconfig.xml可以配置SolrCore實例的相關信息, 可不作修改.
企業項目開發中需要修改三個常用的標簽: lib標簽、datadir標簽、requestHandler標簽.

1.1 lib標簽配置擴展jar包

solrconfig.xml中可以加載一些擴展的jar包.
擴展步驟:

• 首先要擴展的jar包復制到指定目錄, 這裏將其復制到SolrHome同級目錄, 防止項目移動時遺忘了這些jar包, 導致項目出錯(當然若有多個SolrHome, 可將這些jar包放置在SolrHome的上級目錄, 如此就不必在每個SolrHome中添加這些jar包了, 從而下述路徑也就無需修改了);

• 復制solr解壓文件中的contrib和dist目錄到work目錄下(與SolrHome同級, 為了後期搭建集群時共用這些Jar包, 而不用每次都添加);

• 修改solrconfig.xml文件, 加載擴展的jar包:

  solr.install.dir表示${SolrCore}的目錄位置, 這裏即為collection1內部; ./ 表示當前目錄; ../ 表示上一級目錄. 需作如下修改:
  

  

1.2 dataDir標簽指定data目錄

配置SolrCore的data目錄.

data目錄用來存放SolrCore的索引文件和tlog日誌文件.

solr.data.dir表示${SolrCore}/data的目錄位置.

建議不作修改, 否則配置多個SolrCore時容易出錯.

1.3 indexConfig標簽配置索引

• 索引配置很多都使用了默認配置, 其中mainIndex定義了Solr處理索引的一些選項:

  ? (1) useCompoundFile: 通過將很多Lucene內部文件整合到一個文件, 來減少使用Lucene內部文件的數量, 這有助於減少Solr使用文件句柄的數目, 代價是降低了性能. 除非應用程序用完了文件句柄, 否則默認值false就可以了;

  ? (2) mergeFacor: 決定Lucene段被合並的頻率, 值越小(最小為2)頻率越低使用的內存較少但導致的索引時間也更慢; 較大的值可使索引時間變快但會犧牲較多的內存(典型的時間與空間的平衡配置);

  ? (3) maxBufferedDocs: 在合並內存中文檔和創建新段之前, 定義所需索引的最小文檔數. 段是用來存儲索引信息的Lucene文件, 較大的值可使索引時間變快但會犧牲較多內存;

  ? (4) maxMergeDocs: 控制可由Solr合並的Document的最大數量, 較小的值(<10,000)最適合於具有大量更新的應用程序;

  ? (5) maxFieldLength: 對給定的Document, 控制可添加到Field的最大條目數, 進而截斷該文檔. 如果文檔很大, 就需要增加這個數值. 該值設置得過高會導致內存不足異常;

  ? (6) unlockOnStartup: 告知Solr忽略在多線程環境中用來保護索引的鎖定機制. 某些情況下, 索引可能會由於不正確的關機或其他錯誤而一直被鎖定, 這將妨礙添加和更新操作. 將其設置為true可以禁用啟動索引, 進而允許進行添加和更新.

1.4 query標簽配置查詢處理

• query標記段中與緩存無關的特性:

  ? (1) maxBooleanClauses: 定義可組合在一起形成一個查詢的子句數量的上限, 1024已經足夠. 如果應用程序大量使用了通配符或範圍查詢, 增加這個限制能避免當值超出時的TooMangClausesException異常;

  ? (2) enableLazyFieldLoading: 如果應用程序只會檢索Document上少數幾個Field, 就可將這個屬性設置為true. 懶加載大都發生在應用程序返回一些列的搜索結果時, 用戶常常會單擊其中的一個來查看存儲在此索引中的原始文檔, 初始往往只需要顯示很短的一段信息. 若檢索大型的Document, (除非必需)應該避免加載整個文檔.

• query部分負責定義與在Solr中發生的時間相關的選項:

  ? Solr(實際是Lucene)使用稱為Searcher的Java類來處理Query實例, 該類將與索引相關的數據加載到內存中, 根據索引、CPU及內存的大小, 這個過程可能需要較長的一段時間. 要改進這一設計和顯著提高性能, Solr引入了一種”預熱”策略, 即把這些新的Searcher聯機以便為現場用戶提供查詢服務之前, 先對它們進行"熱身".

  ? 可使用newSearcher和firstSearcher等事件來指定在實例化newSearcher或firstSearcher時應該執行的查詢. 如果應用程序期望請求某些特定的查詢, 在創建newSearcher或firstSearcher時就應該反註釋這些部分並執行適當的查詢.

• query中的智能緩存:

  ? (1) filterCache: 通過存儲一個匹配給定查詢文檔的id的無序集合, 過濾器能有效提高Solr的查詢性能. 緩存這些過濾器, Solr重復調用時將會在緩存的結果集中快速查找. 更常見的場景是緩存一個過濾器, 然後再發起後續的精確查詢, 這種查詢能使用過濾器來限制要搜索的文檔數;

  ? (2) queryResultCache: 為查詢、排序條件和所請求文檔的數量緩存文檔id的有序集合;

  ? (3) documentCache: 緩存Lucene Document, 使用內部Lucene文檔的id(以便和Solr的id相區分). 由於Lucene的內部Document id會因索引操作而更改, 這種緩存不能自熱;

  ? (4) Named caches: 命名緩存是用戶定義的緩存, 可被 Solr定制插件所使用.

  其中filterCache、queryResultCache、Named caches(如果實現了 org.apache.solr.search.CacheRegenerator)可以自熱.

  • 每個緩存聲明都只接受最多四個屬性:

    class: 緩存實現的Java全限定名;

    size: 最大的條目數;

    initialSize: 緩存的初始大小;

    autoWarmCount: 是取自舊緩存以預熱新緩存的條目數, 條目多就意味著緩存的hit會更多, 需要更長的預熱時間.

  • 對所有緩存模式而言, 在設置緩存參數時, 都有必要在內存、CPU和磁盤訪問之間進行均衡. 統計信息管理頁(管理員界面的Statistics)對分析緩存的hit-to-miss比例以及微調緩存大小等統計數據都非常有用.

  • 並非所有應用程序都會從緩存受益, 實際上一些應用程序反而會由於”將某個永遠用不到的條目存儲在緩存中”這一額外步驟而受到影響.

1.5 requestHandler標簽

requestHandler請求處理器, 定義了索引和搜索的訪問方式.

• 通過 /select 搜索索引:
  
  設置搜索參數完成搜索. 搜索參數也可以設置默認值, 如下:

  <requestHandler name="/select" class="solr.SearchHandler">
      <!-- 設置默認的參數值, 可在請求地址中修改這些參數 -->
      <lst name="defaults">
          <str name="echoParams">explicit</str>
          <int name="rows">10</int>     <!-- 顯示數量 -->
          <str name="wt">json</str>     <!-- 顯示格式 -->
          <str name="df">text</str>     <!-- 默認搜索字段 -->
      </lst>
  </requestHandler>

• 通過 /update 維護索引, 可以完成索引的添加、修改、刪除操作.
  

版權聲明

作者: ma_shoufeng(馬瘦風)

出處: 博客園 馬瘦風的博客

您的支持是對博主的極大鼓勵, 感謝您的閱讀.

本文版權歸博主所有, 歡迎轉載, 但未經博主同意必須保留此段聲明, 且在文章頁面明顯位置給出原文鏈接, 否則博主保留追究法律責任的權利.

Solr02-solrconfig.xml文件詳細說明