吳潔明，韓云輝，冀單單

（北方工業(yè)大學(xué)信息工程學(xué)院，北京 100144）

1 引言

中國(guó)版權(quán)保護(hù)中心在深入研究國(guó)際現(xiàn)有的版權(quán)保護(hù)技術(shù)、相關(guān)的法規(guī)和標(biāo)準(zhǔn)后，認(rèn)為從根本上解決數(shù)字作品產(chǎn)業(yè)鏈中各個(gè)參與者的利益分享和技術(shù)創(chuàng)新，實(shí)現(xiàn)快速高效的維權(quán)機(jī)制，是互聯(lián)網(wǎng)版權(quán)保護(hù)的核心命題[1]。中國(guó)版權(quán)保護(hù)中心結(jié)合數(shù)字資源出版服務(wù)領(lǐng)域的發(fā)展趨勢(shì)，對(duì)數(shù)字資源登記、備案和檢索進(jìn)行了深入的研究分析，解決數(shù)字作品存儲(chǔ)和搜索問(wèn)題，提出了要對(duì)數(shù)字作品進(jìn)行登記、備案和審核，并對(duì)其提供快速搜索服務(wù)。

據(jù)IDC（互聯(lián)網(wǎng)數(shù)據(jù)中心）于2010年的一則報(bào)道，2010年底全球數(shù)字信息總量將達(dá)到1.2ZB，到2020年這個(gè)數(shù)字將達(dá)到3.5ZB，其增長(zhǎng)速度超過(guò)摩爾定律[2]。針對(duì)海量的數(shù)字信息，如何對(duì)其進(jìn)行快速、準(zhǔn)確的搜索成為研究的重點(diǎn)。目前，國(guó)內(nèi)對(duì)于數(shù)字作品的研究處于初級(jí)階段，關(guān)于海量數(shù)字作品信息搜索引擎的論文也很少，本文就是圍繞這一問(wèn)題，分析設(shè)計(jì)出實(shí)現(xiàn)海量數(shù)字作品信息的專業(yè)搜索引擎。

2 搜索引擎及Lucene應(yīng)用

2.1 Lucene概述

Lucene是Apache軟件基金會(huì)的一個(gè)頂級(jí)項(xiàng)目，它不是一個(gè)完整的全文檢索系統(tǒng)，是一個(gè)高性能、可擴(kuò)展的用Java語(yǔ)言開(kāi)發(fā)的開(kāi)放源碼的全文檢索工具包，共分五個(gè)模塊，分別是：語(yǔ)料庫(kù)（Corpus）、解析（Analysis）、索引（Index）、存儲(chǔ)（Storage）和搜索（Search），每個(gè)模塊又可分為：相互協(xié)議部分和具體實(shí)現(xiàn)部分。Lucene所提供的用于索引和查詢的相關(guān)函數(shù)接口可以方便地嵌入到各類應(yīng)用系統(tǒng)中，實(shí)現(xiàn)全文索引和搜索功能[3]。Lucene最初由Doug Cutting編寫，目的是讓開(kāi)發(fā)人員以此為平臺(tái)，通過(guò)重載Searcher類、Analyzer類以及增加爬蟲系統(tǒng)等對(duì)象實(shí)現(xiàn)一個(gè)完整的搜索引擎系統(tǒng)[4]。關(guān)于Lucene的項(xiàng)目主要有：Eyebrows（郵件列表管理系統(tǒng)中的檢索和歸檔）、Jive（基于Web的論壇系統(tǒng)）和Eclipse（全文檢索部分）等。

2.2 HDFS概述

