DRIS分層檢索資源

文/江玲 王亮

DRIS分層檢索資源

文/江玲 王亮

DRIS是一個分層式網頁搜索引擎技術，采用DNS的地域分布式構架，建立一個新的信息資源整合與檢索平臺。

目前，互聯網資源正以幾何級數增長，但是還沒有一個搜索引擎的數據庫可以和整個互聯網的增長保持同步。雖然，每個搜索引擎都在力圖為用戶提供全面而準確的信息，但是它們不能建立一個可以鏡像整個互聯網的數據庫系統，因此，我們需要一種全新的信息檢索系統。

為此，華中科技大學圖書館提出了一種全新的信息檢索系統——域內資源整合系統(Domain Resources Integrated System，簡稱DRIS)，為整合互聯網上的所有信息資源提供可行性方案。

“搜索引擎+DNS”的思路

對DRIS的研究主要來源于對館內資源整合和數字圖書館聯盟建設的研究，以及對搜索引擎和網格技術的相關研究。“信息檢索應成為互聯網的內在功能，每個人都應該有自己的搜索引擎”是設計本系統的核心思想。DRIS要建立的是互聯網信息檢索的基礎建筑，而不是最終的搜索引擎。

我們從DNS技術的發展得到基本的啟發。在DNS系統建立之初,僅僅有數百個Web站點，而相應的DNS數據庫可以存儲在單個服務器上，但是當WWW上站點的數目達到上百萬個，各個站點分布世界各處且更新較為頻繁時，僅有的幾個DNS服務器顯然難以有效管理如此多的站點。因此DNS最終發展成為一個分層的分布式系統。如今幾乎每個高校和大機構都有自己的域名服務器，而互聯網上所有的站點都能在此系統中得到有效的管理。

但DNS僅僅起到WWW上“瀏覽和導航”的作用，我們還需要必要的網頁檢索功能，因此出現了網頁搜索引擎。但是由于種種原因，目前所有的商業搜索引擎都采用了集中式構架。隨著WWW的迅速擴張，網頁搜索引擎也遇到了當初DNS遇到的問題：如今已有上百億的網頁分布在世界不同角落的服務器上，而當前的搜索引擎卻要反復地訪問并下載全部的網頁到一個數據庫系統中，數據的更新率和覆蓋率根本無法得到保障。顯然，集中式的框架是不適于分布式的WWW信息管理。

參考DNS改進和發展的歷史可以發現，Web搜索引擎若像DNS那樣采用一種等級分布式的框架，一些基本問題就可能得到解決。既然DNS能夠索引各個站點的名稱，那么是否也能索引整個站點的所有網頁呢？我們為DRIS設計了“搜索引擎+DNS”的基本思路。

DRIS采用了DNS的地域分布式構架，建立一種新的信息資源整合與檢索平臺。此平臺在合適的范圍內，采用不同的信息檢索系統，建立一種適合整個互聯網信息管理的基本構架。

構建三層框架

DRIS可簡單描述為（組織級—常規數據庫檢索系統）—（主干網級—元數據采集系統）—（國家級—分布式檢索系統），而其服務管理則采用了XML/Web Services/ UDDI的形式。基本結構如圖1所示。

整個系統分為三層：第三層為DNS的三級域，一般對應于某個組織機構，如一個大學；第二層一般對應于國家的各個主干網；第一層則對應于某個國家。

采用此基本框架，我們可以先在最底層下載網頁數據，然后逐級傳遞到最上層的服務器上。由于網頁的下載更新工作都在不同的底層節點進行，而這些節點一般又都對應于某個局域網，因而這種分布采集、逐層遞交的方式可以保證整個系統的數據每天更新，這樣更新率問題就得到了很好的解決。

但是按照這種方法，頂層的服務器數據存儲量可能依然很大，我們就不得不采用分布計算等復雜技術來保障頂層服務器的數據存儲和檢索服務質量。要建立一個可以鏡像整個Internet數據的系統幾乎是不可能的，我們必須采用其他方式來完成此任務。因此，我們首先對搜索引擎基本技術及當前具有代表性的幾種信息檢索系統和網頁搜索引擎的兩種基本算法進行介紹，并在此基礎上對系統的基本思想進行具體的實現。

信息檢索應成為互聯網的內在功能，每個人都應該有自己的搜索引擎。而DRIS要建立的是互聯網信息檢索的基礎建筑，而不是最終的搜索引擎。

采用三種檢索系統

根據新系統三個層次的具體特點，我們分別采用了不同的系統構架和基本算法，來構建一個更為高效的網頁檢索系統。我們按照從底層到高層的方式逐一介紹各層的搜索系統。

