面向桌面環(huán)境的索引實(shí)時(shí)更新方法①

楊凱飛 ,李文波 ,柯 川

1(中國科學(xué)院 軟件研究所 基礎(chǔ)軟件國家工程研究中心,北京 100190)2(中國科學(xué)院大學(xué),北京 100049)

面向桌面環(huán)境的索引實(shí)時(shí)更新方法①

楊凱飛1,2,李文波1,柯 川1,2

1(中國科學(xué)院 軟件研究所 基礎(chǔ)軟件國家工程研究中心,北京 100190)2(中國科學(xué)院大學(xué),北京 100049)

在桌面計(jì)算環(huán)境中,文件和目錄頻繁發(fā)生新建、刪除、修改、重命名、移動(dòng)、復(fù)制等變化,這對(duì)桌面索引更新的實(shí)時(shí)性和性能提出更高要求,而傳統(tǒng)的桌面索引更新方法完全或部分依賴周期性全盤掃描,往往需要大規(guī)模索引重建,導(dǎo)致索引生成延遲大、系統(tǒng)資源占用高.針對(duì)這些弊端,本文提出了一種基于文件系統(tǒng)事件監(jiān)聽的桌面索引實(shí)時(shí)更新方法,并實(shí)現(xiàn)了相應(yīng)的桌面索引實(shí)時(shí)更新系統(tǒng).實(shí)驗(yàn)表明:本文提出的索引更新方法延遲低、系統(tǒng)資源占用低.

桌面搜索; 文件系統(tǒng)監(jiān)控; 索引更新; 文本抽取; inotify

隨著用戶所掌握的數(shù)據(jù)量迅速增加和PC存儲(chǔ)容量的大幅增長,PC中存儲(chǔ)的文檔、圖片、視頻等越來越多,這些數(shù)據(jù)量大且存儲(chǔ)無序、不規(guī)則,管理、查找較為困難.從如此大規(guī)模的文檔集中尋找所需耗時(shí)費(fèi)力,桌面搜索引擎的重要性逐漸凸顯.桌面搜索引擎用于索引和檢索PC中的文檔信息,Google、Yahoo、Microsoft、百度等先后推出桌面搜索引擎.

類似于網(wǎng)絡(luò)搜索引擎,桌面搜索引擎多采用先為桌面文檔建立索引再提供查詢的方式.這極大地提升了查詢速度,但也帶來了桌面索引更新的問題,桌面索引需及時(shí)更新,才能保證其與文檔內(nèi)容一致.因?yàn)樽烂嫖臋n頻繁發(fā)生新增、刪除、修改、重命名、移動(dòng)、復(fù)制等變化,桌面索引更新的實(shí)時(shí)性和性能要求更為嚴(yán)苛.

桌面索引更新的基本方式有兩種:1)周期性掃描所有文件和目錄并檢測其變化,為發(fā)生變化的文件或目錄更新索引.該方法需周期性遍歷所有文件和目錄,不僅性能差,而且延遲時(shí)間長,無法保證索引更新的實(shí)時(shí)性; 2)基于操作系統(tǒng)或第三方的文件系統(tǒng)事件監(jiān)聽方法,實(shí)時(shí)監(jiān)聽文件系統(tǒng)事件并更新索引.這種方法實(shí)時(shí)性好、效率高.現(xiàn)有桌面索引更新系統(tǒng)多采用方式1)或以其為主[1],往往需要周期性重建索引,導(dǎo)致索引更新延遲大、系統(tǒng)資源占用高.方式2)雖然高效、實(shí)時(shí),但Linux內(nèi)核文件系統(tǒng)變化通知機(jī)制存在無法監(jiān)聽子目錄、冗余信息未過濾等典型缺點(diǎn),依靠其實(shí)現(xiàn)的現(xiàn)有監(jiān)聽方法存在監(jiān)控效率低、穩(wěn)定性差、維護(hù)復(fù)雜等缺點(diǎn).這也是方式2)未被桌面索引更新系統(tǒng)單獨(dú)和廣泛采用的重要原因.

針對(duì)桌面環(huán)境的特性和現(xiàn)有桌面索引更新方法的弊端,本文提出了一種基于文件系統(tǒng)事件監(jiān)聽的桌面索引實(shí)時(shí)更新方法,無需周期性掃描全盤即可保證索引內(nèi)容與桌面文檔完全一致.本方法能夠?qū)崿F(xiàn)對(duì)文件系統(tǒng)事件的實(shí)時(shí)監(jiān)聽以及快速更新索引內(nèi)容.我們研究了現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法,在此基礎(chǔ)上,提出了一種Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法并實(shí)現(xiàn),克服了現(xiàn)有方法的典型缺點(diǎn).最后,在Linux操作系統(tǒng)上實(shí)現(xiàn)了桌面索引實(shí)時(shí)更新系統(tǒng),采用了多種性能優(yōu)化策略提升其索引速度.實(shí)驗(yàn)表明:本文提出的桌面索引實(shí)時(shí)更新方法延遲時(shí)間短、系統(tǒng)資源占用低.

1 相關(guān)工作