HDFS（Hadoop Distributed File System）是分布式文件系統(tǒng)，在Hadoop的系統(tǒng)中有一臺(tái)Master，主要負(fù)責(zé)NameNode的工作以及協(xié)調(diào)作業(yè)的運(yùn)行（JobTracker）。JobTracker的主要職責(zé)就是啟動(dòng)、跟蹤和調(diào)度各個(gè)Slave的任務(wù)執(zhí)行。還有多臺(tái)Slave，每臺(tái)Slave通常具有DataNode的功能并負(fù)責(zé)運(yùn)行作業(yè)劃分后的任務(wù)（TaskTracker）。TaskTracker根據(jù)應(yīng)用要求來(lái)結(jié)合本地?cái)?shù)據(jù)執(zhí)行Map任務(wù)以及Reduce任務(wù)[5]。

名稱節(jié)點(diǎn)（NameNode）：管理文件系統(tǒng)的命名空間，記錄文件系統(tǒng)樹(shù)及這個(gè)樹(shù)內(nèi)所有的文件和索引目錄，同時(shí)也記錄每個(gè)文件所在塊的數(shù)據(jù)節(jié)點(diǎn)。

數(shù)據(jù)節(jié)點(diǎn)（DataNode）：文件系統(tǒng)的工作者，存儲(chǔ)并提供定位塊的服務(wù)，并定時(shí)向名稱節(jié)點(diǎn)發(fā)送塊的存儲(chǔ)列表。

塊（Block）：是HDFS基本儲(chǔ)存邏輯單元，一個(gè)文件有可能包含多個(gè)塊，一個(gè)塊又可以包含多個(gè)文件，由文件的大小和塊大小的參數(shù)決定，Block的大小默認(rèn)為64MB，如果設(shè)置大，就會(huì)有可能導(dǎo)致Map運(yùn)行慢；設(shè)置小，有可能導(dǎo)致Map個(gè)數(shù)過(guò)多。

2.3 Map Reduce概述

Map Reduce是并行計(jì)算，一個(gè)Map Reduce作業(yè)（Job）通常會(huì)把輸入的數(shù)據(jù)集切分為若干獨(dú)立的數(shù)據(jù)塊，由Map任務(wù)（Task）以并行的方式處理任務(wù)，對(duì)Map的輸出先進(jìn)行排序，然后把結(jié)果輸入給Reduce任務(wù)。通常作業(yè)的輸入和輸出都會(huì)被存儲(chǔ)在文件系統(tǒng)中[6]。

Map方法：并行應(yīng)用于每一個(gè)輸入的數(shù)據(jù)集，每一次調(diào)用都會(huì)產(chǎn)生一個(gè)（k2，v2）的隊(duì)列，如：Map（k1，v1）→list（k2，v2）。

Reduce方法：收集Map端輸出隊(duì)列l(wèi)ist（k2，v2）中有相同key的數(shù)據(jù)對(duì)，把它們聚集在一起，輸出時(shí)形成目的數(shù)據(jù)list（k3，v3），如：Reduce（k2，list（v2））→list（k3，v3）。

2.4 搜索引擎結(jié)構(gòu)

基于Lucene的數(shù)字作品搜索引擎結(jié)構(gòu)如圖1所示，采用的技術(shù)主要包括：改進(jìn)的分詞算法、建立索引、實(shí)現(xiàn)檢索和改進(jìn)的相關(guān)度排序算法等。

Figure 1 Structure of the search engine圖1 搜索引擎結(jié)構(gòu)

如圖1所示，數(shù)字作品搜索引擎核心模塊包括：分詞處理、索引器、檢索器、結(jié)果相關(guān)度排序和索引文件等。

（1）分詞處理：對(duì)于數(shù)字作品信息采用改進(jìn)的分詞算法進(jìn)行分詞；

（2）索引器：對(duì)分詞后的數(shù)據(jù)采用倒排索引技術(shù)建立索引；

（3）檢索器：對(duì)于用戶輸入的查詢?cè)~在索引文件中檢索；

（4）結(jié)果相關(guān)度排序：將檢索后的結(jié)果按照改進(jìn)的相關(guān)度排序算法進(jìn)行排序顯示；

