Solr學術索引應用顯身手

文/曾彪

華中科技大學圖書館累積的各種元數據總量接近1億條。學校結合S o l r開發了學術搜索系統，從而能夠充分利用這些元數據。

華中科技大學圖書館在資源整合方面做了大量的元數據收集工作，累積的各種元數據總量接近1億條，為了充分利用這些元數據，我們結合S o l r開發了學術搜索系統（當前在http://www.libsou.com 上運行）。

安裝配置四步曲

Solr是一款非常優秀的全文搜索引擎組件，對千萬級別的數據搜索速度能達到毫秒級別，Solr在2010 年7 月發布了1.41版。

Solr可以在Tomcat、Jetty、Resin等平臺下運行，學術搜索的運行環境為：Windows2008 R2 x64位、Solr 1.41版、Java 1.6 x64位、Tomcat 6.0.24 x64位（考慮到對32G內存的充分利用，在配置環境時選擇了64位的運行環境）。

我們通過以下步驟配置S o l r的運行環境：

1.安裝配置Tomcat和Java運行環境，并調整了Tomcat 的最大和最小的內存值。-Xmx30524M -Xms25524M，在Tomcat 中配置solr.home，設置為Java 的系統參數-Dsolr.solr.home=d:solr。

2.解壓縮Solr，將Solr發布包中的examplesolr目錄復制到其他目錄（d:solr），修改$SOLR_HOME/conf/solrconfig.xml，找到dataDir設置：修改為索引存放的目錄，默認為，修改為：

r.data.dir:./solr}修改為：

。

3.將apache-solr-1.4.1.war部署到Tomca t 之下，并且可以將這個w a r 復制到tomcatwebapps的目錄下。

4.修改Tomcat的server.xml文件(防止出現亂碼)，設置URIEncoding為UTF-8：

redirectPort="8443" URIEncoding="UTF-8" />

增加tomcatconfCatalinalocalhostsolr.xml文件，其內容為：

Solr 主要是通過schema. xml 和solrConfig.xml 這兩個XML 文件來完成配置，solrconfig.xml文件包含了大部分的參數，用來配置Solr的緩存、索引路徑、查詢參數、查詢相關的事件監聽器、更新處理等，與Solr運行相關的參數都可以通過這個文件來配置。schema.xml相當于數據表配置文件，它定義了加入索引的數據的數據類型，主要包括types、fields和其他的一些缺省設置。該文件中配置的字段與索引字段的名稱與屬性一致，例：

中文分詞提高搜索準確性

在中文搜索中，中文分詞的加入可以提高搜索的準確性。中文不同于西文，詞匯之間沒有明顯的分界，但是計算機自然語言處理是按詞匯來進行分析的，因此中文分詞的效果好壞直接影響中文檢索和自然語言處理的準確性。當前開源的分詞組件有：

1.ICTCLAS3.0分詞速度單機是996KB/s，分詞精度為98.45%，API 不超過200KB，各種詞典數據壓縮后不到3M。ICTCLAS 全部采用C/C++編寫，支持Linux、FreeBSD及Windows系列操作系統，支持C/C++、C#、Delphi、Java等主流的開發語言。

2.IKAnalyzer是一個開源的分詞項目，它是基于Java 語言開發的輕量級的中文分詞工具包。結合詞典分詞和文法分析算法的中文分詞組件。最新版本IKAnalyzer3.2.3 ，獨立于Lucene 項目，同時提供了對Lucene、Solr的默認優化實現。。

3.Paoding提供Lucene和Solr 接口，具有極高的效率和高擴展性， 引入隱喻，采用完全的面向對象的設計。

4.MMSeg 提供Lucene 和Solr 接口，MMSeg 算法實現中文分詞器，并實現Lucene的 analyzer和Solr的TokenizerFactory。中文分詞器可以在在Lucene 和Solr 中使用。MMSeg 算法有兩種分詞方法：Simple 和Complex，它們都是基于正向最大匹配。Complex 增加了4 個規則過濾。

