solr全文檢索

1.修改 example項目的web.xml文件 修改solrhome 的路徑。

2 修改solrhome中collection/conf/data-config.xml 配置數據源 數據查詢語句 配置字段在solr中的標識 

3 修改solrhome中collection/conf/schema.xml 。

schema.xml，這個至關於數據表配置文件，它定義了加入索引的數據的數據類型的。
主要包括types、fields和其餘的一些缺省設置。
注:schema.xml裏有一個uniqueKey,的配置，這裏將id字段做爲索引文檔的惟一標識符，很是重要。

<uniqueKey>id</uniqueKey>

 

1.1. FieldType（類型）

首先須要在types結點內定義一個FieldType子結點，包括name,class,positionIncrementGap等等一些參 數，name就是這個FieldType的名稱，class指向org.apache.solr.analysis包裏面對應的class名稱，用來定義 這個類型的行爲。

在FieldType定義的時候，最重要的就是定義這個類型的數據在創建索引和進行查詢的時候要使用的分析器analyzer，包括分詞和過濾。

例如：

<fieldType name="text" class="solr.TextField" positionIncrementGap="100">
      <analyzer type="index">
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <!-- in this example, we will only use synonyms at query time
        <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
        -->
        <!-- Case insensitive stop word removal.
             enablePositionIncrements=true ensures that a 'gap' is left to
             allow for accurate phrase queries.
        -->
        <filter class="solr.StopFilterFactory"
                ignoreCase="true"
                words="stopwords.txt"
                enablePositionIncrements="true"
                />
        <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt"/>
        <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
      </analyzer>
     ……
    </fieldType>

在index的analyzer中使用 solr.WhitespaceTokenizerFactory這個分詞包，就是空格分詞。

而後使用 solr.StopFilterFactory，solr.WordDelimiterFilterFactory，solr.LowerCaseFilterFactory，solr.EnglishPorterFilterFactory，solr.RemoveDuplicatesTokenFilterFactory 這幾個過濾器。

在向索引庫中添加text類型的索引的時候，Solr會首先用空格進行分詞，而後把分詞結果依次使用指定的過濾器進行過濾，最後剩下的結果纔會加入到索引庫中以備查詢。

Solr的analysis包並無帶支持中文分詞的包。

 

1.2. Fields（字段）

接下來的工做就是在fields結點內定義具體的字段（相似數據庫中的字段），就是filed。

filed定義包括name,type（爲以前定義過的各類FieldType）,indexed（是否被索引）,stored（是否被儲存），multiValued（是否有多個值）等等。

例：
<fields>
 <field name="id" type="integer" indexed="true" stored="true" required="true" />
 <field name="name" type="text" indexed="true" stored="true" />
 <field name="summary" type="text" indexed="true" stored="true" />
 <field name="author" type="string" indexed="true" stored="true" />
 <field name="date" type="date" indexed="false" stored="true" />
 <field name="content" type="text" indexed="true" stored="false" />
 <field name="keywords" type="keyword_text" indexed="true" stored="false" multiValued="true" />
 <field name="all" type="text" indexed="true" stored="false" multiValued="true"/>
</fields>

field的定義至關重要，有幾個技巧需注意一下，對可能存在多值得字段儘可能設置 multiValued屬性爲true，避免建索引是拋出錯誤；若是不須要存儲相應字段值，儘可能將stored屬性設爲false。

 

1.3. copyField（複製字段）

 

建議創建了一個拷貝字段，將全部的全文字段複製到一個字段中，以便進行統一的檢索：
<field name="all" type="text" indexed="true" stored="false" multiValued="true"/>

並在拷貝字段結點處完成拷貝設置：

<copyField source="name" dest="all"/>
<copyField source="summary" dest="all"/>

注：「拷貝字段」就是查詢的時候不用再輸入：userName:張三 and userProfile:張三的我的簡介。

直接能夠輸入"張三"就能夠將「名字」含「張三」或者「簡介」中含「張三」的又或者「名字」和「簡介」都含有「張三」的查詢出來。

他將須要查詢的內容放在了一個字段中，而且默認查詢該字段設爲該字段就好了。

1.4. dynamicField（動態字段）

 

除此以外，還能夠定義動態字段，所謂動態字段就是不用指定具體的名稱，只要定義字段名稱的規則。

例如定義一個 dynamicField，name 爲*_i，定義它的type爲text，那麼在使用這個字段的時候，任何以_i結尾的字段都被認爲是符合這個定義的，例如：name_i，gender_i，school_i等。

schema.xml配置文件大致上就是這樣，更多細節請參見solr wiki：http://wiki.apache.org/solr/SchemaXml

 

 

 

 

 

 

2. solrConfig.xml

 

 

 