桌面搜索引擎采用預(yù)先為桌面文檔建立索引的方式來提升用戶檢索信息的速度,但由于桌面文檔頻繁發(fā)生變化,桌面索引需要頻繁并且實(shí)時(shí)更新.桌面索引實(shí)時(shí)更新的核心是及時(shí)獲取到文件的變化,現(xiàn)有桌面索引更新方法完全或部分依賴周期性全盤掃描的方法獲取發(fā)生變化的文件和目錄,這種方法延遲大、效率低.采用實(shí)時(shí)監(jiān)聽文件系統(tǒng)事件的方式可以大幅提升索引更新的實(shí)時(shí)性和效率,所以本文首先研究了現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法.

除了需要實(shí)時(shí)監(jiān)聽文件系統(tǒng)事件,桌面文檔頻繁變化還帶來了桌面索引更新策略如何選擇的問題,尤其是目錄發(fā)生變化時(shí)如何更高效地更新桌面索引的內(nèi)容.桌面索引中一般會(huì)存儲(chǔ)文檔的絕對(duì)路徑等元數(shù)據(jù)信息,目錄的變化會(huì)導(dǎo)致其所包含的所有文件均需要更新,表1列舉了目錄發(fā)生不同類型的變化時(shí)對(duì)桌面索引的影響.在不同的變化類型下,選擇不同的更新策略會(huì)對(duì)系統(tǒng)性能產(chǎn)生較大影響.例如,若目錄發(fā)生重命名事件,一種策略是先從索引中刪除該目錄下所有文件的索引信息,再從新目錄中抽取所有文件信息并為其重建索引.第二種策略是在倒排索引中定位所有需要更改的信息,修改部分元數(shù)據(jù)信息即可.若目錄中包含大量文件,則第二種策略在性能上明顯占優(yōu).相應(yīng)的,目錄刪除、移動(dòng)、復(fù)制等變化同樣需要采取優(yōu)化的索引更新策略.

表1 目錄的變化對(duì)桌面索引的影響

1.1 Linux內(nèi)核文件系統(tǒng)變化通知機(jī)制

Linux內(nèi)核先后引入了dnotify、inotify、fanotify三種文件系統(tǒng)變化通知機(jī)制.dnotify從Linux 2.4.0內(nèi)核開始引入,是三者中最早引入的,但是存在很多缺陷.inotify從 Linux 2.6.13內(nèi)核開始引入,完全替代了dnotify,也是三者中目前使用最廣泛的[2-5].fanotify從Linux 2.6.36內(nèi)核開始引入,與inotify相比各有所長.

dnotify可以監(jiān)控文件系統(tǒng)中目錄的變化事件,目錄中某個(gè)文件發(fā)生訪問、新建、刪除、更改、屬性修改等變化時(shí)均會(huì)發(fā)出通知.但是dnotify只能監(jiān)控某個(gè)目錄中發(fā)生的變化,而無法及時(shí)獲取發(fā)生變化的具體文件,需要進(jìn)一步獲取信息,而且它需要對(duì)每一個(gè)被監(jiān)控目錄打開一個(gè)文件描述符,若文件所在磁盤需要卸載,會(huì)受到影響.此外,它返回的事件信息較少.

inotify監(jiān)控粒度更細(xì),可獲取發(fā)生變化的文件信息,而且監(jiān)控的事件類型很多,涵蓋文件新建、刪除、移動(dòng)等多種類型事件.但是,inotify 的一個(gè)監(jiān)視 (watch)只能監(jiān)控一個(gè)目錄,無法遞歸監(jiān)控其子目錄,而且單個(gè)用戶可創(chuàng)建的inotify實(shí)例數(shù)目和每個(gè)inotify實(shí)例可關(guān)聯(lián)的監(jiān)視數(shù)目均有限制,兩者的默認(rèn)值分別為128和8192.在Linux環(huán)境下,可分別通過修改配置文件“/proc/sys/fs/inotify/max_user_instances”和“/proc/sys/fs/inotify/max_user_watches”修改兩者的默認(rèn)值[6,7].

fanotify既可以通知文件系統(tǒng)變化,也可以攔截文件系統(tǒng)變化,應(yīng)用程序使用fanotify的訪問控制(Access Decision)功能可以決定是否允許其它應(yīng)用程序?qū)ξ募牟僮鱗8].fanotify提供三種文件系統(tǒng)變化監(jiān)控模式:全文件系統(tǒng)監(jiān)控(Global)、單個(gè)掛載點(diǎn)監(jiān)控(per-mount)、單個(gè)對(duì)象監(jiān)控 (Directed).fanotify 不僅可以監(jiān)控其它程序?qū)ξ臋n和目錄的操作,還能決定是否允許其操作.表2比較了三種機(jī)制監(jiān)聽文件系統(tǒng)事件的特性.

在桌面搜索場景中,Linux內(nèi)核文件系統(tǒng)變化通知機(jī)制有兩點(diǎn)主要不足:

1)單個(gè)監(jiān)視(watch)無法監(jiān)聽子目錄內(nèi)部的事件.例如,對(duì)inotify而言,單個(gè)監(jiān)視只能監(jiān)聽到目錄中文件和直接子目錄的變化,而子目錄內(nèi)事件的監(jiān)聽需由新的監(jiān)視負(fù)責(zé).fanotify有三種模式,雖然其 Global模式和Per-mount模式可以分別實(shí)現(xiàn)對(duì)全盤和某個(gè)掛載點(diǎn)的全部文件系統(tǒng)事件的監(jiān)聽,但其依然無法實(shí)現(xiàn)在監(jiān)控某一目錄對(duì)象時(shí)監(jiān)聽包括其子目錄在內(nèi)的所有文件系統(tǒng)事件,而且fanotify監(jiān)聽的事件類型過少,根本無法滿足桌面索引實(shí)時(shí)更新系統(tǒng)的需求.

2)存在冗余信息.例如,為保證事件無遺漏,inotify未過濾臨時(shí)文件的變化信息,這為桌面索引更新帶來不便.

1.2 第三方的文件系統(tǒng)事件監(jiān)聽庫

通過封裝Linux內(nèi)核提供的文件系統(tǒng)變化通知機(jī)制,第三方的文件系統(tǒng)事件監(jiān)聽庫函數(shù)也可為應(yīng)用程序提供對(duì)文件系統(tǒng)事件的實(shí)時(shí)監(jiān)聽.下面對(duì)兩個(gè)提供Java API的監(jiān)聽庫進(jìn)行重點(diǎn)研究.

1)JNotify 是一套 Java API,可以為 Java 應(yīng)用程序提供監(jiān)聽文件系統(tǒng)事件的功能,這些事件包括文件和目錄新建、刪除、修改和重命名等.在Linux操作系統(tǒng)環(huán)境下,JNotify 實(shí)際上是 Linux Inotify API的簡單封裝.Inotify的單個(gè)監(jiān)視不支持遞歸監(jiān)控子目錄,JNotify通過為監(jiān)控目錄下的每個(gè)子目錄遞歸創(chuàng)建一個(gè)監(jiān)視實(shí)現(xiàn)了這個(gè)功能,但這一過程的時(shí)間消耗也隨著子目錄層數(shù)的增加而呈現(xiàn)指數(shù)增長,同時(shí)也帶來了系統(tǒng)資源需求的增加[9,10];

2)JDK 自 1.7 版本開始,提供了 WatchService API供應(yīng)用程序監(jiān)聽文件系統(tǒng)事件,可監(jiān)聽事件包括文件和目錄新建、刪除和修改事件.

1.3 現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法的不足

Linux內(nèi)核文件系統(tǒng)變化通知機(jī)制中,dnotify由于存在諸多不足,fanotify由于支持的事件類型太少,均無法滿足需要.所以,現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法一般基于inotify實(shí)現(xiàn).

在桌面環(huán)境中,文件和目錄頻繁發(fā)生變化,桌面索引的實(shí)時(shí)更新對(duì)文件系統(tǒng)事件的監(jiān)聽過程提出了實(shí)時(shí)、高效、無遺漏的要求.由于inotify的單個(gè)監(jiān)視無法監(jiān)聽子目錄內(nèi)部的事件,所以若要監(jiān)聽某一目錄范圍內(nèi)所有支持的文件系統(tǒng)事件,需為其所有子目錄添加監(jiān)視.這意味著桌面索引更新系統(tǒng)若要無遺漏的監(jiān)控文件系統(tǒng)事件,需要為所有子目錄添加監(jiān)視.因?yàn)檎嬲l(fā)生變化的子目錄數(shù)目相對(duì)較少,所以這種方式必然會(huì)添加大量無效的監(jiān)視.例如,Linux中/home目錄的子目錄個(gè)數(shù)可能達(dá)到上萬個(gè),這意味著若要監(jiān)聽/home目錄范圍所有文件系統(tǒng)事件,添加的無效監(jiān)視可能達(dá)到數(shù)千甚至上萬個(gè).而且,若監(jiān)視超過默認(rèn)值,需要修改系統(tǒng)配置文件,這也帶來不必要的麻煩.JNotify采用的就是這種方式,這種方式導(dǎo)致監(jiān)視的數(shù)目會(huì)隨子目錄層數(shù)的增長呈指數(shù)增長.監(jiān)視數(shù)目的增長會(huì)帶來兩方面問題:1)大量的監(jiān)視會(huì)導(dǎo)致初始化耗時(shí)增加、監(jiān)控效率下降; 2)每個(gè)監(jiān)視與子目錄相關(guān)聯(lián),子目錄更改后需要增刪監(jiān)視,而大量監(jiān)視的維護(hù)與頻繁增刪操作過程復(fù)雜.

此外,現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法的事件通知中存在很多冗余信息,這會(huì)導(dǎo)致桌面索引更新系統(tǒng)進(jìn)行無效的更新操作或?qū)е滤饕率?例如,當(dāng)用戶打開一個(gè)文檔進(jìn)行修改時(shí),編輯器一般會(huì)新建一個(gè)臨時(shí)文件,而這個(gè)臨時(shí)文件的內(nèi)容是不應(yīng)該被索引的,索引它會(huì)導(dǎo)致桌面索引中存在無效內(nèi)容.

綜上,現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法無法滿足桌面索引實(shí)時(shí)更新的性能和功能需要,所以本文提出了一個(gè)Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法,克服了現(xiàn)有方法的典型缺點(diǎn).

2 一種Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法

