改進(jìn)的大數(shù)據(jù)檢索自適應(yīng)性切換搜索算法*

吳雨晨，劉萍萍，徐江濤

(西安工業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與工程學(xué)院，西安710021)

大數(shù)據(jù)云計(jì)算技術(shù)是一種分布式計(jì)算的拓展，其在執(zhí)行工作時(shí)可將龐大的計(jì)算程序進(jìn)行分解，得到很多個(gè)更小的子程序，由集群來(lái)統(tǒng)一的完成計(jì)算工作，并將最終的計(jì)算結(jié)果反饋給用戶。當(dāng)前已經(jīng)出現(xiàn)的分布式搜索引擎技術(shù)已經(jīng)有很多種，例如Ajax技術(shù)、基于策略的分布式架構(gòu)技術(shù)、基于Web service技術(shù)的分布式搜索引擎以及基于P2P技術(shù)的分布式搜索引擎等。分析發(fā)現(xiàn)，此類搜索引擎主要都是介于Lucene全文檢索引擎工具包來(lái)實(shí)現(xiàn)的，但是這種方式建立索引的效率較低。Hadoop 分布式系統(tǒng)作為一個(gè)強(qiáng)大的分布式計(jì)算平臺(tái)，具有較高的兼容性，其能夠運(yùn)行在不同的硬件平臺(tái)中。目前Hadoop分布式系統(tǒng)已經(jīng)逐步應(yīng)用到了不同類型的智能系統(tǒng)中，使其系統(tǒng)的性能更加優(yōu)越。

文獻(xiàn)[1-2]從全文檢索的原理出發(fā)提出基于.net的索引器的海量非結(jié)構(gòu)文本搜索，驗(yàn)證了搜索引擎優(yōu)化的效果。文獻(xiàn)[3-4]針對(duì)檢索網(wǎng)絡(luò)的復(fù)雜變動(dòng)與檢索關(guān)鍵字的語(yǔ)義出發(fā)，基于Lucene架構(gòu)的搜索得分排序算法提出了結(jié)合詞項(xiàng)位置、文檔瀏覽量、更新時(shí)間等因素的AHP二次檢索公式，改進(jìn)的AHP二次檢索公式能更有效地提高信息檢索的準(zhǔn)確度。文獻(xiàn)[5-6]針對(duì)搜索的實(shí)體信息分散且缺乏語(yǔ)義，傳統(tǒng)搜索引擎語(yǔ)義如上下文信息時(shí)長(zhǎng)缺失的缺點(diǎn)，用信息網(wǎng)模型(INM)對(duì)Web數(shù)據(jù)進(jìn)行語(yǔ)義表示和建模，將實(shí)體的所有語(yǔ)義信息組織在一個(gè)對(duì)象中，快速獲取實(shí)體完整的語(yǔ)義信息，基于INM構(gòu)建復(fù)雜語(yǔ)義數(shù)據(jù)庫(kù)優(yōu)化搜索引擎性能。文獻(xiàn)[7-8]針對(duì)特定領(lǐng)域中的專業(yè)規(guī)律，為了更好的滿足專業(yè)領(lǐng)域用戶的信息需求，構(gòu)建了主題搜索引擎。該引擎采用錨文本匹配進(jìn)行領(lǐng)域關(guān)鍵字過(guò)濾、加入IKAnalyzer中文分詞器，排序搜索結(jié)果，并通過(guò)STC算法對(duì)結(jié)果實(shí)時(shí)聚類，其構(gòu)建的主題搜索引擎能更高效的在專業(yè)領(lǐng)域進(jìn)行搜索。文獻(xiàn)[9-11]針對(duì)數(shù)據(jù)實(shí)體信息與轉(zhuǎn)化語(yǔ)義信息之間的關(guān)聯(lián)性誤差，提出本體模型分詞高斯邊緣化融合的特定語(yǔ)義數(shù)據(jù)檢索算法，從而克服中心頻率變化對(duì)關(guān)聯(lián)性能的影響，實(shí)現(xiàn)海量數(shù)據(jù)干擾下算法的改進(jìn)，改進(jìn)算法消除大量關(guān)聯(lián)性誤差，提高搜索引擎查準(zhǔn)率。