（5）索引文件：索引文件儲(chǔ)存在分布式HDFS文件系統(tǒng)上，采用并行計(jì)算機(jī)Map Reduce計(jì)算處理HDFS上的文件。

3 搜索引擎設(shè)計(jì)

3.1 分詞算法的改進(jìn)

西方語(yǔ)言用空格和標(biāo)點(diǎn)來(lái)分隔單詞，但是漢語(yǔ)、日語(yǔ)等亞洲文字不能通過(guò)空格來(lái)分隔，而Lucene采用中文單字和雙字分詞方法難以達(dá)到應(yīng)用需要的效果，所以需要一種有效的針對(duì)漢語(yǔ)習(xí)慣的分詞方法。目前支持中文的分析器主要有StandardAnalyzer、CJKAnalyzer、ChineseAnalyzer、IK＿CAnalyzer和ICTCLAS 等，為了能夠使得分詞器更加符合漢語(yǔ)習(xí)慣，并提高分詞的速度和精度，本文在基于統(tǒng)計(jì)、詞庫(kù)的基礎(chǔ)上，對(duì)基于前向最大匹配切分算法提出一種改進(jìn)算法。假設(shè)對(duì)文本S＝W1W2W3W4W5進(jìn)行分詞，首先讓字符指針指向文本S 的串首，根據(jù)漢語(yǔ)詞語(yǔ)分布，兩個(gè)字的詞是最多的，所以先對(duì)兩個(gè)字的詞進(jìn)行分析，算法中設(shè)定最長(zhǎng)的分詞的字長(zhǎng)為M 個(gè)字，改進(jìn)的分詞算法的流程如圖2所示。

Figure 2 Improved segmentation algorithm process圖2 改進(jìn)的分詞算法流程

則改進(jìn)后的分詞算法可描述為：

（1）指針由串首向后移兩個(gè)字，取得兩個(gè)字W1W2，在詞表中查找W1W2，并判斷以W1W2為前綴的詞的個(gè)數(shù)N，如果N 等于0，則指針向前移一個(gè)字，并將子串W1切分成詞；如果N 等于1，則將子串W1W2切分成詞。

（2）如果N 大于1，指針向后移一個(gè)字，在詞表中查找W1W2W3，并判斷以W1W2W3 為前綴的詞的個(gè)數(shù)N，如果N 等于0，則指針向前移一個(gè)字，并將子串W1W2切分成詞；如果N 等于1，則將子串W1W2W3切分成詞。

（3）如果N 大于1，類似于（2），指針向后移一個(gè)字，在詞表中查找W1W2W3W4，并判斷以W1W2W3W4為前綴的詞的個(gè)數(shù)N，如果N 等于0，則指針向前移一個(gè)字，并將子串W1W2W3切分成詞；如果N 等于1，則將子串W1W2W3W4切分成詞。

（4）如果N 大于1，類似（2）和（3），指針向后移一個(gè)字，直到得到的子串長(zhǎng)度達(dá)到最大長(zhǎng)度M 為止。

（5）重復(fù)（1）～（4）直到文本S 切分完畢為止。

3.2 索引數(shù)據(jù)結(jié)構(gòu)