在配置方面，solrconfig.xml 文件不只指定了 Solr 如何處理索引、突出顯示、分類、搜索以及其餘請求，還指定了用於指定緩存的處理方法的屬性，以及用於指定 Lucene 管理索引的方法的屬性。

配置取決於模式，但模式不取決於配置。solrconfig.xml文件包含了大部分的參數用來配置Solr自己的。

2.1. dataDir parameter

<dataDir>/var/data/solr</dataDir>
用來指定一個替換原先在Solr目錄下默認存放全部的索引數據，能夠在Solr目錄之外的任意目錄中。

若是複製使用後應該符合該參數。若是這個目錄不是絕對路徑的話，那麼應該以當前的容器爲相對路徑。

2.2. mainIndex 

這個參數的值用來控制合併多個索引段。

<useCompoundFile>：經過將不少 Lucene 內部文件整合到單一一個文件來減小使用中的文件的數量。這可有助於減小 Solr 使用的文件句柄數目，代價是下降了性能。除非是應用程序用完了文件句柄，不然 false 的默認值應該就已經足夠。

2.3. mergeFactor

決定低水平的 Lucene 段被合併的頻率。較小的值（最小爲 2）使用的內存較少但致使的索引時間也更慢。
較大的值可以使索引時間變快但會犧牲較多的內存。

2.4. maxBufferedDocs

在合併內存中文檔和建立新段以前，定義所需索引的最小文檔數。
段 是用來存儲索引信息的 Lucene 文件。
較大的值可以使索引時間變快但會犧牲較多的內存。

2.5. maxMergeDocs