現(xiàn)有搜索算法在復(fù)雜問(wèn)題搜索上性能不足且誤差較大，本文擬采用Hadoop分布式計(jì)算平臺(tái)來(lái)建立分布式搜索引擎，利用Map-Reduce實(shí)現(xiàn)分布式索引模塊，最終通過(guò)優(yōu)化自適應(yīng)性切換搜索算法來(lái)提高搜索引擎性能。

1 Hadoop分布式平臺(tái)及框架

Hadoop分布式平臺(tái)是一種分布式的系統(tǒng)架構(gòu)，Hadoop最初分為三部分[12-13]，分別是Hadoop Common、HDFS(Hadoop Distributed File System)以及Map-Reduce，每部分能夠發(fā)揮不同的功能，此外還有很多相關(guān)的開源框架。Hadoop分布式平臺(tái)的組成結(jié)構(gòu)較為復(fù)雜，其中最底層為 HDFS，也就是一個(gè)分布式文件存儲(chǔ)系統(tǒng)。HDFS不僅能夠?qū)崿F(xiàn)文件管理系統(tǒng)的各添加以及刪除等操作，而且具有傳統(tǒng)存儲(chǔ)方式所不具有的優(yōu)勢(shì)。基于Hadoop平臺(tái)來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)的處理和存儲(chǔ)具有很大的優(yōu)勢(shì)，尤其是對(duì)于海量數(shù)據(jù)的存儲(chǔ)和管理，而且對(duì)于故障的恢復(fù)率比較高、可移植性較強(qiáng)。HDFS組織架構(gòu)如圖1所示。

本文設(shè)計(jì)的分布式搜索引擎為企業(yè)或個(gè)人提供個(gè)性化的搜索服務(wù)，為保證服務(wù)器端HDFS文件系統(tǒng)與客戶端文件系統(tǒng)的同步，需要對(duì)Windows本地文件系統(tǒng)進(jìn)行監(jiān)控。因此客戶端必須具有多個(gè)功能，例如對(duì)文件的上傳、下載、新建、刪除以及修改等操作的實(shí)時(shí)監(jiān)控功能。服務(wù)器端主要實(shí)現(xiàn)的是存取文件以及同步事件等功能，例如需要對(duì)文件修改、刪除以及建立等事件進(jìn)行同步處理。

分布式索引子系統(tǒng)主要是對(duì)預(yù)處理之后文檔的分詞處理等，能夠得到倒排索引并存儲(chǔ)到倒排索引庫(kù)內(nèi)，其系統(tǒng)總體架構(gòu)基于Map-Reduce框架實(shí)現(xiàn)。實(shí)現(xiàn)基于字符串的查詢功能，通過(guò)界面獲得使用者輸入的文本，對(duì)其進(jìn)行解析得到關(guān)鍵詞等條件，并對(duì)倒排索引庫(kù)進(jìn)行查詢即可得到最終的結(jié)果。具體的分布式查詢子系統(tǒng)整體架構(gòu)為：① 輸入查詢內(nèi)容。② 對(duì)查詢內(nèi)容進(jìn)行中文分詞。③ 對(duì)分詞結(jié)果執(zhí)行查詢。④ 獲得查詢文檔的倒排索引。⑤ 將查詢文檔的倒排索引存儲(chǔ)到索引庫(kù)。⑥ 利用Map-Reduce計(jì)算框架按行分割查詢結(jié)果，key為文本偏移量，value為一行文檔的內(nèi)容。⑦ 將⑥結(jié)果再進(jìn)行一輪Reduce過(guò)程，合并索引的查詢結(jié)果。

圖1 HDFS組織架構(gòu)Fig.1 HDFS organization

2 算法優(yōu)化

2.1 TF-IDF算法