Lucene倒排索引的數(shù)據(jù)結(jié)構(gòu)如圖3所示，Lucene中項(xiàng)（Term）是最小的索引單位，它直接代表了一個(gè)關(guān)鍵詞以及其在文件中的出現(xiàn)位置和出現(xiàn)次數(shù)等信息；若干的項(xiàng)組成域（Field），域是一個(gè)關(guān)聯(lián)的元組，域是由一個(gè)域名和一個(gè)域值組成，域名是一個(gè)字符串，域值是一個(gè)項(xiàng)；若干的域組成文檔（Document），文檔是提取了某個(gè)文件中的所有信息之后的結(jié)果；若干的文檔組成段（Segment），內(nèi)存中的段數(shù)量達(dá)到指定數(shù)量時(shí)（默認(rèn)為10）將會(huì)合并成一個(gè)段；若干段組成子索引（Index），子索引可以組合為索引，也可以合并為一個(gè)新的包含了所有合并項(xiàng)的內(nèi)部元素的子索引。在Lucene中采用段索引的生成方式，合并閾值（MergeFactor）影響著內(nèi)存與硬盤中索引文件的個(gè)數(shù)。每添加一個(gè)Document將生成一段索引被內(nèi)存持有，當(dāng)段索引的個(gè)數(shù)超過(guò)合并閾值時(shí)，就會(huì)通過(guò)merge（合并）的過(guò)程將一段索引合并為段索引[7]。如圖3從左到右是一個(gè)搜索順序，從右到左是一個(gè)索引的順序，這種順序就是下面將要提到的倒排索引。

Figure 3 Inverted index data structure圖3 倒排索引數(shù)據(jù)結(jié)構(gòu)

3.3 倒排索引

倒排索引是一種面向關(guān)鍵詞的索引機(jī)制，是目前對(duì)搜索引擎最常用的存儲(chǔ)方式，本文采用倒排表來(lái)組織索引，倒排表中項(xiàng)記錄某關(guān)鍵詞在文檔中的出現(xiàn)位置和出現(xiàn)次數(shù)等信息，這種由屬性值來(lái)確定記錄、而不是由記錄來(lái)確定屬性值的搜索稱之為倒排索引。倒排表的組織結(jié)構(gòu)如圖4所示[8]。

Figure 4 Index structure of inverted table圖4 倒排表的索引結(jié)構(gòu)

例如有文檔1和文檔2：

文檔1：Jim loves lucene；

文檔2：Lucene loves Tom。

首先對(duì)文檔1和文檔2提取關(guān)鍵詞，按照一般索引得到的結(jié)果如表1所示，按照Lucene倒排索引得到的結(jié)果如表2所示。由表1和表2可知，一般索引關(guān)鍵詞數(shù)量隨著文檔內(nèi)容成線性關(guān)系增長(zhǎng)，而倒排索引當(dāng)出現(xiàn)相同關(guān)鍵詞時(shí)，只需要修改相應(yīng)記錄信息，節(jié)省索引文件的存儲(chǔ)空間，提高檢索效率[9]。Lucene在具體實(shí)現(xiàn)索引時(shí)，將表2 中的關(guān)鍵詞、出現(xiàn)位置和文檔出現(xiàn)次數(shù)，在建索引時(shí)，分別保存在詞典文件、位置文件和頻率文件中。在詞典文件中同時(shí)還保存了指向位置文件和頻率文件的指針。

Table 1 General index表1 一般索引

Table 2 Inverted index表2 倒排索引

3.4 建立索引

將分詞后的數(shù)字作品信息采用倒排索引技術(shù)建立索引。如圖5是建立索引模塊，可分為如下四步：從數(shù)據(jù)源（數(shù)據(jù)庫(kù)）獲取數(shù)據(jù)、解析生成Field對(duì)象、構(gòu)建Document對(duì)象、IndexWriter建立索引。首先，從數(shù)據(jù)庫(kù)中獲取數(shù)字作品信息，針對(duì)一條數(shù)據(jù)進(jìn)行解析，取出每個(gè)字段和值，按照數(shù)據(jù)庫(kù)字段對(duì)應(yīng)Lucene域的方式生成Field對(duì)象；接著，將生成的Field 添加到Document中生成Document對(duì)象；然后，通過(guò)IndexWriter類的addDocument方法建立索引，在建立索引時(shí)，Lucene會(huì)對(duì)數(shù)據(jù)進(jìn)行分析處理；最后，直到?jīng)]有要更新的數(shù)據(jù)，則索引創(chuàng)建完成并關(guān)閉索引器。當(dāng)大量數(shù)據(jù)建索引時(shí)，在向磁盤寫入索引文件時(shí)會(huì)出現(xiàn)瓶頸，在Lucene內(nèi)存中有一塊緩沖區(qū)來(lái)解決此問(wèn)題。IndexWriter 提供了三個(gè)參數(shù)mergeFactor、min-MergeDocs、maxMergeDocs來(lái)設(shè)置緩沖區(qū)的大小和向磁盤寫索引文件的頻率。