目前，大多數商業化網頁搜索器和檢索接口，利用兩種基于詞頻索引擎的基本算法，都是基于集中式結構設計的，一般包括三個主要部分：網頁下載器、搜索引擎和基于超鏈接分析的搜索引擎。

按照基本體系結構劃分，目前已有三種不同類型的信息檢索系統：基于傳統數據庫的集中式檢索系統、基于元數據采集的檢索系統和分布式檢索系統。

隨著數據源規模擴大和數據類型的增多，信息檢索系統基本結構一般可依次選擇常規數據庫型、元數據采集型、分布式檢索型。

第三層：集中式檢索系統

第三層的系統將構建一個三級域內的網頁搜索引擎，如一個大學校園網的搜索引擎，其設計原理同現有的搜索引擎基本相同，差別僅在于其搜索范圍較小。這里采用了集中式的設計結構，此檢索系統由三個部分組成：網頁下載器、索引器以及檢索接口。

1．網頁下載器

此系統的網頁下載器將下載某個三級域內的所有網頁。如 “www.hust.edu.cn ”是華中科技大學的域名，那么此域名下的低級域名如計算機系的域名“cs.hust.edu.cn”均可在此三級域名服務器上查到。因此相應的Spider程序只要依照DNS列表就可下載此域內的所有網頁。

系統Spider的工作是按不同的站點劃分的，Spider依次訪問一個域內的全部站點。當一個Spider訪問某個Web服務器時，它將下載此服務器上的所有內容，當遇到指向其他服務器的鏈接時，也將此鏈接作為本站內容下載，但不再下載更深層次的鏈接，這些指向外部的鏈接相當于Spider的訪問終止標記，我們將這樣的鏈接稱為“終止標志鏈接”。

這一點和現有的網頁搜索引擎有較大的不同——它們的Spider一般采用自由漫游的方式采集網頁信息，沒有一定的終止標記，系統采用多個Spider協作的方式進行網頁下載，一般都要用非常復雜的算法來指導Spider漫游，以便盡可能遍歷更多的網頁。而在系統中只要按站點下載即可，不用考慮各站點之間的復雜鏈接關系。

2.網頁索引器

索引技術的關鍵在于元數據的恰當選擇。目前的搜索引擎一般采用全文檢索，即文中每一個詞匯都作為索引詞，而用詞頻和位置信息確定索引詞的重要性。我們也利用此方式進行網頁的索引。而網頁的標題、編碼等其他信息也可作為索引項。我們也可選用一些更為復雜的技術如W3C的Ontology語義模型來索引網頁。

3.檢索接口

檢索接口的主要功能是處理檢索結果并提供用戶接口，如何進行檢索結果的排序是此部分的關鍵所在。在這一層，我們采用基于詞頻統計的算法進行檢索結果的排序。因為在這種情況下采集的網頁僅僅限于一個很小的范圍如一個大學，而超鏈接分析則適用于大范圍的網頁排序。此外，針對局域網網頁集合的特點，IBM的研究院曾提出了一種名字為“rank aggregation”的局域網內網頁排序方法，在提高網頁檢索準確率方面有一定的改進。

第二層：元數據采集系統

此層的檢索系統將提供二級域范圍的信息檢索服務，元數據采集系統用來構建此層的搜索引擎。一個第三層節點如一個大學內的網頁數目一般不會超過10萬個，集中式系統可以很好地管理這種規模的數據。而一個第二層節點如“edu.cn”則包含了國內所有的大學，網頁總數可能超過千萬。如果依然采用常規的檢索系統就難以保證數據庫的覆蓋率和更新率，所以我們采用了元數據采集方式。

此層的搜索引擎包含兩個部分：網頁數據庫和檢索接口，該引擎沒有自己的數據采集器Spider，直接從第三層的節點數據庫中獲得數據，如對應于“edu.cn”節點的服務器可從數千個大學中的第三層節點搜索引擎數據庫中獲得網頁數據，而不是直接下載上百萬張網頁，這種方法的數據更新效率更高。而由于采集的是元數據，因此總數據量也不會過大。具體的元數據采集方法將參照OAI系統設計。

一個值得注意的問題就是網頁的重復存儲問題。在第三層中，Spider下載某個站點的網頁的同時也下載了一些不屬于此網站的網頁(終止標志鏈接)，那么在采集整合元數據時一些網頁可能出現多次。而根據第三層的下載規則，一個網頁重復出現的次數就是其他站點指向此網頁的鏈接數目，而這正是超鏈接分析技術中的網頁排名權值。在集中式體系中，出于成本等因素考慮，不可能將位于不同位置的同一個鏈接全部下載再統計被引用的次數，而在分布式框架下則可用這種簡單的方式實現超鏈接分析技術的基本思想。

顯然此層的檢索接口應采用超鏈接分析的方式進行檢索結果的排序。這里只介紹基本原理，各層之間如何協調、最終的排名算法等將在系統的標準協議中制定。