文件系統(tǒng)事件監(jiān)聽方法是索引實(shí)時(shí)更新的核心,針對(duì)現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法的缺點(diǎn),基于Linux內(nèi)核文件系統(tǒng)變化通知機(jī)制,提出一種Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法并實(shí)現(xiàn).

2.1 方法的執(zhí)行流程

現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法為所有子目錄添加監(jiān)視,需要維護(hù)的監(jiān)視數(shù)目隨子目錄層數(shù)的增加而成指數(shù)增長,大量的監(jiān)視提升了初始化耗時(shí)、維護(hù)成本等.相比而言,Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法對(duì)用戶操作子目錄行為進(jìn)行監(jiān)控,只為可能發(fā)生文件變化的子目錄添加監(jiān)視.既能夠無遺漏地監(jiān)聽指定目錄范圍中所有支持的文件系統(tǒng)事件,也大大減少了對(duì)無關(guān)子目錄的監(jiān)控,只需維護(hù)極少數(shù)目的監(jiān)視.另外,根據(jù)異常文件名稱、文件是否存在、特殊符號(hào)等規(guī)則過濾了冗余信息.

Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法的輸入信息:待監(jiān)控目錄、禁止監(jiān)控的子目錄,輸出信息:發(fā)生變化的文件、變化類型(新增、刪除、修改、重命名).

如圖1,描述了Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法的工作流程,主要包括三步.

圖1 Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法流程圖

步驟1.對(duì)待監(jiān)控目錄的子目錄打開和關(guān)閉事件進(jìn)行監(jiān)聽,基于規(guī)則過濾冗余信息.監(jiān)聽到子目錄打開或關(guān)閉事件后,將打開的子目錄信息添加到監(jiān)控目錄列表中,并從監(jiān)控目錄列表中刪除關(guān)閉了的子目錄信息.同時(shí)觸發(fā)監(jiān)控目錄列表變化事件,該事件中包含兩個(gè)關(guān)鍵信息:目錄名稱、操作類型(添加或刪除).其中,監(jiān)控列表的長度由系統(tǒng)設(shè)定,當(dāng)達(dá)到最大長度時(shí)采用LRU算法替換列表中的數(shù)據(jù).

步驟2.監(jiān)聽監(jiān)控目錄列表變化事件.監(jiān)聽到事件后,根據(jù)操作類型和目錄名稱添加或刪除某個(gè)子目錄的監(jiān)視.

步驟3.每個(gè)監(jiān)視監(jiān)聽目錄中文件或直接子目錄的新建、刪除、修改、重命名四種事件.監(jiān)聽到事件后,首先根據(jù)文件名稱是否合法、隱藏屬性、文件是否存在等規(guī)則過濾臨時(shí)文件、緩存文件等引發(fā)的事件通知,并通知外部應(yīng)用.

2.2 監(jiān)聽系統(tǒng)實(shí)現(xiàn)

基于Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法設(shè)計(jì)并實(shí)現(xiàn)了相應(yīng)系統(tǒng).系統(tǒng)包括三個(gè)模塊:用戶目錄操作行為監(jiān)控、監(jiān)控目錄存儲(chǔ)和文件系統(tǒng)事件監(jiān)聽,如圖2所示.

圖2 實(shí)時(shí)監(jiān)聽系統(tǒng)架構(gòu)圖

用戶目錄操作行為監(jiān)控模塊負(fù)責(zé)監(jiān)聽待監(jiān)控目錄中所有子目錄打開和關(guān)閉事件,并依據(jù)設(shè)置的禁止監(jiān)控子目錄過濾事件.該模塊基于fanotify實(shí)現(xiàn).

監(jiān)控目錄存儲(chǔ)模塊負(fù)責(zé)維護(hù)監(jiān)控目錄列表,它根據(jù)用戶目錄操作行為監(jiān)控模塊監(jiān)聽到的子目錄打開和關(guān)閉事件增加或刪除監(jiān)控目錄列表中的數(shù)據(jù)并發(fā)送事件通知給文件系統(tǒng)事件監(jiān)聽模塊.該模塊基于Java LinkedHashMap實(shí)現(xiàn).

文件系統(tǒng)事件監(jiān)聽模塊負(fù)責(zé)根據(jù)監(jiān)聽到的監(jiān)控目錄列表變化事件添加或刪除子目錄的監(jiān)視,每個(gè)監(jiān)視負(fù)責(zé)監(jiān)聽目錄中文件和直接子目錄新增、刪除、修改、重命名事件.當(dāng)事件發(fā)生時(shí),文件系統(tǒng)事件監(jiān)聽模塊通知使用該機(jī)制的外部應(yīng)用.該模塊基于對(duì)inotify的Java封裝API實(shí)現(xiàn).

3 一種桌面索引實(shí)時(shí)更新方法

桌面索引更新過程可以細(xì)分為三個(gè)步驟:1)及時(shí)獲取發(fā)生變化的文件或目錄; 2)基于文件系統(tǒng)事件類型采取合適的策略更新索引; 3)快速獲取發(fā)生變化的文件或目錄的信息.本文提出一種基于文件系統(tǒng)事件監(jiān)控的桌面索引實(shí)時(shí)更新方法,針對(duì)以上三個(gè)步驟分別給出了方案:1)基于Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法及時(shí)獲取文件和目錄的變化; 2)根據(jù)發(fā)生變化的是文件或目錄以及變化類型選擇優(yōu)化的索引更新策略,避免目錄發(fā)生變化時(shí)大規(guī)模更新甚至重建索引; 3)在索引更新系統(tǒng)的實(shí)現(xiàn)中,提出并采用了多種性能優(yōu)化策略來提高文件信息提取速度.