5.imdict-chinese-analyzer：算法基于隱馬爾科夫模型(Hidden Markov Model，H M M ) ，是中國科學院計算技術研究所的ictclas 中文分詞程序的重新實現（基于Java），可以直接為Lucene搜索引擎提供簡體中文分詞支持。

Solr在建立索引進行搜索時都用到了中文分詞組件，我們選擇IKAna lyzer作為學術搜索的分詞工具。

在設計好數據庫和檢索字段后，可以通過S o l r提供的導入功能，將我們需要進行搜索的數據導入到S o l r中，S o l r會生成索引文件。這種方式雖然方便，但是不靈活。在學術搜索的排序中，要將最相關的、最值得閱讀的、最新的、引用頻次高的學術文獻排到最前面，而S o l r在建立索引的過程中對文獻的評分不能有效地控制，我們選擇了在L u c e n e的基礎上開發索引程序，從而生成索引以供S o l r使用。

調用Solr搜索

在完成上面的工作后，調用S o l r搜索就很容易了，通過h t t p發送指定的搜索參數，S o l r就能返回X M L或者j o s n的結果。

搜索語法

Solr查詢的格式如下：

http://localhost:8983/solr/select/?facet.limit=10&rows=10&start=0&facet=true&q=content:java&mlt.count=15&mlt=true&mlt.fl=title&mlt.mintf=1&hl.fl=title,content&facet.field=type,year&mlt.mindf=1&hl=true

以上參數表示：在content中查詢關鍵詞為java的記錄，返回前面10條記錄，并且按照type和year進行查詢結果的分組。

Solr 常用的查詢參數如下：

q:查詢字符串；

fl:指定返回哪些字段內容，用逗號或空格分隔多個內容；

start:返回第一條記錄在完整找到結果中的偏移位置，從0開始，一般用于分頁；

rows:指定返回記錄條數的上限，配合start來實現分頁；

sort:對指定字段的排序，格式是year desc, year asc，默認是相關性降序；

fq（filter query）: 過濾查詢；

qt（query type）: 指定某個類型，用來處理查詢請求，默認是standard；

indent:返回的結果是否縮進，默認關閉，用indent=true|on 開啟，一般調用json，php，phps，ruby輸出才有必要用這個參數；

version:查詢語法的版本，建議不使用它，由服務器指定默認值。

分組

按照指定的字段分組檢索是Solr的一項特性，目前有很多搜索引擎提供這項功能。在設計好分組字段后，建立索引時必須將需要分組的字段設置為Field.Index.NOT_ANALYZED。人們可以同時按照多個字段進行分組。在提交給Solr的參數中，facet.field用來確定需要分組的字段，facet.limit用來確定返回前分組數據的條數。

排序

學術搜索除了有海量的數據和高效的搜索引擎外，優秀的排序算法也非常重要，在互聯網搜索引擎中，人們大多采用Pagerank來排序。Lucene中組合使用了信息檢索的向量空間模型和布爾模型。下面是Lucene的評分公式：

score(q,d) = coord·queNorm(q)…

∑（tf(t in d) ·idf(t)2t.getBoost() ·norm(t,d)）

t inq其中：

tf(t in d)：詞條t在文檔d中出現的詞頻；

idf( t )：詞條t在文檔中的倒排詞頻；

boost(t.field in d)：在索引過程中設置的字段參數；

lengthNorm(t.field in d)：字段的標準化值，表明在字段中存儲了多少詞條，這個數值是在索引過程中計算出來的，并且也存儲在索引中；

coord(q, d)：協調因子，它的計算是基于文檔d中所包含的所有可供查詢的詞條數量；

queryNorm(q) ：在給出每個查詢條目的方差和后，計算某查詢的標準化值。

學術搜索在設計排序時結合了3個方面的內容：

1.L u c e n e本身的評分機制，學術搜索綜合時間、類型、引用次數、是否核心期刊、是否基金項目等因素，通過d o c.S e t B o o s t(f)來給記錄評分。

2.在搜索時，對標題、關鍵詞、文摘分別給不同的權重t i t l e^2 k e y w o r d^ c o n t e n t。

3.分析檢索詞的詞性及分類屬性，對應的分類文獻給予較高的權重。

改進效率軟硬兼施