通常文檔數(shù)據(jù)量非常巨大，用戶進(jìn)行查詢時(shí)會(huì)得到很多不同的查詢結(jié)果[14]。為找到與用戶真正需求一致的查詢結(jié)果就需要借助于一定的評(píng)分策略，通過(guò)特定的網(wǎng)頁(yè)評(píng)分功能來(lái)滿足用戶對(duì)查詢結(jié)果精確性的要求?；诖髷?shù)據(jù)的數(shù)據(jù)檢索系統(tǒng)系統(tǒng)，不同文檔之間都是相互獨(dú)立的，而同一個(gè)文檔內(nèi)的標(biāo)題和內(nèi)容具有較強(qiáng)的關(guān)聯(lián)性。為了使系統(tǒng)滿足用戶的個(gè)性化查詢需求，設(shè)計(jì)了一種基于用戶偏好的搜索方法，并且結(jié)合了TF-IDF(Term Frequency-Inverse Document Frequency)算法來(lái)改進(jìn)現(xiàn)有的文檔評(píng)分策略，從而為用戶提供真正符合其需求的搜索服務(wù)。

TF-IDF作為一類統(tǒng)計(jì)方法，能夠有效地對(duì)文件集中某個(gè)文件的重要程度進(jìn)行合理地統(tǒng)計(jì)。其原理可以理解為兩層含義：① 可以認(rèn)為某個(gè)詞在文檔中出現(xiàn)的次數(shù)在很大程度上能夠表明這個(gè)詞與文檔的相關(guān)程度，這個(gè)詞出現(xiàn)的次數(shù)越多說(shuō)明相關(guān)性越大；② 某個(gè)詞用來(lái)驗(yàn)證文檔相關(guān)性的作用與含有此詞的文檔數(shù)是一種反比關(guān)系。TF-IDF算法的計(jì)算公式為

(1)

(2)

tfidfi,j=tfi,j×idfi

(3)

式中：ni,j為文件dj中詞的數(shù)量，∑knk,j為文件dj中的所有詞之和。|D|為語(yǔ)料庫(kù)的文件數(shù)目，|{j:ti∈dj}|為含有詞語(yǔ)ti的文件數(shù)，而tfidfi,j為詞ti和文檔的相關(guān)性大小。在一份給定的文件里，詞頻(Term Frequency，TF)為某一個(gè)給定的詞語(yǔ)在該文件中出現(xiàn)的頻率，它是對(duì)詞數(shù)(Term Count)的歸一化，以防止它偏向長(zhǎng)的文件。對(duì)于在某一特定文件里的詞語(yǔ)ti來(lái)說(shuō)，它的重要性可表示為逆向文件頻率(Inverse Document Frequency，IDF)，是一個(gè)詞語(yǔ)普遍重要性的度量。某一特定詞語(yǔ)的IDF，可以由總文件數(shù)目除以包含該詞語(yǔ)之文件的數(shù)目，再將得到的商取對(duì)數(shù)得到。某一特定文件內(nèi)的高詞語(yǔ)頻率，以及該詞語(yǔ)在整個(gè)文件集合中的低文件頻率，可以產(chǎn)生出高權(quán)重的TF-IDF。因此，TF-IDF傾向于過(guò)濾掉常見(jiàn)的詞語(yǔ)，保留重要的詞語(yǔ)。本文對(duì)原始的TF-IDF算法進(jìn)行了改進(jìn)，在計(jì)算Rank評(píng)分時(shí)將文檔中詞的位置納入影響因素，對(duì)于文檔中標(biāo)題和正文出現(xiàn)的關(guān)鍵詞分別設(shè)置不一樣的權(quán)重值。例如在詞頻值計(jì)算方面，標(biāo)題中含有此關(guān)鍵詞時(shí)就將詞頻值大小增加6；正文內(nèi)出現(xiàn)關(guān)鍵詞時(shí)就將詞頻值大小增加1。

2.2 算法優(yōu)化

本文設(shè)計(jì)的自適應(yīng)性切換搜索算法，需要基于索引的大小來(lái)針對(duì)性的處理索引過(guò)程。如果索引很小，可以將其直接存入內(nèi)存；如果索引文件很大，可以建立二級(jí)索引，讀到內(nèi)存中的索引列表，可以進(jìn)行分布式的查詢。通過(guò)這種方式可以有效地提高對(duì)索引文件的搜索效率。