控制可由 Solr ,000) 最適合於具備合併的 Document 的最大數。
較小的值 (< 10大量更新的應用程序。
該參數不容許lucene在任何索引段裏包含比這個值更多的文檔，可是，多餘的文檔能夠建立一個新的索引段進行替換。

2.6. maxFieldLength

對於給定的 Document，控制可添加到 Field 的最大條目數，進而截斷該文檔。
若是文檔可能會很大，就須要增長這個數值。然而，若將這個值設置得太高會致使內存不足錯誤。

2.7. unlockOnStartup

unlockOnStartup 告知 Solr 忽略在多線程環境中用來保護索引的鎖定機制。
在某些狀況下，索引可能會因爲不正確的關機或其餘錯誤而一直處於鎖定，這就妨礙了添加和更新。
將其設置爲 true 能夠禁用啓動鎖定，進而容許進行添加和更新。

<mainIndex>
<!-- lucene options specific to the main on-disk lucene index -->
    <useCompoundFile>false</useCompoundFile>
    <mergeFactor>10</mergeFactor>
    <maxBufferedDocs>1000</maxBufferedDocs>
    <maxMergeDocs>2147483647</maxMergeDocs>
    <maxFieldLength>10000</maxFieldLength>
  </mainIndex>

2.8. updateHandler

這個更新處理器主要涉及底層的關於如何更新處理內部的信息。
（此參數不能跟高層次的配置參數Request Handlers對處理髮自客戶端的更新相混淆）。

<updateHandler class="solr.DirectUpdateHandler2">
<!-- Limit the number of deletions Solr will buffer during doc updating.
         Setting this lower can help bound memory use during indexing.
-->

緩衝更新這麼多的數目，設置以下比較低的值，能夠約束索引時候所用的內存
    <maxPendingDeletes>100000</maxPendingDeletes>
   

等待文檔知足必定的標準後將自動提交，將來版本能夠擴展示有的標準
    <!-- autocommit pending docs if certain criteria are met.  Future versions may expand the available
     criteria -->
    <autoCommit> 
      <maxDocs>10000</maxDocs> <!-- maximum uncommited docs before autocommit triggered -->

觸發自動提交前最多能夠等待提交的文檔數量
      <maxTime>86000</maxTime> <!-- maximum time (in MS) after adding a doc before an autocommit is triggered -->

在添加了一個文檔以後，觸發自動提交以前所最大的等待時間
    </autoCommit>

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

<query>
    <!-- Maximum number of clauses in a boolean query... can affect range
         or wildcard queries that expand to big boolean queries. 
一次布爾查詢的最大數量，能夠影響查詢的範圍或者進行通配符的查詢，藉此來擴展一個更強大的查詢。
         An exception is thrown if exceeded.
    -->
    <maxBooleanClauses>1024</maxBooleanClauses>

<query>:
控制跟查詢相關的一切東東。

 

2.8. Caching

修改這個參數能夠作爲索引的增加和變化。

<!-- Cache used by SolrIndexSearcher for filters (DocSets),
         unordered sets of *all* documents that match a query.
在過濾器中過濾文檔集合的時候，或者是一個無序的全部的文檔集合中將在在SolrIndexSearcher中使用緩存來匹配符合查詢的全部文檔。
         When a new searcher is opened, its caches may be prepopulated
         or "autowarmed" using data from caches in the old searcher.
當一次搜索被打開，它能夠自動的或者預先從舊的搜索中使用緩存數據。
         autowarmCount is the number of items to prepopulate.
autowarmCount這個值是預先設置的數值項。
  For LRUCache,
         the autowarmed items will be the most recently accessed items.
在LRUCache中，這個autowarmed 項中保存的是最近訪問的項。
       Parameters: 參數選項
         class - the SolrCache implementation (currently only LRUCache)實現SolrCache接口的類 當前僅有LRUCache
           
         size - the maximum number of entries in the cache
在cache中最大的上限值
         initialSize - the initial capacity (number of entries) of
           the cache.  (seel Java.util.HashMap)
在cache中初始化的數量
         autowarmCount - the number of entries to prepopulate from
           and old cache.
從舊的緩存中預先設置的項數。
         -->
    <filterCache
      class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="256"/>

   <!-- queryResultCache caches results of searches - ordered lists of
         document ids (DocList) based on a query, a sort, and the range
         of documents requested.  -->
查詢結果緩存
    <queryResultCache
      class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="256"/>

  <!-- documentCache caches Lucene Document objects (the stored fields for each document).
documentCache緩存Lucene的文檔對象（存儲領域的每個文件）
       Since Lucene internal document ids are transient, this cache will not be autowarmed.  -->
因爲Lucene的內部文檔ID標識（文檔名稱）是短暫的，因此這種緩存不會被自動warmed。
    <documentCache
      class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="0"/>

    <!-- Example of a generic cache. 
一個通用緩存的列子。
These caches may be accessed by name
         through SolrIndexSearcher.getCache().cacheLookup(), and cacheInsert().
這些緩存能夠經過在SolrIndexSearcher.getCache().cacheLookup()和cacheInsert()中利用緩存名稱訪問獲得。
         The purpose is to enable easy caching of user/application level data.
這樣作的目的就是很方便的緩存用戶級或應用程序級的數據。
         The regenerator argument should be specified as an implementation
         of solr.search.CacheRegenerator if autowarming is desired.  -->
這麼作的的關鍵就是應該明確規定實現solr.search.CacheRegenerator接口若是autowarming是比較理想化的設置。
    <!--
    <cache name="myUserCache"
      class="solr.LRUCache"
      size="4096"
      initialSize="1024"
      autowarmCount="1024"
      regenerator="org.mycompany.mypackage.MyRegenerator"
      />
    -->

    <!-- An optimization that attempts to use a filter to satisfy a search.
一種優化方式就是利用一個過濾器，以知足搜索需求。
         If the requested sort does not include a score,
若是請求的不是要求包括得分的類型，filterCache 這種過濾器將檢查與過濾器相匹配的結果。若是找到，過濾器將被用來做爲文檔的來源識別碼，並在這個基礎上進行排序。
then the filterCache
         will be checked for a filter matching the query.  If found, the filter
         will be used as the source of document ids, and then the sort will be
         applied to that.
      -->
    <useFilterForSortedQuery>true</useFilterForSortedQuery>
    <!-- An optimization for use with the queryResultCache.  When a search
         is requested, a superset of the requested number of document ids
         are collected.  For example, of a search for a particular query
         requests matching documents 10 through 19, and queryWindowSize is 50,
         then documents 0 through 50 will be collected and cached. Any further
         requests in that range can be satisfied via the cache.
    -->
一種優化用於queryResultCache，當一個搜索被請求，也會收集必定數量的文檔ID作爲一個超集。舉個例子，一個特定的查詢請求匹配的文檔是 10到19，此時，queryWindowSize是50，這樣，文檔從0到50都會被收集並緩存。這樣，任何更多的在這個範圍內的請求都會經過緩存來滿 足查詢。
    <queryResultWindowSize>50</queryResultWindowSize>
  <!-- This entry enables an int hash representation for filters (DocSets)
         when the number of items in the set is less than maxSize. For smaller
         sets, this representation is more memory efficient, more efficient to
         iterate over, and faster to take intersections.
     -->
    <HashDocSet maxSize="3000" loadFactor="0.75"/>
    <!-- boolToFilterOptimizer converts boolean clauses with zero boost
     cached filters if the number of docs selected by the clause exceeds the
         threshold (represented as a fraction of the total index)
    -->
<boolTofilterOptimizer enabled="true" cacheSize="32" threshold=".05"/>

    <!-- Lazy field loading will attempt to read only parts of documents on disk that are          requested.  Enabling should be faster if you aren't retrieving all stored fields.     -->     <enableLazyFieldLoading>false</enableLazyFieldLoading>