方案1)的具體實(shí)現(xiàn)已在上一節(jié)詳述,方案3)中具體的優(yōu)化策略將在下一節(jié)詳述,下面重點(diǎn)敘述方案2).

在基于周期性遍歷的索引更新方法中,無法監(jiān)聽文件系統(tǒng)事件,所以也就無法根據(jù)文件系統(tǒng)事件類型優(yōu)化索引更新策略.在基于文件系統(tǒng)事件監(jiān)聽的桌面索引更新方法中,當(dāng)監(jiān)聽到文件系統(tǒng)事件時(shí),根據(jù)發(fā)生事件的主體是文件或目錄以及事件類型選擇合適的索引更新策略.在Lucene等開源搜索引擎的倒排索引結(jié)構(gòu)中,數(shù)據(jù)存儲(chǔ)在邏輯上有Document、Field等概念,分別可以類比為關(guān)系數(shù)據(jù)庫中的一行記錄和列.在本方法中,一個(gè)文件的信息在桌面索引中對(duì)應(yīng)一個(gè)Document,每個(gè) Document都有一個(gè)唯一 ID,我們將其設(shè)置為文件的絕對(duì)路徑,具體的索引更新策略如表3所示.

表3 針對(duì)不同事件主體和類型的索引更新策略

圖3為基于文件系統(tǒng)監(jiān)控的桌面索引實(shí)時(shí)更新方法執(zhí)行流程,包括如下步驟:

步驟1.讀取配置文件并判斷其是否合法.

步驟2.獲取用戶配置的可索引目錄,監(jiān)聽該目錄范圍所有文件系統(tǒng)事件.若目錄新增事件發(fā)生,跳轉(zhuǎn)到步驟3.若文件新增、修改或重命名事件發(fā)生,跳轉(zhuǎn)到步驟4.若文件刪除事件發(fā)生,則跳轉(zhuǎn)到步驟7.若目錄刪除、修改或重命名事件發(fā)生,跳轉(zhuǎn)到步驟8.

步驟3.掃描所有文件,獲取格式符合要求的所有文檔.

步驟4.抽取文件的內(nèi)容,同時(shí)獲取文件的元數(shù)據(jù):文件名、文件格式、絕對(duì)路徑.其中,若文件格式不屬于用戶規(guī)定的可抽取格式,則將其文件內(nèi)容字段置為空.

步驟5.對(duì)步驟4獲得的文件內(nèi)容和元數(shù)據(jù)進(jìn)行分詞,擴(kuò)充部分字段.

步驟6.以文件絕對(duì)路徑作為ID,在索引中添加文檔,結(jié)束.

步驟 7.獲取文件絕對(duì)路徑,匹配索引中的 ID,刪除相應(yīng)文檔,結(jié)束.

步驟 8.若為目錄刪除事件,獲取目錄絕對(duì)路徑,以前綴匹配方式獲取索引中所有相關(guān)文檔并批量刪除.若為目錄修改或重命名事件,獲取目錄絕對(duì)路徑,以前綴匹配方式獲取索引中所有相關(guān)文檔更新其ID和絕對(duì)路徑字段,結(jié)束.

圖3 桌面索引實(shí)時(shí)更新方法流程圖

4 桌面索引實(shí)時(shí)更新系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

基于本文提出的桌面索引實(shí)時(shí)更新方法,設(shè)計(jì)和實(shí)現(xiàn)了桌面索引實(shí)時(shí)更新系統(tǒng).

4.1 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)

如圖4所示,本系統(tǒng)由日志記錄、配置管理、事件感知、文本抽取、文本分析、索引更新六個(gè)模塊組成.其中,所有模塊均調(diào)用日志記錄模塊,在圖4 中省略日志記錄模塊.

圖4 桌面索引實(shí)時(shí)更新系統(tǒng)框架圖

日志記錄模塊負(fù)責(zé)記錄系統(tǒng)索引文檔的過程信息及可能出現(xiàn)的錯(cuò)誤,便于系統(tǒng)異常時(shí)查錯(cuò); 配置管理模塊負(fù)責(zé)管理用戶配置信息; 事件感知模塊負(fù)責(zé)監(jiān)聽可索引目錄中文件系統(tǒng)事件; 文本抽取模塊負(fù)責(zé)抽取文件內(nèi)容和元數(shù)據(jù); 文本分析模塊負(fù)責(zé)為文件內(nèi)容和元數(shù)據(jù)做分詞等后續(xù)處理; 索引更新模塊負(fù)責(zé)更新倒排索引.

4.2 系統(tǒng)實(shí)現(xiàn)

本系統(tǒng)使用C、Java開發(fā),在Linux操作系統(tǒng)實(shí)現(xiàn).