自適應(yīng)性切割搜索算法的基本原理是基于索引文件大小選擇合適的搜索算法[15-16]，以256 MB大小的索引文件為界限，如果索引文件大小不超過(guò)256 MB，此時(shí)用戶查詢時(shí)將索引文件讀進(jìn)內(nèi)存，對(duì)其直接進(jìn)行查詢。如果索引文件大小超過(guò)256 MB，需要構(gòu)建二級(jí)索引，查詢時(shí)先將二級(jí)索引讀進(jìn)內(nèi)存中，用戶先對(duì)此二級(jí)索引進(jìn)行查詢，并以此來(lái)查詢到原始的索引文件。最終獲取的索引文件即為Map-Reduce查詢?nèi)蝿?wù)的輸入，可以得到最終的查詢結(jié)果。在執(zhí)行Map-Reduce任務(wù)時(shí)，將輸入文件分割為多個(gè)split，同時(shí)為每個(gè)split建立Mapper。通常情況下split是64 MB，如果輸入文件很少，只需少數(shù)Mapper就能完成處理任務(wù)，此時(shí)不能充分發(fā)揮分布式計(jì)算的高性能優(yōu)勢(shì)。同時(shí)可能會(huì)因?yàn)檫^(guò)多的文件分割以及分發(fā)過(guò)程使得計(jì)算效率降低。默認(rèn)情況下，Map-Reduce任務(wù)處理小于256 MB的文件是采用直接將其讀入內(nèi)存的方式，而超過(guò)256 MB采用的是并發(fā)執(zhí)行4個(gè)Mapper的方式。相關(guān)統(tǒng)計(jì)數(shù)據(jù)表明，當(dāng)前在漢字中使用最普遍的詞大約有56 000左右。如果索引文件中囊括了全部的詞，此時(shí)也可以加載二級(jí)索引文件到內(nèi)存中。另外關(guān)鍵詞通常只有少數(shù)幾個(gè)，此時(shí)通過(guò)建立二級(jí)索引的方式，就可以有效地降低查詢時(shí)的索引文件數(shù)。

算法的具體執(zhí)行過(guò)程如下：

1) 對(duì)索引文件的大小進(jìn)行統(tǒng)計(jì)，當(dāng)索引文件超過(guò)256MB時(shí)就建立二級(jí)索引，并將其存儲(chǔ)到HDFS。二級(jí)索引建立過(guò)程如下：

① 啟動(dòng)查詢器。

② 統(tǒng)計(jì)索引文件大小。

③ 判斷索引文件是否大于256M，若索引文件小于或等于256M直接寫入內(nèi)存；索引文件大于256M，流程繼續(xù)執(zhí)行。

④ 判斷是否已經(jīng)存在對(duì)應(yīng)二級(jí)索引文件，若存在，則將二級(jí)索引直接利用哈希表寫入內(nèi)存；若不存在則流程繼續(xù)執(zhí)行。

⑤ 對(duì)當(dāng)前索引文件構(gòu)建倒排索引。

⑥ 加入倒排索引數(shù)據(jù)庫(kù)。

⑦ 構(gòu)建二級(jí)索引。

⑧ 加入二級(jí)索引庫(kù)，并寫入內(nèi)存。

2) 對(duì)是否存在二級(jí)索引進(jìn)行判斷，同時(shí)使用flag變量進(jìn)行表示。如果不存在二級(jí)索引，就直接把索引文件存入特定的數(shù)據(jù)結(jié)構(gòu)中。具體的數(shù)據(jù)結(jié)構(gòu)如圖2所示，其主體是多個(gè)哈希表，在每一個(gè)哈希表中都有一個(gè)指向沖突鏈表的指針，而哈希值一樣的關(guān)鍵詞就組成了鏈表結(jié)構(gòu)。鏈表節(jié)點(diǎn)也就是結(jié)構(gòu)體，其含有關(guān)鍵詞及其文檔索引信息等。

圖2 哈希鏈表結(jié)構(gòu)示意