Figure 5 Creating index module圖5 建立索引模塊

3.5 搜索模塊

Lucene提供了全面且高效的檢索功能。圖6所示是基于索引模塊來(lái)實(shí)現(xiàn)搜索模塊，可分為如下四步：解析用戶輸入的查詢關(guān)鍵詞、解析生成Query對(duì)象、IndexSearcher搜索得到Hits搜索結(jié)果、相關(guān)度排序算法顯示結(jié)果。首先，Lucene對(duì)用戶輸入的查詢關(guān)鍵詞，通過(guò)查詢分析器QueryParser進(jìn)行分詞處理，如去除多余空格；接著，QueryParser將分詞后的查詢關(guān)鍵詞生成查詢Query對(duì)象；然后，IndexSearcher對(duì)查詢Query對(duì)象進(jìn)行搜索，將搜索結(jié)果返回在Hits結(jié)果集里；最后，通過(guò)改進(jìn)的相關(guān)度排序算法將搜索結(jié)果集Hits排序顯示給用戶。Lucene完成一次搜索后，所有搜索結(jié)果不會(huì)全部顯示出來(lái)，而是將與查詢關(guān)鍵詞匹配度最高的前100條結(jié)果的ID 放在緩存中，然后返回給用戶，如果這100條不能滿足用戶需求，Lucene會(huì)再次搜索，通常會(huì)生成一個(gè)比上次大一倍的緩存。在處理大數(shù)據(jù)量的數(shù)字作品信息的時(shí)候，這種搜索技術(shù)不僅節(jié)省結(jié)果集的空間還會(huì)自動(dòng)過(guò)濾掉匹配度低的結(jié)果，從而提高搜索準(zhǔn)確率和速度。

Figure 6 Searching module圖6 搜索模塊

3.6 Lucene相關(guān)度排序算法及改進(jìn)

在信息檢索時(shí)，一般會(huì)得到很多符合條件的結(jié)果，有些結(jié)果可能并不是用戶想要的，但是用戶一般只會(huì)查看前幾十個(gè)結(jié)果，所以Lucene采用相關(guān)度排序算法對(duì)檢索結(jié)果進(jìn)行排序，將得分高的結(jié)果排在前面，得分低的排在后面。本文先介紹Lucene的相關(guān)度排序算法：

通過(guò)這個(gè)評(píng)分公式得到的是原始分?jǐn)?shù)，但是由Hits對(duì)象返回的關(guān)于某文檔的評(píng)分卻不一定是其原始得分，因?yàn)樵u(píng)分得分最高的文檔如果超過(guò)了1.0，那么接下來(lái)的所有評(píng)分都會(huì)以這個(gè)評(píng)分為標(biāo)準(zhǔn)進(jìn)行計(jì)算，因此所有Hits對(duì)象的得分都只能小于或等于1.0[10]。

所以，Lucene在相關(guān)度排序算法中，如果某文檔中含有某查詢?cè)~的次數(shù)越多，則得分越高，如果除了該查詢?cè)~之外，其他的詞越多，則得分就會(huì)越少。由此可以看出，Lucene的相關(guān)度排序算法容易受到查詢?cè)~的數(shù)量的影響，但是查詢?cè)~在某文檔中的出現(xiàn)位置沒(méi)有在算法中得到體現(xiàn)，也不能體現(xiàn)不同數(shù)字作品信息各自的特性。因此，提出如下改進(jìn)的相關(guān)度排序算法：