日志記錄模塊記錄如下信息:被索引文件元數(shù)據(jù)信息、索引過程信息、系統(tǒng)異常信息.根據(jù)日志信息的級(jí)別將其輸出至日志文件或運(yùn)行窗口.該模塊基于Apache log4j庫實(shí)現(xiàn).

配置管理模塊將所有配置信息以鍵值對(duì)形式存儲(chǔ)在程序根目錄的“config.properties”文件中,用戶可修改該文件以靈活定制索引選項(xiàng).配置管理模塊在系統(tǒng)啟動(dòng)時(shí)首先判斷配置文件是否存在并檢測配置信息是否合理,然后獲取配置信息并提供給其他模塊.用戶可配置的選項(xiàng)包括:可索引目錄、禁止索引目錄、可索引文件格式、可抽取文件格式.

事件感知模塊基于對(duì)用戶操作目錄行為的監(jiān)控,只為可能發(fā)生文件變化的子目錄添加監(jiān)視,每個(gè)監(jiān)視負(fù)責(zé)監(jiān)聽單個(gè)目錄中文件和直接子目錄的新增、刪除、修改、重命名事件,但不包括其子目錄中的文件系統(tǒng)事件.該模塊基于Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法實(shí)現(xiàn).

文本抽取模塊抽取了Word、Pdf、Txt、PPT、JPG等常見格式文件的內(nèi)容和元數(shù)據(jù),抽取的信息包括:文件名稱、絕對(duì)路徑、文件格式、文件內(nèi)容.該模塊基于 Apache Tika[11]實(shí)現(xiàn),Tika 在搜索引擎、文本分析、文本翻譯等場景中應(yīng)用廣泛[12-14].

文本分析模塊基于IkAnalyzer[15]分詞工具實(shí)現(xiàn),對(duì)抽取模塊得到的部分字段進(jìn)行分詞,同時(shí)擴(kuò)充部分字段.

索引更新模塊基于 Apache Lucene[16]實(shí)現(xiàn),負(fù)責(zé)基于桌面文檔的變化更新倒排索引.Lucene將復(fù)雜的索引和檢索過程以簡單的接口呈現(xiàn)給應(yīng)用[17],在桌面搜索場景有廣泛應(yīng)用[18].

4.3 系統(tǒng)性能優(yōu)化

桌面索引實(shí)時(shí)更新既需要及時(shí)獲取文件系統(tǒng)變化,也需要快速完成文檔索引.分析和測試了索引過程各個(gè)階段的耗時(shí),提出并應(yīng)用了多種優(yōu)化策略以加快索引速度.

混合抽取策略.Tika作為抽取框架,為不同格式文件提供了統(tǒng)一的抽取接口.Tika抽取文件內(nèi)容包括三步:文件類型檢測、文件解析器選擇、內(nèi)容抽取.若跳過前兩步,直接抽取文檔將提升文本抽取速度.因?yàn)镻DF文件抽取相對(duì)較慢,基于加快抽取速度和保證不同文件格式抽取接口統(tǒng)一性的考慮,決定對(duì)PDF文件的抽取速度進(jìn)行重點(diǎn)優(yōu)化.首先,通過實(shí)驗(yàn)比較了不同數(shù)據(jù)集下Tika和Pdfbox抽取PDF的速度.

表4 抽取測試數(shù)據(jù)集

表5 pdf抽取測試結(jié)果

通過以上實(shí)驗(yàn)發(fā)現(xiàn),對(duì)小文件的抽取,Pdfbox快于 Tika.而對(duì)于大文件,Pdfbox 慢于 Tika.基于以上結(jié)果,系統(tǒng)采取如下混合抽取策略:

1)若文件格式為 PDF,且大小小于 1 MB,直接調(diào)用Pdfbox抽取.

2)其余文件調(diào)用org.apache.tika.parser.Parser類抽取.

多線程處理.文本抽取和分詞耗時(shí)較長,所以采用多線程方式處理.為兼顧速度與系統(tǒng)資源占用,多線程基于以下原則:1)單個(gè)線程處理的文件數(shù)目固定; 2)線程數(shù)目由文件總數(shù)決定,但不超過最大值.

在系統(tǒng)實(shí)現(xiàn)中,使用StringBuffer代替String進(jìn)行字符串拼接等操作.

綜合使用以上優(yōu)化方法,索引速度得到了極大提升,其中,混合抽取策略的提速效果最為突出.

5 實(shí)驗(yàn)

實(shí)驗(yàn)測試包括四項(xiàng):測試Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法的延遲; 測試桌面索引實(shí)時(shí)更新方法的延遲;測試桌面索引實(shí)時(shí)更新系統(tǒng)的索引速度并與DocFetcher、Recoll的索引系統(tǒng)進(jìn)行比較; 測試并比較桌面索引實(shí)時(shí)更新方法與基于周期性全盤掃描的索引更新方法的內(nèi)存占用.

5.1 實(shí)驗(yàn)準(zhǔn)備

四項(xiàng)實(shí)驗(yàn)測試均基于Eclipse開發(fā)環(huán)境,Ubuntu 64 位操作系統(tǒng),采用 Intel(R)Core(TM)i7-2600 CPU、14 GB內(nèi)存和1 TB硬盤的硬件平臺(tái).