3) 如果索引文件很大，此時(shí)也需要先將二級(jí)索引加載到一個(gè)數(shù)據(jù)結(jié)構(gòu)中，但是此數(shù)據(jù)結(jié)構(gòu)與之前的哈希鏈表結(jié)構(gòu)有所不同，其鏈表結(jié)構(gòu)體主要包括了關(guān)鍵詞及其索引文檔URL。

4) 自適應(yīng)搜索算法首先是系統(tǒng)獲取用戶輸入的查詢內(nèi)容，作中文分詞處理。

5) 此時(shí)需要對(duì)索引文件大小進(jìn)行確定，如果其低于256 MB，可以直接按照關(guān)鍵詞的哈希值來(lái)查詢內(nèi)存中的索引文件并得到結(jié)果。

6) 當(dāng)索引文件的大小超過(guò)了256 MB時(shí)，需要基于關(guān)鍵詞的哈希值來(lái)查詢二級(jí)索引文件。此時(shí)將得到的索引文件作為Map-Reduce輸入，來(lái)得到最終的查詢結(jié)果。

同時(shí)需要基于Map-Reduce框架來(lái)建立二級(jí)索引，其步驟如下：

① 執(zhí)行Map-Reduce任務(wù)的輸入即為之前的倒排索引文件，使用TextInputFormat完成對(duì)輸入文件的分割。

② 將輸入文件中沒(méi)行內(nèi)容作為Map()函數(shù)的輸入，此時(shí)的新key值也就是其中含有的關(guān)鍵詞；相應(yīng)的新value值即為關(guān)鍵詞所在文件的URL。

③ 通過(guò)Reduce()來(lái)合并Map()函數(shù)的輸出，并將最終的結(jié)果存儲(chǔ)到HDFS文件系統(tǒng)的二級(jí)索引庫(kù)內(nèi)。

2.3 算法測(cè)試

在測(cè)試自適應(yīng)搜索算法的計(jì)算性能時(shí)，采用了按照大、小索引兩種類型計(jì)算的方式，并與之前算法的計(jì)算性能作對(duì)比。測(cè)試結(jié)果見(jiàn)表1和表2。

表1 小索引文件新舊算法性能測(cè)試結(jié)果

表2 大索引文件新舊算法性能測(cè)試結(jié)果

進(jìn)行查詢測(cè)試時(shí)，選取了五組低于256 MB的索引文件來(lái)進(jìn)行測(cè)試。針對(duì)每一組索引文件作10次查詢，統(tǒng)計(jì)每次的查詢時(shí)間并計(jì)算出時(shí)間的平均值。測(cè)試結(jié)果如圖3所示，從圖3中可以發(fā)現(xiàn)，小索引情況時(shí)使用新搜索算法花費(fèi)的時(shí)間明顯低于原始搜索算法，這說(shuō)明這種新算法在性能方面具有較大的優(yōu)勢(shì)。

圖3 小索引的算法測(cè)試結(jié)果比較

測(cè)試超過(guò)256 MB的索引文件的查詢性能，這里選擇了三組索引文件進(jìn)行測(cè)試。針對(duì)每一組索引文件作10次查詢，統(tǒng)計(jì)查詢時(shí)間并計(jì)算出時(shí)間的平均值。得到的測(cè)試結(jié)果如圖4所示，可以發(fā)現(xiàn)使用新搜索算法進(jìn)行查詢花費(fèi)的時(shí)間顯著小于原始的搜索算法。

通過(guò)測(cè)試發(fā)現(xiàn)，使用文中算法的查詢效率顯著提高，原因是由于本文的查詢測(cè)試是基于5節(jié)點(diǎn)集群，共有4個(gè)索引文件，關(guān)鍵詞數(shù)也是4個(gè)左右，因此關(guān)鍵詞可能出現(xiàn)在2個(gè)或者是3個(gè)索引文件內(nèi)。而通過(guò)二級(jí)索引檢索能夠降低索引文件數(shù)，使其變?yōu)?個(gè)或者3個(gè)。同理，如果集群的節(jié)點(diǎn)更多，可以將索引文件進(jìn)行更精細(xì)的劃分，新算法的計(jì)算效率也會(huì)更高。