第一層：分布式檢索系統

第一層將構建覆蓋一個國家范圍的網頁搜索引擎，如果依然按照第二層那樣將全部的網頁元數據進行集中存儲，那么可能要存儲上十億張網頁數據，系統設計依然比較困難。由于第二層的節點一般對應于一個國家的主干網，數目較少，因此可以考慮將第一層的搜索系統設計成分布式檢索系統，那么系統將只有檢索接口，而沒有Spider，也沒有索引數據。

設計分布式檢索系統一般要解決三個主要問題：

1. 基本的數據傳輸協議，如TCP/IP

此系統中以SOAP協議為技術協議，SOAP協議基于HTTP協議而設計，但在安全性等方面都有較大的改進。

2. 子系統和主系統的具體的數據交換協議，如數據結構、檢索語法等

系統的檢索協議設計以Web Service為基礎。Web Service以SOAP協議為基礎建立了一種高效的分布式系統框架。在設計協議時我們參考了SDLIP和Google的Web Service檢索服務，用來定義相應的數據格式和檢索語法等。此方法要求在第二層的節點提供統一的Web Service檢索服務，而在第一層對這些檢索服務進行索引。

3. 從子系統獲得檢索結果的合并方式

結果合并的關鍵依然是排序問題。在第二層中，我們用數據采集中網頁重復的次數當作網頁的排名權值，而在第一層依然采用此方法，在執行并行檢索時只要把同一個網頁在各個子系統的排名值簡單相加即可得到一個最終的排名權值。

第三層的搜索引擎工作原理同元搜索引擎基本一致，沒有自己的網頁數據庫，而僅索引其他搜索引擎的檢索接口。但在此系統中，各個子系統都嚴格遵循一個相同的協議，而且組織有序，因此性能要比現有的元搜索引擎優良。此層的搜索引擎將提供一個國家范圍內的網頁搜索，這已經是本系統的最高級，而由于語言的差異，它已經基本覆蓋了大部分的檢索請求，如果確實要進行多個國家范圍的并行搜索，只要設計一個簡單的系統，調用多個最高層檢索接口即可。

為用戶分配適合的搜索引擎

由于新系統的每一個節點都是完整的搜索引擎，因此，怎樣使用戶能夠找到需要的搜索引擎是系統應用的關鍵。我們一般采用面向對象的模型對系統進行描述，這里我們也利用此模型來描述此系統。我們為其選擇一個基本的命名空間“DRIS”，整個系統的類樹如圖2所示。

所有的系統節點都位于命名空間“DRIS”下，并被視為子類。這些子類及其實現都在不同的服務器上實現。為了方便使用和管理整個系統，我們定義了幾個基本規則：

1.所有的節點都通過標準Web Service的形式提供檢索服務。

2.所有的檢索服務都按照“繼承”的關系進行組織，但這種關系的實現和標準的面向對象模型略有不同。低層的節點通過引用高層節點的Web Service的形式進行繼承。而對高層節點來說，其各個子類都位于不同的服務器上，高層節點并不知道其子類，因此將有一個專門的模塊用來索引低層節點的檢索接口。

3. Web Service通過URL鏈接來提供服務，對用戶來說如何發現相應搜索引擎服務的鏈接是應用中的關鍵問題。例如，我們要尋找一個高校的網頁信息檢索服務，那么就必須找到它的URL。如何做到呢？我們對搜索引擎服務器的位置進行規定，即每個DRIS服務器都通過鏈接“DRIS.域名”向外提供標準Web Service檢索服務，而此服務器上Web Service的主類名為“DRIS.反順序域名”。如華中科技大學的域名為“hust.edu.cn”，則DRIS服務器通過鏈接“DRIS.hust.edu.cn”向外提供校內各種資源的檢索服務，此服務的主類名為“DRIS. cn.edu.hust”。在新系統中，域名不僅起到DNS中的“導航”作用，而且是資源集合的一種“標識”。

系統提供互聯網不同范圍的標準信息檢索服務，這將為一些個性化信息檢索系統提供高質量數據源。這些個性化搜索系統可以根據用戶的興趣愛好等信息自動選擇合適的數據源并按照用戶需求對檢索結果進行相應的整理。由超鏈接分析等得到的排名權值僅作為一個參考值，檢索結果的最終排序會根據不同用戶的實際需求信息進行調整。基于DNS的網頁搜索引擎將為此類研究提供一個高效的基礎數據平臺。

DRIS在覆蓋率、更新率以及檢索結果的準確率等方面都較現有的搜索引擎有較大的改進，同時整個系統設計都基于比較成熟的技術，可以滿足用戶的需求。

(作者單位為華中科技大學圖書館)