面向桌面環境的索引實時更新方法①

楊凱飛 ,李文波 ,柯 川

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

面向桌面環境的索引實時更新方法①

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

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

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

桌面搜索; 文件系統監控; 索引更新; 文本抽取; inotify

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

類似于網絡搜索引擎,桌面搜索引擎多采用先為桌面文檔建立索引再提供查詢的方式.這極大地提升了查詢速度,但也帶來了桌面索引更新的問題,桌面索引需及時更新,才能保證其與文檔內容一致.因為桌面文檔頻繁發生新增、刪除、修改、重命名、移動、復制等變化,桌面索引更新的實時性和性能要求更為嚴苛.

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

針對桌面環境的特性和現有桌面索引更新方法的弊端,本文提出了一種基于文件系統事件監聽的桌面索引實時更新方法,無需周期性掃描全盤即可保證索引內容與桌面文檔完全一致.本方法能夠實現對文件系統事件的實時監聽以及快速更新索引內容.我們研究了現有Linux文件系統事件監聽方法,在此基礎上,提出了一種Linux文件系統事件實時監聽方法并實現,克服了現有方法的典型缺點.最后,在Linux操作系統上實現了桌面索引實時更新系統,采用了多種性能優化策略提升其索引速度.實驗表明:本文提出的桌面索引實時更新方法延遲時間短、系統資源占用低.

1 相關工作

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

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

表1 目錄的變化對桌面索引的影響

1.1 Linux內核文件系統變化通知機制

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

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

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

fanotify既可以通知文件系統變化,也可以攔截文件系統變化,應用程序使用fanotify的訪問控制(Access Decision)功能可以決定是否允許其它應用程序對文件的操作[8].fanotify提供三種文件系統變化監控模式:全文件系統監控(Global)、單個掛載點監控(per-mount)、單個對象監控 (Directed).fanotify 不僅可以監控其它程序對文檔和目錄的操作,還能決定是否允許其操作.表2比較了三種機制監聽文件系統事件的特性.

在桌面搜索場景中,Linux內核文件系統變化通知機制有兩點主要不足:

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

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

1.2 第三方的文件系統事件監聽庫

通過封裝Linux內核提供的文件系統變化通知機制,第三方的文件系統事件監聽庫函數也可為應用程序提供對文件系統事件的實時監聽.下面對兩個提供Java API的監聽庫進行重點研究.

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

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

1.3 現有Linux文件系統事件監聽方法的不足

Linux內核文件系統變化通知機制中,dnotify由于存在諸多不足,fanotify由于支持的事件類型太少,均無法滿足需要.所以,現有Linux文件系統事件監聽方法一般基于inotify實現.

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

此外,現有Linux文件系統事件監聽方法的事件通知中存在很多冗余信息,這會導致桌面索引更新系統進行無效的更新操作或導致索引更新失敗.例如,當用戶打開一個文檔進行修改時,編輯器一般會新建一個臨時文件,而這個臨時文件的內容是不應該被索引的,索引它會導致桌面索引中存在無效內容.

綜上,現有Linux文件系統事件監聽方法無法滿足桌面索引實時更新的性能和功能需要,所以本文提出了一個Linux文件系統事件實時監聽方法,克服了現有方法的典型缺點.

2 一種Linux文件系統事件實時監聽方法

文件系統事件監聽方法是索引實時更新的核心,針對現有Linux文件系統事件監聽方法的缺點,基于Linux內核文件系統變化通知機制,提出一種Linux文件系統事件實時監聽方法并實現.

2.1 方法的執行流程

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

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

如圖1,描述了Linux文件系統事件實時監聽方法的工作流程,主要包括三步.

圖1 Linux文件系統事件實時監聽方法流程圖

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

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

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

2.2 監聽系統實現

基于Linux文件系統事件實時監聽方法設計并實現了相應系統.系統包括三個模塊:用戶目錄操作行為監控、監控目錄存儲和文件系統事件監聽,如圖2所示.

圖2 實時監聽系統架構圖

用戶目錄操作行為監控模塊負責監聽待監控目錄中所有子目錄打開和關閉事件,并依據設置的禁止監控子目錄過濾事件.該模塊基于fanotify實現.

監控目錄存儲模塊負責維護監控目錄列表,它根據用戶目錄操作行為監控模塊監聽到的子目錄打開和關閉事件增加或刪除監控目錄列表中的數據并發送事件通知給文件系統事件監聽模塊.該模塊基于Java LinkedHashMap實現.

文件系統事件監聽模塊負責根據監聽到的監控目錄列表變化事件添加或刪除子目錄的監視,每個監視負責監聽目錄中文件和直接子目錄新增、刪除、修改、重命名事件.當事件發生時,文件系統事件監聽模塊通知使用該機制的外部應用.該模塊基于對inotify的Java封裝API實現.

3 一種桌面索引實時更新方法

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

方案1)的具體實現已在上一節詳述,方案3)中具體的優化策略將在下一節詳述,下面重點敘述方案2).

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

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

圖3為基于文件系統監控的桌面索引實時更新方法執行流程,包括如下步驟:

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

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

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

