本節書摘來自華章出版社《大規模元搜尋引擎技》一書中的第2章，第2.1節，作者 ［美］孟衛一(weiyi meng)， 紐約州立大學， 賓漢姆頓分校於德（clement t.yu），伊利諾伊大學芝加哥分校，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
搜尋文本文檔的元搜尋引擎可分為兩種類型：通用元搜尋引擎和專用元搜尋引擎。前者旨在搜尋整個web，而後者專注于在特定領域搜尋資訊（例如，新聞、招聘）。
建構每個類型的元搜尋引擎有兩種方法：
主流搜尋引擎方法。這種方法使用少數的熱門主流搜尋引擎來建構元搜尋引擎。因而，使用這種方法建構通用元搜尋引擎，可以使用少量的主流搜尋引擎，如google、yahoo!、bing（msn）和ask。類似地，在特定領域建立一個專用元搜尋引擎也可以使用這種方法，使用該領域的主流搜尋引擎。例如，在新聞領域可以使用google news、yahoo！news、reuters等。
大規模元搜尋引擎方法。這種方法使用大量的以小搜尋引擎為主的搜尋引擎來建構元搜尋引擎。例如，使用這種方法，我們可以想象用web上所有文檔驅動的搜尋引擎來建構一個通用元搜尋引擎。這樣一個元搜尋引擎将有數百萬的成員搜尋引擎。類似地，對于一個給定的領域，用這種方法可以通過連接配接該領域所有的搜尋引擎來建構專用元搜尋引擎。例如，在新聞領域可以使用數以萬計的報紙和新聞站點的搜尋引擎。
上述兩種方法各有優缺點，本節将較長的描述。相對于大規模元搜尋引擎方法，主流搜尋引擎方法的明顯優勢是主流元搜尋引擎更容易建構，因為用這種方法建構元搜尋引擎隻需要很少數目的搜尋引擎。目前幾乎所有流行的元搜尋引擎都是使用主流搜尋引擎方法建構的，例如，dogpile（http：//www.dogpile.com/）、mamma（http：//www.mamma.com/）、metacrawler（http：//www.metacrawler.com/），其中大多數隻使用少數幾個主流搜尋引擎。allinonenews（http：//www.allinonenews.com/）是大規模專用元搜尋引擎的一個例子，它使用了約200個國家/地區的1800個左右的新聞搜尋引擎。一般而言，建立大規模元搜尋引擎需要更先進的技術。随着這些技術越來越成熟，可能會建立更多大規模元搜尋引擎。
設計元搜尋引擎系統的體系結構時應該同時考慮上述兩種方法。圖2-1所示的體系結構就是基于這種考慮。該體系結構包含一些重要的軟體部件，包括搜尋引擎選擇器（search engine selector）、搜尋引擎加入器（search engine incorporator）和結果合并器（result merger）。搜尋引擎加入器由兩個子部件組成：搜尋引擎連接配接器（search engine connector）和結果抽取器（result extractor）。本書中我們把元搜尋引擎中使用的那些搜尋引擎稱為元搜尋引擎的成員搜尋引擎（component search engine）。
下面對圖2-1中元搜尋引擎的主要部件進行更較長的描述。
圖2-1 元搜尋引擎系統的體系結構
如果一個元搜尋引擎中的成員搜尋引擎的數目很少，比如小于10個，那麼把每個送出給元搜尋引擎的使用者查詢發送到所有成員搜尋引擎也許是合理的。在這種情況下，很可能不需要搜尋引擎選擇器。然而，如果成員搜尋引擎的數目很多，就像在使用大規模元搜尋引擎，發送每個查詢給所有成員搜尋引擎将是一種低效率的政策，因為大多數成員搜尋引擎對任何特定的查詢是無用的。例如，假設使用者想要從具有1000個成員搜尋引擎的元搜尋引擎中查找與其查詢比對的50個最佳結果。因為50個最佳結果将包含在不超過50個成員搜尋引擎中，很明顯，對這個特定的查詢，至少950個成員搜尋引擎是無用的。
把查詢傳遞給無用的搜尋引擎可能會導緻嚴重的效率問題。一般而言，發送查詢給無用的搜尋引擎将導緻資源浪費，包括元搜尋引擎伺服器、涉及每個搜尋引擎的伺服器和網際網路資源。具體而言，發送查詢給一個無用搜尋引擎并處理傳回結果會浪費元搜尋引擎伺服器的資源，其中發送查詢時浪費的資源包括查詢所需的格式重寫，處理傳回結果時浪費的資源包括接收傳回的響應頁面，從這些頁面中抽取結果記錄，并确定它們是否應該包含在最終的合并結果清單中，若是，還需要确定它們在合并後的結果清單中的位置。如果一個搜尋引擎的結果最終毫無用處，那麼接收來自元搜尋引擎的查詢、處理查詢并傳回結果給元搜尋引擎将浪費搜尋引擎的資源。最後，從元搜尋引擎向無用搜尋引擎傳輸查詢，以及從這些搜尋引擎向元搜尋引擎傳輸無用的檢索結果，都浪費了網際網路的網絡資源。
是以，把每個使用者查詢僅發送給潛在有用的搜尋引擎去處理是重要的。對于一個給定查詢，識别應該調用的潛在有用成員搜尋引擎的問題稱為搜尋引擎選擇問題（search engine selection problem），有時也稱為資料庫選擇問題（database selection problem）、伺服器選擇問題（server selection problem）或查詢路由問題（query routing problem）。顯然，對于元搜尋引擎，具有越多的成員搜尋引擎和越多不同内容的成員搜尋引擎，擁有一個有效的搜尋引擎選擇器就越重要。搜尋引擎選擇技術将在第3章讨論。
當一個成員搜尋引擎被選擇參與處理一個使用者查詢處理之後，搜尋引擎連接配接器建立與此搜尋引擎伺服器的連接配接并将查詢傳給該伺服器。不同的搜尋引擎通常有不同的連接配接參數。是以，對每個搜尋引擎都需要建立一個單獨的連接配接器。一般而言，對于一個搜尋引擎s，搜尋引擎連接配接器需要知道s支援的http連接配接參數。有3個基本參數：（a）搜尋引擎伺服器的名稱和位址；（b）s支援的http請求方法（通常是get或post）；（c）用來儲存實際查詢字元串的字元串變量名。
當實作一個成員搜尋引擎數目少的元搜尋引擎時，可以由經驗豐富的開發者為每個搜尋引擎手動編寫連接配接器。然而，對于大規模元搜尋引擎來說，這可能會非常耗時和昂貴。是以，開發自動生成連接配接器的能力是非常重要的。
需要注意的是，一個智能元搜尋引擎如果發現修改接收到的使用者查詢可以潛在地提高搜尋效率，那麼它可能會先修改該查詢并把修改後的查詢傳送給搜尋引擎連接配接器。例如，元搜尋引擎可能通過使用查詢擴充技術為原始使用者查詢增加一些相關詞來增大擷取更多相關文檔的機會。
搜尋引擎連接配接器将在第4章讨論。
當一個成員搜尋引擎處理一個查詢之後，搜尋引擎将傳回一個或多個響應頁面。一個典型的響應頁面包含多個（通常10個）查詢結果記錄（search result record，srr），每個記錄對應一個檢索到的web頁面，該記錄通常包含url、頁面标題、頁面内容的簡短摘要（稱為概覽，snippet）和一些其他的資訊，例如頁面大小。圖2-2顯示了google搜尋引擎的一個響應頁面的上部。響應頁面是動态生成的html文檔，它們通常也包含與使用者查詢不相關的内容，例如廣告（贊助商連結）和網站的資訊。
圖2-2 google響應頁面的一部分
需要一個程式（即結果抽取器）從每個響應頁面中抽取正确的srr，以便把來自不同成員搜尋引擎的srr合并成一個排序清單。這個程式有時稱為抽取包裝器（extraction wrapper）。由于來自不同搜尋引擎的結果通常格式不同，是以需要為每個成員搜尋引擎配備單獨的結果抽取器。盡管經驗豐富的程式員可以手動編寫抽取器，但對于大規模元搜尋引擎，更希望研發能夠自動生成抽取器的技術。
結果抽取技術将在第4章讨論。
被選擇的成員搜尋引擎的結果傳回給元搜尋引擎之後，結果合并器把結果合并成一個排序清單。然後把排序的srr清單呈現給使用者，或許一次一個包含10條記錄的頁面，就像大多數搜尋引擎一樣。
很多因素會影響結果合并的進行以及輸出結果像什麼樣子。其中的一些因素為：1)不同成員搜尋引擎索引的各個文檔集合之間存在多少重疊？可能的情形從沒有重疊到這些文檔集合完全相同，以及介于這兩個極端之間的任意情況。2)什麼樣的資訊存在或可用來進行合并？可能利用的資訊包括：成員搜尋引擎結果記錄的本地排序、結果記錄的标題和概覽、每個結果的完整文檔、每個檢索文檔的釋出時間、搜尋引擎與其檢索結果所對應的查詢之間的潛在相關性，以及其他資訊。好的結果合并器應将所有傳回結果按其需求度降序排列。
結果合并的不同方法将在第5章中讨論。