第一項(xiàng)和第二項(xiàng)實(shí)驗(yàn)均通過連續(xù)復(fù)制單個(gè)文件到指定目錄觸發(fā)文件新建事件以及桌面索引更新,模擬發(fā)生文件系統(tǒng)事件時(shí)的事件通知和索引更新過程.

第三項(xiàng)實(shí)驗(yàn),即索引速度對(duì)比實(shí)驗(yàn)選取的對(duì)比系統(tǒng)為 DocFetcher 1.17 和 Recoll 1.21.5,均為這兩款桌面搜索引擎的最新版本.Linux平臺(tái)上優(yōu)秀的桌面搜索引擎有 Google Desktop Search、Beagle、DocFetcher、Recoll等,但前兩者均已停止更新較長時(shí)間.DocFetcher是一款開源、跨平臺(tái)的桌面全文搜索軟件,支持多種格式文檔的快速索引和檢索[19].Recoll是一款基于Xapian開源搜索引擎的桌面全文桌面搜索工具,它提供了強(qiáng)大的文本抽取層和完整、易用的基于Qt的界面[20].第三項(xiàng)實(shí)驗(yàn)中使用的數(shù)據(jù)集信息如表6所示.

表6 實(shí)驗(yàn)數(shù)據(jù)集信息

5.2 實(shí)驗(yàn)結(jié)果和分析

第一項(xiàng)實(shí)驗(yàn)測試了在發(fā)生不同數(shù)目的文件系統(tǒng)事件時(shí),本文提出的Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法的平均延遲時(shí)間.如圖5,隨著文件系統(tǒng)事件的增多,本方法監(jiān)聽到單個(gè)事件的平均延遲時(shí)間穩(wěn)定在1 ms左右,沒有出現(xiàn)大幅增加或減少.相比現(xiàn)有方法,本方法僅需維護(hù)數(shù)目極少的監(jiān)視即可實(shí)現(xiàn)對(duì)指定目錄范圍發(fā)生的文件系統(tǒng)事件的無遺漏監(jiān)聽,降低了監(jiān)視維護(hù)的復(fù)雜性及耗時(shí),能夠穩(wěn)定、實(shí)時(shí)地持續(xù)監(jiān)聽文件系統(tǒng)事件.

圖5 文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法平均延遲時(shí)間

第二項(xiàng)實(shí)驗(yàn)測試了在發(fā)生不同數(shù)目的文件系統(tǒng)事件時(shí),本文提出的桌面索引實(shí)時(shí)更新方法平均延遲時(shí)間.圖6 顯示,隨著文件系統(tǒng)事件的增多,桌面索引更新的平均延遲時(shí)間穩(wěn)定在90 ms內(nèi),延遲低.

圖6 桌面索引實(shí)時(shí)更新方法平均延遲時(shí)間

第三項(xiàng)實(shí)驗(yàn)測試了本文實(shí)現(xiàn)的桌面索引實(shí)時(shí)更新系統(tǒng)的索引速度并與其它系統(tǒng)對(duì)比.如圖7,隨著文件數(shù)目的增加,三個(gè)系統(tǒng)耗時(shí)均不斷增加,其中Recoll隨著文件數(shù)目的增加性能下降最為嚴(yán)重,本系統(tǒng)的耗時(shí)遠(yuǎn)低于DocFetcher和Recoll.需要說明的是,具體的測試數(shù)據(jù)與使用的數(shù)據(jù)集和硬件性能相關(guān).

第四項(xiàng)實(shí)驗(yàn)對(duì)比本文提出的桌面索引實(shí)時(shí)更新方法與周期性索引更新方法的內(nèi)存占用,如圖8所示.可以發(fā)現(xiàn),本方法內(nèi)存占用少,而且較為穩(wěn)定.需要說明的是,內(nèi)存占用的具體數(shù)值與實(shí)驗(yàn)的條件有關(guān).本實(shí)驗(yàn)通過每五秒鐘新建一個(gè)文件來模擬文檔集的變化,周期性掃描的時(shí)間間隔為20秒,每隔一秒采集一次內(nèi)存信息,持續(xù)采集150秒.

圖7 索引速度比較圖

圖8 內(nèi)存占用對(duì)比圖

6 結(jié)語

現(xiàn)有桌面索引更新方法采用的周期性索引更新策略存在延遲大、系統(tǒng)資源占用高等缺點(diǎn).針對(duì)這些弊端,本文提出并實(shí)現(xiàn)了一種基于文件系統(tǒng)事件監(jiān)聽的桌面索引實(shí)時(shí)更新方法,無需定時(shí)掃描全盤即可保證桌面文檔與索引內(nèi)容完全一致.為了實(shí)現(xiàn)高效、低延遲地監(jiān)控文件系統(tǒng)事件,研究了現(xiàn)有Linux文件系統(tǒng)事件監(jiān)聽方法,針對(duì)其不足,提出并實(shí)現(xiàn)了一種Linux文件系統(tǒng)事件實(shí)時(shí)監(jiān)聽方法,僅需維護(hù)極少數(shù)目的監(jiān)視即可實(shí)現(xiàn)對(duì)文件系統(tǒng)事件的無遺漏監(jiān)聽,而且也對(duì)冗余的事件通知信息進(jìn)行了有效過濾.