圖4 大索引的算法測(cè)試結(jié)果

3 系統(tǒng)構(gòu)建

大數(shù)據(jù)數(shù)據(jù)檢索自適應(yīng)系統(tǒng)包括客戶端與服務(wù)器端。在系統(tǒng)正常運(yùn)行的時(shí)候，監(jiān)控模塊會(huì)實(shí)現(xiàn)對(duì)文件的實(shí)時(shí)監(jiān)控功能。對(duì)于客戶端來(lái)說(shuō)，操作本地文件時(shí)，系統(tǒng)會(huì)對(duì)用戶的操作事件進(jìn)行實(shí)時(shí)的監(jiān)控處理，同時(shí)對(duì)監(jiān)控結(jié)果進(jìn)行劃分。下一步為文件同步過(guò)程的執(zhí)行，此時(shí)需要文件同步模塊提供相應(yīng)的同步服務(wù)。此模塊能夠基于不同的事件來(lái)做出特定的響應(yīng)，具體的響應(yīng)包括對(duì)服務(wù)器端HDFS中文件的增刪改查。

3.1 客戶端功能模塊

在客戶端中，對(duì)HDFS文件系統(tǒng)進(jìn)行操作主要包括文件新建、文件下載、文件刪除以及文件打開等，其功能分別為：文件新建實(shí)現(xiàn)新HDFS文件的創(chuàng)建； 下載實(shí)現(xiàn)將服務(wù)器端的HDFS文件下載到本地文件夾中；刪除實(shí)現(xiàn)對(duì)HDFS文件的刪除；重命名實(shí)現(xiàn)對(duì)HDFS文件系統(tǒng)中文件的重新命名；打開將HDFS文件系統(tǒng)中相應(yīng)的文件打開并查看其具體內(nèi)容；刷新實(shí)現(xiàn)對(duì)HDFS的文件列表刷新顯示。H按鈕操作事件監(jiān)控及分類處理如圖5所示。

3.2 服務(wù)器端功能模塊

系統(tǒng)的后臺(tái)存儲(chǔ)系統(tǒng)使用了HDFS文件系統(tǒng)，可以有效地實(shí)現(xiàn)分布式存儲(chǔ)功能。結(jié)構(gòu)分為3個(gè)節(jié)點(diǎn)，其中一個(gè)為Namenode主節(jié)點(diǎn)，主要實(shí)現(xiàn)對(duì)元數(shù)據(jù)信息的存儲(chǔ)功能；其余兩個(gè)為Datanode從節(jié)點(diǎn)，主要實(shí)現(xiàn)對(duì)文件數(shù)據(jù)塊的存儲(chǔ)功能。Datanode的文件分塊大小為64MB，復(fù)制因子為2，表示文件分塊備份了2個(gè)。系統(tǒng)服務(wù)器端的架構(gòu)如圖6所示。

圖5 H按鈕操作事件監(jiān)控及分類處理

圖6 系統(tǒng)服務(wù)端的整體架構(gòu)圖

4 性能測(cè)試與分析

為充分利用現(xiàn)有的硬件資源進(jìn)行測(cè)試，直接使用一臺(tái)IBM服務(wù)器來(lái)模擬五個(gè)配置完全一致的節(jié)點(diǎn)。具體硬件配置如下：CPU是單處理器單核；內(nèi)存大小是1 G，硬盤大小是20 G。選擇使用Linux下的ubuntu-12.04操作系統(tǒng) ；使用jdk1.7與Eclipse 3.5來(lái)進(jìn)行Java程序開發(fā)；Hadoop平臺(tái)選擇的是hadoop-0.20.2版本；虛擬機(jī)選擇的是VMware-workstation full-v10.0.0版本。本系統(tǒng)在配置Hadoop集群時(shí)，選擇其中一個(gè)作為Master，其他的都作為 Slave節(jié)點(diǎn)，并將網(wǎng)絡(luò)設(shè)置成橋接模式。節(jié)點(diǎn)的具體信息見(jiàn)表3。

表3 集群的節(jié)點(diǎn)設(shè)置

