| 2007 年 11 月 27 日 為應用程序添加搜索能力經(jīng)常是一個(gè)常見(jiàn)的需求。本文介紹了一個(gè)框架，開(kāi)發(fā)者可以使用它以最小的付出實(shí)現搜索引擎功能，理想情況下只需要一個(gè)配置文件。該框 架基于若干開(kāi)源的庫和工具，如 Apache Lucene，Spring 框架，cpdetector 等。它支持多種資源。其中兩個(gè)典型的例子是數據庫資源和文件系統資源。Indexer 對配置的資源進(jìn)行索引并傳輸到中央服務(wù)器，之后這些索引可以通過(guò) API 進(jìn)行搜索。Spring 風(fēng)格的配置文件允許清晰靈活的自定義和調整。核心 API 也提供了可擴展的接口。 引言 為 應用程序添加搜索能力經(jīng)常是一個(gè)常見(jiàn)的需求。盡管已經(jīng)有若干程序庫提供了對搜索基礎設施的支持，然而對于很多人而言，使用它們從頭開(kāi)始建立一個(gè)搜索引擎將 是一個(gè)付出不小而且可能乏味的過(guò)程。另一方面，很多的小型應用對于搜索功能的需求和應用場(chǎng)景具有很大的相似性。本文試圖以對多數小型應用的適用性為出發(fā) 點(diǎn)，用 Java 語(yǔ)言構建一個(gè)靈活的搜索引擎框架。使用這個(gè)框架，多數情形下可以以最小的付出建立起一個(gè)搜索引擎。最理想的情況下，甚至只需要一個(gè)配置文件。特殊的情形 下，可以通過(guò)靈活地對框架進(jìn)行擴展滿(mǎn)足需求。當然，如題所述，這都是借助開(kāi)源工具的力量。
基礎知識 Apache Lucene 是開(kāi)發(fā)搜索類(lèi)應用程序時(shí)最常用的 Java 類(lèi)庫，我們的框架也將基于它。為了下文更好的描述，我們需要先了解一些有關(guān) Lucene 和搜索的基礎知識。注意，本文不關(guān)注索引的文件格式、分詞技術(shù)等話(huà)題。 什么是搜索和索引 從 用戶(hù)的角度來(lái)看，搜索的過(guò)程是通過(guò)關(guān)鍵字在某種資源中尋找特定的內容的過(guò)程。而從計算機的角度來(lái)看，實(shí)現這個(gè)過(guò)程可以有兩種辦法。一是對所有資源逐個(gè)與關(guān) 鍵字匹配，返回所有滿(mǎn)足匹配的內容；二是如同字典一樣事先建立一個(gè)對應表，把關(guān)鍵字與資源的內容對應起來(lái)，搜索時(shí)直接查找這個(gè)表即可。顯而易見(jiàn)，第二個(gè)辦 法效率要高得多。建立這個(gè)對應表事實(shí)上就是建立逆向索引（inverted index）的過(guò)程。 Lucene 基本概念 Lucene 是 Doug Cutting 用 Java 開(kāi)發(fā)的用于全文搜索的工具庫。在這里，我假設讀者對其已有基本的了解，我們只對一些重要的概念簡(jiǎn)要介紹。要深入了解可以參考 參考資源 中列出的相關(guān)文章和圖書(shū)。下面這些是 Lucene 里比較重要的類(lèi)。 -
Document：索引包含多個(gè) Document。而每個(gè) Document 則包含多個(gè) Field 對象。Document 可以是從數據庫表里取出的一堆數據，可以是一個(gè)文件，也可以是一個(gè)網(wǎng)頁(yè)等。注意，它不等同于文件系統中的文件。 -
Field：一個(gè) Field 有一個(gè)名稱(chēng)，它對應 Document的一部分數據，表示文檔的內容或者文檔的元數據（與下文中提到的資源元數據不是一個(gè)概念）。一個(gè) Field 對象有兩個(gè)重要屬性：Store ( 可以有 YES, NO, COMPACT 三種取值 ) 和 Index ( 可以有 TOKENIZED, UN_TOKENIZED, NO, NO_NORMS 四種取值 ) -
Query：抽象了搜索時(shí)使用的語(yǔ)句。 -
IndexSearcher：提供 Query 對象給它，它利用已有的索引進(jìn)行搜索并返回搜索結果。 -
Hits：一個(gè)容器，包含了指向一部分搜索結果的指針。 使用 Lucene 來(lái)進(jìn)行編制索引的過(guò)程大致為：將輸入的數據源統一為字符串或者文本流的形式，然后從數據源提取數據，創(chuàng )建合適的 Field 添加到對應數據源的 Document 對象之中。
系統概覽 要 建立一個(gè)通用的框架，必須對不同情況的共性進(jìn)行抽象。反映到設計需要注意兩點(diǎn)。一是要提供擴展接口；二是要盡量降低模塊之間的耦合程度。我們的框架很簡(jiǎn)單 地分為兩個(gè)模塊：索引模塊和搜索模塊。索引模塊在不同的機器上各自進(jìn)行對資源的索引，并把索引文件（事實(shí)上，下面我們會(huì )說(shuō)到，還有元數據）統一傳輸到同一 個(gè)地方（可以是在遠程服務(wù)器上，也可以是在本地）。搜索模塊則利用這些從多個(gè)索引模塊收集到的數據完成用戶(hù)的搜索請求。 圖 1 展現了整體的框架?？梢钥吹?，兩個(gè)模塊之間相對是獨立的，它們之間的關(guān)聯(lián)不是通過(guò)代碼，而是通過(guò)索引和元數據。在下文中，我們將會(huì )詳細介紹如何基于開(kāi)源工具設計和實(shí)現這兩個(gè)模塊。
圖 1. 系統架構圖
建立索引 可以進(jìn)行索引的對象有很多，如文件、網(wǎng)頁(yè)、RSS Feed 等。在我們的框架中，我們定義可以進(jìn)行索引的一類(lèi)對象為資源。從實(shí)現細節上來(lái)說(shuō)，從一個(gè)資源中可以提取出多個(gè) Document 對象。文件系統資源和數據庫結果集資源都是資源的代表性例子。 前面提到，從資源中收集到的索引被統一傳送到同一個(gè)地方，以被搜索模塊所用。顯然除了索引之外，搜索模塊需要對資源有更多的了解，如資源的名稱(chēng)、搜索該資源后搜索結果的呈現格式等。這些額外的附加信息稱(chēng)為資源的元數據。元數據和索引數據一同被收集起來(lái)，放置到某個(gè)特定的位置。 簡(jiǎn)要地介紹過(guò)資源的概念之后，我們首先為其定義一個(gè) Resource 接口。這個(gè)接口的聲明如下。
清單 1. Resource 接口
public interface Resource {
// RequestProcessor 對象被動(dòng)地從資源中提取 Document，并返回提取的數量
public int extractDocuments(ResourceProcessor processor);
// 添加的 DocumentListener 將在每一個(gè) Document 對象被提取出時(shí)被調用
public void addDocumentListener(DocumentListener l);
// 返回資源的元數據
public ResourceMetaData getMetaData();
} |
其中元數據包含的字段見(jiàn)下表。在下文中，我們還會(huì )對元數據的用途做更多的介紹。
表 1. 資源元數據包含的字段
而 DocumentListener 的代碼如下。
清單 2. DocumentListener 接口
public interface DocumentListener extends EventListener {
public void documentExtracted(Document doc);
}
|
為了讓索引模塊能夠知道所有需要被索引的資源，我們在這里使用 Spring 風(fēng)格的 XML 文件配置索引模塊中的所有組件，尤其是所有資源。您可以在 下載部分 查看一個(gè)示例配置文件。 | 為什么選擇使用 Spring 風(fēng)格的配置文件？
這主要有兩個(gè)好處： - 僅依賴(lài)于 Spring Core 和 Spring Beans 便免去了定義配置機制和解析配置文件的負擔；
- Spring 的 IoC 機制降低了框架的耦合性，并使擴展框架變得簡(jiǎn)單；
| | 基于以上內容，我們可以大致描述出索引模塊工作的過(guò)程： - 首先在 XML 配置的 bean 中找出所有
Resource 對象； - 對每一個(gè)調用其
extractDocuments() 方法，這一步除了完成對資源的索引外，還會(huì )在每次提取出一個(gè) Document 對象之后，通知注冊在該資源上的所有 DocumentListener； - 接著(zhù)處理資源的元數據（
getMetaData() 的返回值）； - 將緩存里的數據寫(xiě)入到本地磁盤(pán)或者傳送給遠程服務(wù)器；
在這個(gè)過(guò)程中，有兩個(gè)地方值得注意。 第一，對資源可以注冊 DocumentListener 使得我們可以在運行時(shí)刻對索引過(guò)程有更為動(dòng)態(tài)的控制。舉一個(gè)簡(jiǎn)單例子，對某個(gè)文章發(fā)布站點(diǎn)的文章進(jìn)行索引時(shí)，一個(gè)很正常的要求便是發(fā)布時(shí)間更靠近當前時(shí)間的文章需要在搜索結果中排在靠前的位置。每篇文章顯然對應一個(gè) Document 對象，在 Lucene 中我們可以通過(guò)設置 Document 的 boost 值來(lái)對其進(jìn)行加權。假設其中文章發(fā)布時(shí)間的 Field 的名稱(chēng)為 PUB_TIME，那么我們可以為資源注冊一個(gè) DocumentListener，當它被通知時(shí)，則檢測 PUB_TIME 的值，根據距離當前時(shí)間的遠近進(jìn)行加權。 第二點(diǎn)很顯然，在這個(gè)過(guò)程中，extractDocuments() 方法的實(shí)現依不同類(lèi)型的資源而各異。下面我們主要討論兩種類(lèi)型的資源：文件系統資源和數據庫結果集資源。這兩個(gè)類(lèi)都實(shí)現了上面的 接口。 文件系統資源 對文件系統資源的索引通常從一個(gè)基目錄開(kāi)始，遞歸處理每個(gè)需要進(jìn)行索引的文件。該資源有一個(gè)字符串數組類(lèi)型的 excludedFiles 屬性，表示在處理文件時(shí)需要排除的文件絕對路徑的正則表達式。在遞歸遍歷文件系統樹(shù)的同時(shí)，絕對路徑匹配 excludedFiles 中任意一項的文件將不會(huì )被處理。這主要是考慮到一般我們只需要對一部分文件夾（比如排除可能存在的備份目錄）中的一部分文件（如 doc, ppt 文件等）進(jìn)行索引。 除了所有文件共有的文件名、文件路徑、文件大小和修改時(shí)間等 Field，不同類(lèi)型的文件需要有不同的處理方法。為了保留靈活性，我們使用 Strategy 模式封裝對不同類(lèi)型文件的處理方式。為此我們抽象出一個(gè) DocumentBuilder 的接口，該接口僅定義了一個(gè)方法如下：
清單 3. DocumentBuilder 接口
public interface DocumentBuilder {
Document buildDocument(InputStream is);
} |
| 什么是 Strategy 模式？
根 據 Design patterns: Elements of reusable object orientated software 一書(shū)：Strategy 模式“定義一系列的算法，把它們分別封裝起來(lái)，并且使它們相互可以替換。這個(gè)模式使得算法可以獨立于使用它的客戶(hù)而變化?！?/p> | | 不同的 DocumentBuilder（Strategy） 用于從一個(gè)輸入流中讀取數據，處理不同類(lèi)型的文件。對于常見(jiàn)的文件格式來(lái)說(shuō)，都有合適的開(kāi)源工具幫助進(jìn)行解析。在下表中我們列舉一些常見(jiàn)文件類(lèi)型的解析辦法。 | 文件類(lèi)型 | 常用擴展名 | 可以使用的解析辦法 | | 純文本文檔 | txt | 無(wú)需類(lèi)庫解析 | | RTF 文檔 | rtf | 使用 javax.swing.text.rtf.RTFEditorKit 類(lèi) | | Word 文檔（非 OOXML 格式） | doc | Apache POI （可配合使用 POI Scratchpad） | | PowerPoint 演示文稿（非 OOXML 格式） | xls | Apache POI （可配合使用 POI Scratchpad） | | PDF 文檔 | pdf | PDFBox（可能中文支持欠佳） | | HTML 文檔 | htm, html | JTidy, Cobra | 這里以 Word 文件為例，給出一個(gè)簡(jiǎn)單的參考實(shí)現。
清單 4. 解析純文本內容的實(shí)現
// WordDocument 是 Apache POI Scratchpad 中的一個(gè)類(lèi)
Document buildDocument(InputStream is) {
String bodyText = null;
try {
WordDocument wordDoc = new WordDocument(is);
StringWriter sw = new StringWriter();
wordDoc.writeAllText(sw);
sw.close();
bodyText = sw.toString();
} catch (Exception e) {
throw new DocumentHandlerException("Cannot extract text from a Word document", e);
}
if ((bodyText != null) && (bodyText.trim().length() > 0)) {
Document doc = new Document();
doc.add(new Field("body", bodyText, Field.Store.YES, Field.Index.TOKENIZED));
return doc;
}
return null;
}
|
那么如何選擇合適的 Strategy 來(lái)處理文件呢？UNIX 系統下的 file(1) 工具提供了從 magicnumber 獲取文件類(lèi)型的功能，我們可以使用 Runtime.exec() 方法調用這一命令。但這需要在有 file(1) 命令的情況下，而且并不能識別出所有文件類(lèi)型。在一般的情況下我們可以簡(jiǎn)單地根據擴展名來(lái)使用合適的類(lèi)處理文件。擴展名和類(lèi)的映射關(guān)系寫(xiě)在 properties 文件中。當需要添加對新的文件類(lèi)型的支持時(shí)，我們只需添加一個(gè)新的實(shí)現 DocumentBuilder 接口的類(lèi)，并在映射文件中添加一個(gè)映射關(guān)系即可。 數據庫結果集資源 大多數應用使用數據庫作為永久存儲，對數據庫查詢(xún)結果集索引是一個(gè)常見(jiàn)需求。 生成一個(gè)數據庫結果集資源的實(shí)例需要先提供一個(gè)查詢(xún)語(yǔ)句，然后執行查詢(xún)，得到一個(gè)結果集。這個(gè)結果集中的內容便是我們需要進(jìn)行索引的對象。extractDocuments 的實(shí)現便是為結果集中的每一行創(chuàng )建一個(gè) Document 對象。和文件系統資源不同的是，數據庫資源需要放入 Document 中的 Field 一般都存在在查詢(xún)結果集之中。比如一個(gè)簡(jiǎn)單的文章發(fā)布站點(diǎn)，對其后臺數據庫執行查詢(xún) SELECT ID, TITLE, CONTENT FROM ARTICLE 返回一個(gè)有三列的結果集。對結果集的每一行都會(huì )被提取出一個(gè) Document 對象，其中包含三個(gè) Field，分別對應這三列。 然而不同 Field 的類(lèi)型是不同的。比如 ID 字段一般對應 Store.YES 和 Index.NO 的 Field；而 TITLE 字段則一般對應 Store.YES 和 Index.TOKENIZED 的 Field。為了解決這個(gè)問(wèn)題，我們在數據庫結果集資源的實(shí)現中提供一個(gè)類(lèi)型為 Properties 的 fieldTypeMappings 屬性，用于設置數據庫字段所對應的 Field 的類(lèi)型。對于前面的情況來(lái)說(shuō)，這個(gè)屬性可能會(huì )被配置成類(lèi)似這樣的形式： ID = YES, NO
TITLE = YES, TOKENIZED
CONTENT = NO, TOKENIZED |
配合這個(gè)映射，我們便可以生成合適類(lèi)型的 Field，完成對結果集索引的工作。
收集索引 完成對資源的索引之后，還需要讓索引為搜索模塊所用。前面我們已經(jīng)說(shuō)過(guò)這里介紹的框架主要用于小型應用，考慮到復雜性，我們采取簡(jiǎn)單地將分布在各個(gè)機器上的索引匯總到一個(gè)地方的策略。 匯總索引的傳輸方式可以有很多方案，比如使用 FTP、HTTP、rsync 等。甚至索引模塊和搜索模塊可以位于同一臺機器上，這種情況下只需要將索引進(jìn)行本地拷貝即可。同前面類(lèi)似，我們定義一個(gè) Transporter 接口。
清單 5. Transporter 接口
public interface Transporter {
public void transport(File file);
} |
以 FTP 方式傳輸為例，我們使用 Commons Net 完成傳輸的操作。 public void transport(File file) throws TransportException {
FTPClient client = new FTPClient();
client.connect(host);
client.login(username, password);
client.changeWorkingDirectory(remotePath);
transportRecursive(client, file);
client.disconnect();
}
public void transportRecursive(FTPClient client, File file) {
if (file.isFile() && file.canRead()) {
client.storeFile(file.getName(), new FileInputStream(file));
} else if (file.isDirectory()) {
client.makeDirectory(file.getName());
client.changeWorkingDirectory(file.getName());
File[] fileList = file.listFiles();
for (File f : fileList) {
transportRecursive(client, f);
}
}
}
|
對其他傳輸方案也有各自的方案進(jìn)行處理，具體使用哪個(gè) Transporter 的實(shí)現被配置在 Spring 風(fēng)格的索引模塊配置文件中。傳輸的方式是靈活的。比如當需要強調安全性時(shí)，我們可以換用基于 SSL 的 FTP 進(jìn)行傳輸。所需要做的只是開(kāi)發(fā)一個(gè)使用 FTP over SSL 的 Transporter 實(shí)現，并在配置文件中更改 Transporter 的實(shí)現即可。
進(jìn)行搜索 在做了這么多之后，我們開(kāi)始接觸和用戶(hù)關(guān)聯(lián)最為緊密的搜索模塊。注意，我們的框架不包括一個(gè)搜索的 Web 前端界面。但是類(lèi)似這樣的界面可以在搜索模塊的基礎上方便地開(kāi)發(fā)出來(lái)?；谝呀?jīng)收集好的索引進(jìn)行搜索是個(gè)很簡(jiǎn)單的過(guò)程。Lucene 已經(jīng)提供了功能強大的 IndexSearcher 及其子類(lèi)。在這個(gè)部分，我們不會(huì )再介紹如何使用這些類(lèi)，而是關(guān)注在前文提到過(guò)的資源元數據上。元數據從各個(gè)資源所在的文件夾中讀取得到，它在搜索模塊中扮演重要的角色。 構建一個(gè)查詢(xún) 對 不同資源進(jìn)行搜索的查詢(xún)方法并不一樣。例如搜索一個(gè)論壇里的所有留言時(shí)，我們關(guān)注的一般是留言的標題、作者和內容；而當搜索一個(gè) FTP 站點(diǎn)時(shí)，我們更多關(guān)注的是文件名和文件內容。另一方面，我們有時(shí)可能會(huì )使用一個(gè)查詢(xún)去搜索多個(gè)資源的結果。這正是之前我們在前面所提到的元數據中 searchableFields 和 resourceName 屬性的作用。前者指出一個(gè)資源中哪些字段是參與搜索的；后者則用于在搜索時(shí)確定使用哪個(gè)或者哪些索引。從技術(shù)細節來(lái)說(shuō)，只有有了這些信息，我們才可以構造出可用的 Query 對象。 呈現搜索結果 當從 IndexSearcher 對象得到搜索結果（Hits） 之后，當然我們可以直接從中獲取需要的值，再格式化予以輸出。但一來(lái)格式化輸出搜索結果（尤其在 Web 應用中）是個(gè)很常見(jiàn)的需求，可能會(huì )經(jīng)常變更；二來(lái)結果的呈現格式應該是由分散的資源各自定義，而不是交由搜索模塊來(lái)定義?；谏厦鎯蓚€(gè)原因，我們的框架將 使用在資源收集端配置結果輸出格式的方式。這個(gè)格式由資源元數據中的 hitTextPattern 屬性定義。該屬性是一個(gè)字符串類(lèi)型的值，支持兩種語(yǔ)法 - 形如
${field_name} 的子字符串都會(huì )被動(dòng)態(tài)替換成查詢(xún)結果中各個(gè) Document 內 Field 的值。 - 形如
$function(...) 的被解釋為函數，括號內以逗號隔開(kāi)的符號都被解釋成參數，函數可以嵌套。 例如搜索“具體”返回的搜索結果中包含一個(gè) Document 對象，其 Field 如下表： | Field 名稱(chēng) | Field 內容 | | url | http://example.org/article/1.html | | title | 示例標題 | | content | 這里是具體的內容。 | 那么如果 hitTextPatten 被設置為“<a href="${url}">${title}</a><br/>$highlight(${content}, 5, "<b>", "</b>")”，返回的結果經(jīng)瀏覽器解釋后可能的顯示結果如下（這只是個(gè)演示鏈接，請不要點(diǎn)擊）： 示例標題
這里是具體... 上面提到的 $highlight() 函數用于在搜索結果中取得最匹配的一段文本，并高亮顯示搜索時(shí)使用的短語(yǔ)，其第一個(gè)參數是高亮顯示的文本，第二個(gè)參數是顯示的文本長(cháng)度，第三和第四個(gè)參數是高亮文本時(shí)使用的前綴和后綴。 可以使用正則表達式和文本解析來(lái)實(shí)現前面所提到的語(yǔ)法。我們也可以使用 JavaCC 定義 hitTextPattern 的文法，進(jìn)而生成詞法分析器和語(yǔ)法解析器。這是更為系統并且相對而言不易出錯的方法。對 JavaCC 的介紹不是本文的重點(diǎn)，您可以在下面的 閱讀資源 中找到學(xué)習資料。
相關(guān)產(chǎn)品 下面列出的是一些與我們所提出的框架所相關(guān)或者類(lèi)似的產(chǎn)品，您可以在 學(xué)習資料 中更多地了解他們。 IBM?OmniFind?Family OmniFind 是 IBM 公司推出的企業(yè)級搜索解決方案?；?UIMA (Unstructured Information Management Architecture) 技術(shù)，它提供了強大的索引和獲取信息功能，支持巨大數量、多種類(lèi)型的文檔資源（無(wú)論是結構化還是非結構化），并為 Lotus?Domino?和 WebSphere?Portal 專(zhuān)門(mén)進(jìn)行了優(yōu)化。 Apache Solr Solr 是 Apache 的一個(gè)企業(yè)級的全文檢索項目，實(shí)現了一個(gè)基于 HTTP 的搜索服務(wù)器，支持多種資源和 Web 界面管理，它同樣建立在 Lucene 之上，并對 Lucene 做了很多擴展，例如支持動(dòng)態(tài)字段及唯一鍵，對查詢(xún)結果進(jìn)行動(dòng)態(tài)分組和過(guò)濾等。 Google SiteSearch 使 用 Google 的站點(diǎn)搜索功能可以方便而快捷地建立一個(gè)站內搜索引擎。但是 Google 的站點(diǎn)搜索基于 Google 的網(wǎng)絡(luò )爬蟲(chóng)，所以無(wú)法訪(fǎng)問(wèn)受保護的站點(diǎn)內容或者 Intranet 上的資源。另外，Google 所支持的資源類(lèi)型也是有限的，我們無(wú)法對其進(jìn)行擴展。 SearchBlox? SearchBlox 是一個(gè)商業(yè)的搜索引擎構建框架。它本身是一個(gè) J2EE 組件，和我們的框架類(lèi)似，也支持對網(wǎng)頁(yè)和文件系統等資源進(jìn)行索引，進(jìn)而進(jìn)行搜索。
還需考慮的問(wèn)題 本文介紹的思想試圖利用開(kāi)源的工具解決中小型應用中的常見(jiàn)問(wèn)題。當然，作為一個(gè)框架，它還有很多不足， 下面列舉出一些可以進(jìn)行改進(jìn)的地方。 性能考慮 當 需要進(jìn)行索引的資源數目不多時(shí)，隔一定的時(shí)間進(jìn)行一次完全索引不會(huì )占用很長(cháng)時(shí)間。使用一臺 2G 內存，Xeon 2.66G 處理器的服務(wù)器進(jìn)行實(shí)際測試，發(fā)現對數據庫資源的索引占用的時(shí)間很少，一千多條記錄花費的時(shí)間在 1 秒到 2 秒之內。而對 1400 多個(gè)文件進(jìn)行索引耗時(shí)大約十幾秒。但在大型應用中，資源的容量是巨大的，如果每次都進(jìn)行完整的索引，耗費的時(shí)間會(huì )很驚人。我們可以通過(guò)跳過(guò)已經(jīng)索引的資源 內容，刪除已不存在的資源內容的索引，并進(jìn)行增量索引來(lái)解決這個(gè)問(wèn)題。這可能會(huì )涉及文件校驗和索引刪除等。 另一方面，框架可以提供查詢(xún)緩存來(lái)提高查詢(xún)效率?？蚣芸梢栽趦却嬷薪⒁患壘彺?，并使用如 OSCache 或 EHCache 實(shí)現磁盤(pán)上的二級緩存。當索引的內容變化不頻繁時(shí)，使用查詢(xún)緩存更會(huì )明顯地提高查詢(xún)速度、降低資源消耗。 分布式索引 我 們的框架可以將索引分布在多臺機器上。搜索資源時(shí)，查詢(xún)被 flood 到各個(gè)機器上從而獲得搜索結果。這樣可以免去傳輸索引到某一臺中央服務(wù)器的過(guò)程。當然也可以基于實(shí)現了分布式哈希表 （DHT）的結構化 P2P 網(wǎng)絡(luò )，配合索引復制 (Replication)，使得應用程序更為安全，可靠，有伸縮性。在 閱讀資料 中給出了 一篇關(guān)于構建分布式環(huán)境下全文搜索的可行性的論文。 安全性 目前我們的框架并沒(méi)有涉及到安全性。除了依賴(lài)資源本身的訪(fǎng)問(wèn)控制（如受保護的網(wǎng)頁(yè)和文件系統等）之外，我們還可以從兩方面增強框架本身的安全性： - 考慮到一個(gè)組織的搜索功能對不同用戶(hù)的權限設置不一定一樣，可以支持對用戶(hù)角色的定義，實(shí)行對搜索模塊的訪(fǎng)問(wèn)控制。
- 在資源索引模塊中實(shí)現一種機制，讓資源可以限制自己暴露的內容，從而縮小索引模塊的索引范圍。這可以類(lèi)比 robots 文件可以規定搜索引擎爬蟲(chóng)的行為。
總結 通 過(guò)上文的介紹，我們認識了一個(gè)可擴展的框架，由索引模塊和搜索模塊兩部分組成。它可以靈活地適應不同的應用場(chǎng)景。如果需要更獨特的需求，框架本身預留了可 以擴展的接口，我們可以通過(guò)實(shí)現這些接口完成功能的定制。更重要的是這一切都是建立在開(kāi)源軟件的基礎之上。希望本文能為您揭示開(kāi)源的力量，體驗用開(kāi)源工具 組裝您自己的解決方案所帶來(lái)的莫大快樂(lè )。
下載 | 描述 | 名字 | 大小 | 下載方法 | | 一個(gè)示例搜索模塊配置文件 | config.zip | 2 KB | HTTP |
參考資料 學(xué)習
獲得產(chǎn)品和技術(shù)
關(guān)于作者 | | | | 仇寅是南京大學(xué)軟件學(xué)院的本科四年級學(xué)生，目前在 IBM 上海 SAL&FIT 部門(mén)實(shí)習。仇寅熱愛(ài)開(kāi)源活動(dòng)，并愿意積極參與。他擔任學(xué)院的教學(xué)支持系統的維護和開(kāi)發(fā)人員已經(jīng)有一年多的時(shí)間。他感興趣的方向是 Java 技術(shù)和分布式應用。 | | 