我們有多種方式來提高Solr搜索效率與并發數，比如用更快的C P U、采取S S D硬盤或者S A S 1 5 K r a i d 0 的方式能大幅提高硬盤的讀取效率、使用大內存虛擬硬盤來存放索引文件。

我們除了從硬件方面改善Solr性能之外，還可以采用其他方式來改善其性能。

多級緩存策略

在建立索引完成之后，我們很難對索引結構作出較大改動，而緩存能大幅度提高搜索服務的性能，所以我們可以采用多級緩存的策略來提高Solr的并發性能和搜索性能。

Solr中有如下幾種類型的緩存：

1.SolrCache緩存

Solr提供了兩種SolrCache接口實現類：solr.search.LRUCache(LRU = 最近最少使用內存中)和solr.search.FastLRUCache(FastLRUCache在1.4版本中引入的)，后者速度在普遍意義上要比LRUCache更快。LRUCache和FastLRUCache都使用了現成的Map來維護數據，不同點是如何來淘汰數據。

2.過濾器緩存（filterCache）

filterCache存儲了無序的文檔編號列表（lucene document id集合）。filterCache主要用在查詢過濾、查詢結果分組、進行排序，在查詢參數使用fq、facet的應用中，對filterCache的調優使得性能的改善效果明顯。通過監控搜索服務器的緩存命中率來調整參數，從而獲取更好的效果。

3.查詢結果緩存（queryResultCache）

queryResultCache是對查詢結果的緩存（SolrIndexSearcher中的Cache緩存的都是document id set），這里的結果就是完全有序的結果。

4.對象緩存（documentCache）

在Lucene中，Documen是一個需要進行索引的“單元”，一個Document由多個字段組成，類似數據庫中的一條記錄。documentCache用來保存，要注意document中存儲的字段的多少，避免大量的內存消耗。

5.自定義緩存（User/Generic Caches）

Solr支持自定義Cache，只需要實現自定義的regenerator即可，下面是配置示例：

warmCount="4096"regenerator="myrRege nerator"/>-也可以使用memcached來替代Solr提供的緩存方式，這樣能獲得分布式緩存支持。

分布式搜索與索引

當索引越來越大，單臺服務器無法滿足搜索需求時，可以采取分布式搜索與索引來提高搜索效率：將原來大的索引文件，分隔為多個小索引文件，分發到多臺S o l r搜索服務器上面，客戶端通過一次搜索多臺服務器，S o l r將從多臺服務器返回的結果合并，然后返回給客戶端。分布式搜索可以大幅度提高S o l r的并發處理能力。

需要注意的是要增大容器http處理線程數來防止阻塞，分布式搜索會加大http的請求數目，如果http容器沒有多余的線程處理請求，servlet容器就會阻塞剛來的請求，這種情況一直持續到正在處理的請求被處理完畢。

與分布式搜索相同，當需要索引的數據量非常大或者對數據的實時性要求比較高時，可以通過分布式索引來提供索引速度。在實施分布式索引中，索引的文檔必須有一個唯一鍵，至于如何建立小索引，這點隨用戶的喜好而定。關于如何決定哪條記錄放在哪個索引上，我們可以使用類似這樣的公式：uniqueId.hashCode() % numServers。

監控性能

LucidGaze for Solr 是由 Lucid 開發的開源 Solr 監測工具，該工具提供了快照、存儲、交互視圖、比較各種Solr 性能指標等功能，用5個不同的監視器來搜集統計數據，具體如下：

1.分析統計數據：Analyzer、TokenFilter、TokenStream和Tokenizer相關數據，以及哪一個Analyzer被用來為特定域產生TokenStream。

2.文檔統計數據：已建索引文檔的總數，索引的各個域。

3.索引統計數據: IndexReader和IndexWriter的活動和行為，比如查看每個實例、跟蹤每個相關方法的調用、查看緩存及內存使用情況和索引增加和提交的平均時間。

4.搜索統計數據：查詢操作、搜索器性能和處理時間、方法調用統計以及對大多常用執行的查詢。

5.存儲統計數據: Lucene存儲架構的目錄實例（directory instance）。