步驟4.抽取文件的內容,同時獲取文件的元數據:文件名、文件格式、絕對路徑.其中,若文件格式不屬于用戶規定的可抽取格式,則將其文件內容字段置為空.

步驟5.對步驟4獲得的文件內容和元數據進行分詞,擴充部分字段.

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

步驟 7.獲取文件絕對路徑,匹配索引中的 ID,刪除相應文檔,結束.

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

圖3 桌面索引實時更新方法流程圖

4 桌面索引實時更新系統設計與實現

基于本文提出的桌面索引實時更新方法,設計和實現了桌面索引實時更新系統.

4.1 系統結構設計

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

圖4 桌面索引實時更新系統框架圖

日志記錄模塊負責記錄系統索引文檔的過程信息及可能出現的錯誤,便于系統異常時查錯; 配置管理模塊負責管理用戶配置信息; 事件感知模塊負責監聽可索引目錄中文件系統事件; 文本抽取模塊負責抽取文件內容和元數據; 文本分析模塊負責為文件內容和元數據做分詞等后續處理; 索引更新模塊負責更新倒排索引.

4.2 系統實現

本系統使用C、Java開發,在Linux操作系統實現.

日志記錄模塊記錄如下信息:被索引文件元數據信息、索引過程信息、系統異常信息.根據日志信息的級別將其輸出至日志文件或運行窗口.該模塊基于Apache log4j庫實現.

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

事件感知模塊基于對用戶操作目錄行為的監控,只為可能發生文件變化的子目錄添加監視,每個監視負責監聽單個目錄中文件和直接子目錄的新增、刪除、修改、重命名事件,但不包括其子目錄中的文件系統事件.該模塊基于Linux文件系統事件實時監聽方法實現.

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

文本分析模塊基于IkAnalyzer[15]分詞工具實現,對抽取模塊得到的部分字段進行分詞,同時擴充部分字段.

索引更新模塊基于 Apache Lucene[16]實現,負責基于桌面文檔的變化更新倒排索引.Lucene將復雜的索引和檢索過程以簡單的接口呈現給應用[17],在桌面搜索場景有廣泛應用[18].

4.3 系統性能優化

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

混合抽取策略.Tika作為抽取框架,為不同格式文件提供了統一的抽取接口.Tika抽取文件內容包括三步:文件類型檢測、文件解析器選擇、內容抽取.若跳過前兩步,直接抽取文檔將提升文本抽取速度.因為PDF文件抽取相對較慢,基于加快抽取速度和保證不同文件格式抽取接口統一性的考慮,決定對PDF文件的抽取速度進行重點優化.首先,通過實驗比較了不同數據集下Tika和Pdfbox抽取PDF的速度.

表4 抽取測試數據集

表5 pdf抽取測試結果

通過以上實驗發現,對小文件的抽取,Pdfbox快于 Tika.而對于大文件,Pdfbox 慢于 Tika.基于以上結果,系統采取如下混合抽取策略:

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

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

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

在系統實現中,使用StringBuffer代替String進行字符串拼接等操作.

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

5 實驗

實驗測試包括四項:測試Linux文件系統事件實時監聽方法的延遲; 測試桌面索引實時更新方法的延遲;測試桌面索引實時更新系統的索引速度并與DocFetcher、Recoll的索引系統進行比較; 測試并比較桌面索引實時更新方法與基于周期性全盤掃描的索引更新方法的內存占用.

5.1 實驗準備

四項實驗測試均基于Eclipse開發環境,Ubuntu 64 位操作系統,采用 Intel(R)Core(TM)i7-2600 CPU、14 GB內存和1 TB硬盤的硬件平臺.

第一項和第二項實驗均通過連續復制單個文件到指定目錄觸發文件新建事件以及桌面索引更新,模擬發生文件系統事件時的事件通知和索引更新過程.

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

表6 實驗數據集信息

5.2 實驗結果和分析

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

圖5 文件系統事件實時監聽方法平均延遲時間

第二項實驗測試了在發生不同數目的文件系統事件時,本文提出的桌面索引實時更新方法平均延遲時間.圖6 顯示,隨著文件系統事件的增多,桌面索引更新的平均延遲時間穩定在90 ms內,延遲低.

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

第三項實驗測試了本文實現的桌面索引實時更新系統的索引速度并與其它系統對比.如圖7,隨著文件數目的增加,三個系統耗時均不斷增加,其中Recoll隨著文件數目的增加性能下降最為嚴重,本系統的耗時遠低于DocFetcher和Recoll.需要說明的是,具體的測試數據與使用的數據集和硬件性能相關.

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

圖7 索引速度比較圖

圖8 內存占用對比圖

6 結語

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

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

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的桌面搜索引擎的研究與應用[碩士學位論文].杭州:浙江理工大學,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王旭仁,鄭秋輝,何發鎂,等.基于 Tika 和 Lucene 的桌面搜索引擎研究與實現.計算機工程與設計,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:桌面搜索引擎的設計與實現.計算機工程與設計,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

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

國家高技術研究發展計劃(863計劃)(2013AA01A603)

2016-04-06; 采用時間:2016-04-27