常規(guī)的搜索引擎主要在建立索引時(shí)需要花費(fèi)較多的時(shí)間，查詢過(guò)程較為迅速，而查詢時(shí)間過(guò)短會(huì)導(dǎo)致受到帶寬等因素的干擾，因此對(duì)本系統(tǒng)測(cè)試時(shí)主要是對(duì)索引建立進(jìn)行了測(cè)試。為了確定Hadoop集群的性能與節(jié)點(diǎn)數(shù)量之間的關(guān)系，本文將集群的節(jié)點(diǎn)數(shù)分別設(shè)置為2,3,4和5進(jìn)行測(cè)試；對(duì)系統(tǒng)運(yùn)行時(shí)間進(jìn)行比較，分別選擇了100,1 000,10 000,100 000以及1 000 000個(gè)網(wǎng)頁(yè)文檔來(lái)建立倒排索引。性能測(cè)試結(jié)果如圖7所示。

圖7 性能測(cè)試結(jié)果

從圖7可以發(fā)現(xiàn)，如果網(wǎng)頁(yè)文檔的數(shù)量很少，建立索引時(shí)間與節(jié)點(diǎn)數(shù)量。其主要原因?yàn)椋喝绻W(wǎng)頁(yè)文檔的數(shù)量較少，也只有很少部分節(jié)點(diǎn)來(lái)執(zhí)行建立索引任務(wù)，其分布式計(jì)算性能沒(méi)有發(fā)揮，索引時(shí)間也不會(huì)隨著文檔的增多而變化，因?yàn)樵谌蝿?wù)分隔等過(guò)程中花費(fèi)了較多的時(shí)間。而如果網(wǎng)頁(yè)文檔足夠多時(shí)，此時(shí)建立索引需要的時(shí)間與節(jié)點(diǎn)數(shù)呈現(xiàn)出負(fù)增長(zhǎng)關(guān)系，即節(jié)點(diǎn)數(shù)量越大，索引時(shí)間就越短，這就證明系統(tǒng)性能隨著節(jié)點(diǎn)的增多而提升。因此可以采用增加節(jié)點(diǎn)數(shù)量的方式來(lái)提升整個(gè)系統(tǒng)的性能。這表明，本系統(tǒng)具有較高的可靠性，即使有多個(gè)節(jié)點(diǎn)發(fā)生了故障，系統(tǒng)仍然能夠完成相應(yīng)任務(wù)。

5 結(jié) 論

本文設(shè)計(jì)并實(shí)現(xiàn)了一種自適應(yīng)性切換搜索算法，通過(guò)對(duì)索引文件大小的有效分析和處理，利用了Map-Reduce框架完成了對(duì)索引以及查詢兩個(gè)子系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)，優(yōu)化了分布式搜索引擎的搜索效率。

1) 基于用戶的個(gè)性化搜索需求來(lái)選擇合適的搜索方式，提高了搜索結(jié)果的精確性。用戶在使用Map/Reduce框架進(jìn)行文件處理時(shí)，只需要重新對(duì)Map以及Reduce函數(shù)進(jìn)行編寫即可實(shí)現(xiàn)分布式處理功能，而完全不需要考慮其處理過(guò)程中涉及到的通信問(wèn)題、存儲(chǔ)問(wèn)題以及負(fù)載均衡問(wèn)題等。

2) 選擇100,1 000,10 000,100 000以及1 000 000個(gè)網(wǎng)頁(yè)文檔來(lái)建立倒排索引，建立索引需要的時(shí)間與節(jié)點(diǎn)數(shù)呈現(xiàn)出負(fù)增長(zhǎng)關(guān)系，即節(jié)點(diǎn)數(shù)目越大，索引時(shí)間就越短，證明系統(tǒng)性能隨著節(jié)點(diǎn)的增多而提升。

3) 通過(guò)對(duì)五組低于256 MB的索引文件和三組超過(guò)256 MB的索引文件進(jìn)行測(cè)試，并針對(duì)每一組索引文件作10次查詢。當(dāng)索引文件大小在1 000 MB左右時(shí)，算法效果達(dá)到最優(yōu)，搜索時(shí)間相較原算法大幅縮短。