在處理目錄刪除、重命名事件時(shí),采取了批量更新倒排索引的策略,避免了大規(guī)模索引更新或重建.在系統(tǒng)的實(shí)現(xiàn)中,綜合應(yīng)用了多種優(yōu)化策略提升索引速度.實(shí)驗(yàn)結(jié)果表明,本文提出的方法在索引更新的延遲時(shí)間、系統(tǒng)資源占用方面均有較大提升.本文實(shí)現(xiàn)的系統(tǒng)能夠監(jiān)聽和高效處理文件和目錄的新建、刪除、修改、重命名事件,目錄移動(dòng)和復(fù)制等事件均轉(zhuǎn)化為新建、刪除、修改事件處理.如何從高層語義上監(jiān)聽到移動(dòng)和復(fù)制等事件并針對(duì)其優(yōu)化索引更新策略需要進(jìn)一步研究.

1Cen ZW,Xu JG,Sun J.SoDesktop:A desktop search engine.Proc.of the 2012 International Conference on Communication Systems and Network Technologies (CSNT).Rajkot,India.2012.463–467.

2Morgan S,Mortazavi M,Palani G,et al.Metadata index search in a file system:U.S.Patent 20160063021.2016-03-03.

3Xu L,Jiang H,Tian L,et al.Propeller:A scalable real-time file-search service in distributed systems.Proc.of the 34th International Conference on Distributed Computing Systems(ICDCS).Madrid,Spain.2014.378–388.

4Takata M,Sutoh A.Event-notification-based inactive file search for large-scale file systems.Proc.of the 2012 Digest APMRC.Singapore.2012.1–7.

5Onyisi P.Event-driven messaging for offline data quality monitoring at ATLAS.Proc.of the 21st International Conference on Computing in High Energy and Nuclear Physics (CHEP2015).Okinawa,Japan.2015.

6Shields I.Monitor Linux file system events with inotify.http://www.ibm.com/developerworks/ linux/library/l-inotify/.[2010-09-10].

7McCutchan J,Love R,Griffis A.Inotify-get your file system supervised.http://inotify.aiken.cz/.

8Paris E.Fanotify:The fscking all notification system.https://lwn.net/Articles/339253/.[2009-06-29].

9J Notify File system events library for Java.http://jnotify.sourceforge.net/linux.html.

10黃江平.基于Lucene的桌面搜索引擎的研究與應(yīng)用[碩士學(xué)位論文].杭州:浙江理工大學(xué),2012.

11ASF.Apache Tika-a content analysis toolkit.http://tika.apache.org/.

12Mattmann CA,Zitting JL.Tika in Action.Shelter Island,NY:Manning Publications Co.,2011:28–75.

13Burgess AB,Mattmann CA.Automatically classifying and interpreting polar datasets with Apache Tika.Proc.of the 15th International Conference on Information Reuse and Integration (IRI).Redwood City,CA,USA.2014.863–867.

14王旭仁,鄭秋輝,何發(fā)鎂,等.基于 Tika 和 Lucene 的桌面搜索引擎研究與實(shí)現(xiàn).計(jì)算機(jī)工程與設(shè)計(jì),2014,35(1):310–314.

15IK Analyzer.http://git.oschina.net/wltea/IK-Analyzer-2012FF.

16Lucene.http://lucene.apache.org/.

17McCandless M,Hatcher E,Gospodnetic O.Lucene in Action:Covers Apache Lucene 3.0.2nd ed.Shelter Island,NY:Manning Publications Co.,2010:3–4.

18劉艷,楊奇龍,蔡燕冬.FileFinder:桌面搜索引擎的設(shè)計(jì)與實(shí)現(xiàn).計(jì)算機(jī)工程與設(shè)計(jì),2013,34(7):2627–2631.

19DocFetch.https://sourceforge.net/projects/docfetcher/.

20Recoll.http://www.lesbonscomptes.com/recoll/.

Index Real-Time Updating Method for Desktop Environment

YANG Kai-Fei1,2,LI Wen-Bo1,KE Chuan1,21(National Engineering Research Center of Fundamental Software,Institute of Software,CAS,Beijing 100190,China)2(University of Chinese Academy of Sciences,Beijing 100049,China)

In the desktop computing environment,files and directories are frequently changed,such as being created,deleted,modified,renamed,moved,and copied,which has higher demands on the real-time updating of desktop index and its efficiency.However,the traditional desktop index updating methods are fully or partially dependent on periodically full scan,which inevitably requires a large-scale index reconstruction and leads to long delay of index generation and high usage of system resources.In order to overcome these drawbacks,this paper puts forward a new desktop index real-time updating method based on a new file system events monitoring,and implements corresponding desktop index real-time updating system.Experimental results show that the proposed index updating method provides lower latency and lower usage of system resources.

desktop search; file system monitoring; index update; text extraction; inotify

楊凱飛,李文波,柯川.面向桌面環(huán)境的索引實(shí)時(shí)更新方法.計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(10):20–28.http://www.c-s-a.org.cn/1003-3254/5512.html

國家高技術(shù)研究發(fā)展計(jì)劃(863計(jì)劃)(2013AA01A603)

2016-04-06; 采用時(shí)間:2016-04-27