其中k1、k2、k3、k4為權(quán)重系數(shù)，且滿足如下條件：（1）k1＋k2＋k3＋k4＝1；（2）1＞k1＞k4＞k2＞k3＞0，用戶在滿足（1）、（2）條件下，可以根據(jù)自己的需求設(shè)置權(quán)重系數(shù)。公式中具體評(píng)分參數(shù)的描述如表3所示，本改進(jìn)算法引入PageRank和二次檢索算法，同時(shí)為了體現(xiàn)數(shù)字作品信息的特性，針對(duì)不同的數(shù)字作品信息都有一個(gè)自己的權(quán)重值DataScore，這樣用戶可以將重要的數(shù)字作品信息顯示在前面，不重要的信息顯示在后面，最終顯示的搜索結(jié)果更符合數(shù)字作品信息的特性。

Table 3 Parameter descriptions of Improved rating formula表3 改進(jìn)評(píng)分公式中的參數(shù)描述

4 實(shí)驗(yàn)結(jié)果與分析

基于本文的理論分析，在JDK1.6、Tomcat6.0、Oracle10g、Myeclipse8.5、WinowsXP 的軟件平臺(tái)和Intel Core Due CPU i5-2450M（2.5GHz）、2GB內(nèi)存的硬件平臺(tái)下對(duì)20萬(wàn)條數(shù)據(jù)建立索引，并提供相應(yīng)的檢索服務(wù)。從以下四方面對(duì)數(shù)字作品搜索引擎實(shí)驗(yàn)分析：

（1）數(shù)字作品搜索引擎與傳統(tǒng)搜索引擎的比較如表4 所示。由表4 可知，該搜索引擎在數(shù)據(jù)源、分詞算法、索引和查詢分析等都比傳統(tǒng)的搜索引擎有很大的改進(jìn)和提高。

Table 4 Comparison table of search engines表4 搜索引擎比較表

（2）改進(jìn)后的分詞算法與上面提到的幾種主流的中文分詞算法在分詞效果上進(jìn)行比較。例如“基于LuceneDCI數(shù)據(jù)垂直搜索引擎的研究與設(shè)計(jì)”分詞得到的結(jié)果如表5所示。不難發(fā)現(xiàn)，改進(jìn)后的分詞算法的分詞效果更符合漢語(yǔ)習(xí)慣，更為重要的是改進(jìn)后的分詞算法節(jié)省了存儲(chǔ)空間，這樣也節(jié)省了建立索引的時(shí)間。

Table 5 Comparison of segmentation results表5 分詞結(jié)果比較

（3）在數(shù)字作品信息大小為10MB 和900MB時(shí)，將改進(jìn)后的分詞算法與幾種主流的中文分詞算法在分詞速度上進(jìn)行比較，如表6所示，其中第一次分詞是對(duì)大小是10MB 的數(shù)據(jù)進(jìn)行分詞，第二次分詞是對(duì)大小是900MB 的數(shù)據(jù)進(jìn)行分詞。實(shí)驗(yàn)數(shù)據(jù)表明，改進(jìn)后的分詞算法的分詞速度比IK＿CAanalyzer提 升45 倍，和StandardAnalyzer 和ICTCLAS的分詞速度相似。

Table 6 Comparison of segmentation algorithms speed表6 分詞速度比較

（4）在關(guān)鍵詞檢索方面，實(shí)驗(yàn)表明本搜索引擎確實(shí)實(shí)現(xiàn)了數(shù)字作品信息（20萬(wàn)條數(shù)據(jù)）的快速搜索，實(shí)驗(yàn)分析了檢索結(jié)果的響應(yīng)時(shí)間和命中數(shù)量等數(shù)值。如表7所示，關(guān)鍵詞檢索時(shí)間全部在1秒之內(nèi)完成。

Table 7 Time and number of keyword retrieval表7 關(guān)鍵詞檢索時(shí)間和數(shù)量

（5）以上幾種中文分詞算法在關(guān)鍵詞檢索方面，實(shí)驗(yàn)表明本搜索引擎確實(shí)實(shí)現(xiàn)了數(shù)字作品信息（20萬(wàn)條數(shù)據(jù)）搜索的準(zhǔn)確性。如表8 所示，實(shí)驗(yàn)分析了檢索結(jié)果的準(zhǔn)確率和召回率等。

Table 8 Accuracy and recall rate of retrieval表8 檢索準(zhǔn)確率和召回率 %

5 結(jié)束語(yǔ)

專業(yè)搜索引擎以其更準(zhǔn)確、更有效的檢索而越來(lái)越受到用戶的重視，在深入學(xué)習(xí)Lucene之后，本文先對(duì)整體結(jié)構(gòu)進(jìn)行了分析；接著對(duì)各個(gè)功能技術(shù)進(jìn)行了分析與設(shè)計(jì)，對(duì)于數(shù)據(jù)建立索引和搜索方面提出相應(yīng)的改進(jìn)算法；最終設(shè)計(jì)了一個(gè)可行有效的用于解決海量數(shù)字作品信息的搜索引擎。本系統(tǒng)還有一些有待改進(jìn)的地方，比如搜索精度和搜索效率的進(jìn)一步提高等，這些都是以后需要進(jìn)一步研究的內(nèi)容。

[1]DCI[EB／OL].[2011-12-02].http：／／baike.baidu.com／view／1733861.htm.

[2]http：／／tech.hexun.com／2010-05-10／123653027.html.

[3]Li Zhen-long.Study of improving strategy and technological analysis for information searching[J].Computer Science，2006，33（4）：181-184.（in Chinese）

[4]Cui Xiao-bo.SOA overview[EB／OL].[2006-01-05].Blog.csdn.（in Chinese）

[5]Wang Lei.High availability HDFS：Hadoop[M].Beijing：Tsinghua University Press，2012.（in Chinese）

[6]Liu Peng.Actual Hadoop：Open the shortcut to the cloud computing[M].Beijing：Publishing House of Electronics Industry，2011.（in Chinese）

[7]Qiu Zhe，F(xiàn)u Tao-tao.The development of own search engine—Lucene 2.0＋Heritrix[M].Beijing：People＇s Posts and Telecommunications Press，2007.（in Chinese）

[8]Witten I H，Moffat A，Bell T C.Managing gigabytes：Compressing and index documents and images[M].New York：Van Nostrand Reinhold，1994.

[9]Zhao Ke，Lu Peng，Li Yong-qiang.Design and implementation of search engine based on Lucene[J].Computer Engineering，2011，37（16）：39-41.（in Chinese）

[10]Gospodnetic O，Hatcher E.Lucene in action[M].Beijing：Publishing House of Electronics Industry，2007.（in Chinese）

附中文參考文獻(xiàn)：

[3]李振龍.Web信息檢索的技術(shù)分析與發(fā)展策略研究[J].計(jì)算機(jī)科學(xué)，2006，33（4）：181-184.

[4]崔曉波.SOA 概覽[EB／OL].[2006-01-05].Blog.csdn.

[5]王磊.高可用性的HDFS：Hadoop[M].北京：清華大學(xué)出版社，2012.

[6]劉鵬.實(shí)戰(zhàn)Hadoop：開(kāi)啟通向云計(jì)算的捷徑[M].北京：電子工業(yè)出版社，2011.

[7]邱哲，符滔滔.開(kāi)發(fā)自己的搜索引擎--Lucene 2.0＋Heritrix[M].北京：人民郵電出版社，2007.

[9]趙珂，逯鵬，李永強(qiáng).基于Lucene的搜索引擎的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程，2011，37（16）：39-41.

[10]Gospodnetic O，Hatcher E.Lucene in action中文版[M].譚鴻，譯.北京：電子工業(yè)出版社，2007.