【正文】 如果我 們 是在 閱讀 了 這 篇文章之后，再 閱讀 以上的 這 些信息，那么可能更加有助 于我 們對這 篇文章的理解，除了站在作者的角度考 慮他 對 自己的文章中那些部 分比 較側(cè) 重， 還 可以仍 別 的 專 家 對這 篇文章的 評論中 獲 得 這 篇文章 還 有那些更 加 值 得我 們 注意的和學(xué) 習(xí) 的地方。我 們還了解到 這 篇文章的重點部分，包括完成 緩 存之后的后 續(xù) 工作，與搜索引擎 結(jié)合， 記錄 用 戶 日志等等。 綜 上所述，我 們 在 對這 篇文章完全沒有了解的情況下，通 過閱讀 摘要，知 道了它的大體內(nèi)容是做三 級緩 存的。 仍（ 4）中可以看出， 這篇 論 文 為 了 實現(xiàn)緩 存 結(jié) 構(gòu)，需要 對請 求的性 質(zhì)進 行 描述，并 計 算出一些概率方面的只是。 仍（ 2）中可以看出， 這 篇 論 文是基于網(wǎng) 頁 抓取以及真 實 得 搜索引擎 請求的 日志來 進 行 評測 的，在 單 獨 處 理以及與其他的 結(jié) 合方面都很好， 這 是 這篇 論 文的 成果。 仍（ 1）中可以看出 ,該論 文 緩 存不 僅僅 是 為 了提高每秒 鐘處 理的 請 求量， 還 能 夠進 行索引 壓縮 以及 請 求的 刪 減等工作。這 也代表了 源 論 文后 續(xù) 工作的一種，方便了 讀 者以更加廣 闊 的 視 野來看待 該論 文。源 論 文并不 僅僅 在三 級緩 存 結(jié) 構(gòu)上有研究，其 請 求 處理模型很可能用 處 更大。 仍（ 2）中可以看出， 該 條 評論說 明了它利用了源 論 文中的 請 求 處 理器，來 搭建了一個地理搜索引擎。 仍（ 1）中可以看出， 該 條 評論 并沒有源 論 文的三 級緩 存 結(jié) 構(gòu)，而是比 較 看 重其中的一個方法：利用用 戶請 求的 歷 史 記錄 ，基于以前所 獲 得的比 較 理想的 查 詢詞 ， 簡歷 一個用 戶請 求 庫 ，來提高搜索引擎的中相似的 請 求的 處 理速度。 Comment: (1)They may be considered separate and plementary to a cachebased approach. Raghavan and Sever [the cited paper], in one of the first papers on exploiting user query history, propose using a query base, built upon a set of persistent “optimal” queries submitted in the past, to improve the retrieval effectiveness for similar future queries. Markatos [10] shows the existence of temporal locality in queries, and pares the performance of different catching policies. (2)Our results show that even under the fairly general framework adopted in this paper, geographic search queries can be evaluated in a highly efficient manner and in some cases as fast as the corresponding textonly queries. The query processor that we use and adapt to geographic search queries was built by Xiaohui Long, and earlier versions were used in [26, 27]. It supports variants of all the optimizations described in Subsection 1. (3)the survey by Gaede and G168。 Abstract: Large web search engines have to answer thousands of queries per second with interactive response times. Due to the sizes of the data sets involved, often in the range of multiple terabytes, a single query may require the processing of hundreds of megabytes or more of index data. To keep up with this immense workload, large search engines employ clusters of hundreds or thousands of machines, and a number of techniques such as catching, index pression, and index and query pruning are used to improve scalability. In particular, twolevel caching techniques cache results of repeated identical queries at the frontend, while index data for frequently used query terms are cached in each node at a lower level. We propose and evaluate a threelevel caching scheme that adds an intermediate level of caching for additional performance gains. This intermediate level attempts to exploit frequently occurring pairs of terms by caching intersections or projections of the corresponding inverted lists. We propose and study several offline and online algorithms for the resulting weighted caching problem, which turns out to be surprisingly rich in structure. Our experimental evaluation based on a large web crawl and real search engine query log shows significant performance gains for the best schemes, both in isolation and in bination with the other caching levels. We also observe that a careful selection of cache admission and eviction policies is crucial for best overall performance. 摘要部分，先 說 了搜索引擎的 負載 很重的概況；然后介 紹現(xiàn) 有的兩 級catc h 有一定的缺點，而作者完成了一個三 級緩 存，在原有的 緩 存加入了一個中 間層 ； 最后 說 本文用到了一些算法，并且最 終實驗結(jié) 果的性能也很好。 具體分析 為 了很好的 說 明我 們 所做的 這 個系 統(tǒng) 的效果，下面隨即 選 取一篇 評論較 多論 文 為 例，來 說 明我 們獲 得的 這 些 評論 以及概括的作用。平均每個論 文 有個 95 評論 句子，每個 論 文在被另外一篇 論 文引用 時 ，平均 約 被 評論 次 根據(jù)上面的比率，可以看出，如果我 們 最 終顯 示在界面上的 評論 個數(shù)需要 是 5 個，那么一篇 論 文，它被 1 到 2 篇 論 文引用 時 ，就會 獲 得足 夠 的 評論集。 系 統(tǒng) 示意 圖 主界面 搜索 結(jié) 果界面 界面 第 6 章 實驗結(jié) 果與分析 實驗結(jié) 果 在我 們 的 實驗 數(shù)據(jù)里，我 們總 共抓取了 2500 篇 論 文，其中在我 們 的 論 文集 里被其他 論 文引用的文章個數(shù) 為 1686 篇， 總 共被引用 72471 次，平均每個 論 文被4 2 論 文引用。 這里，我 們 利用了前 面 獲 得的 文件，里面存有一篇 論 文的摘要，獲 得摘要段落之后， 對 其利用摘要算法，可以 獲 取 較 好的效果。我 們 知道，不可 能 對 整篇文章 進 行摘要算法，那 樣 會耗 費 大量的 時間 ，最 終 會 導(dǎo) 致前段所耗 費 的 時間 比后端 檢 索所花 費 的 時間還 多， 這顯 然是用 戶 無法接受的。因 為 Paradise 主要是 針對 網(wǎng) 頁 搜索的，所以稱 這 個域 為 Url， 實際 上 應(yīng)該 叫 DocumentID更確切一點。 這 里我 們 將文獻的文本內(nèi)容存在 BerkeleyDB中的，因 此需要 獲 得每個文章的 id 號。其中， url 域及其重要，是必 須 有的一個域，而且 必 須 名 為 Url。 } 上面的代 碼 中，首先建立一個 Content 域，內(nèi)容 為 我 們 的文獻全文形成的 字符串。 pWriteraddDocument(document)。 (field_ID, NONSTATIC)。 shared_ptrFieldData field_ID_data(new FieldData(PDFFunction::Int2Str(pContentgetID())))。 (field_content, NONSTATIC)。 shared_ptrFieldData field_content_data(new FieldData(pContentgetContentToken()))。 doc_id) { paradise::index::document::Document document。 (2) 重寫一個 Content 類 ，里面存有所需要建立索引的 document 的內(nèi)容 ，由上面的 getContent 類 返回。}} } 在上面的 這 段代 碼 中，可以看出，首先建立了一個分析模 塊 ，然后 選擇壓 縮 方式 為 pfordata，然后建立一個 IndexWriter， 這 個是建立索引的 類 。amp。 addDocument(pContent, writer, doc_id)。 Timer t。 begin。 PDFParser parser。 IndexWriter * writer = new IndexWriter(fsdir, analyzer, pressorFactory)。 void main(){ Analyzer* analyzer = new NaiveAnalyzer()。 壓縮 的 時 候，可以 選擇 vint、 pfordelta 等等各種 壓縮 算法para dise 系 統(tǒng) 接口 設(shè)計 得非常好，當(dāng)需要 對 上面仸何一個模 塊進 行 修改 時 ，不需要修 改源代 碼 ，只需要自己重寫一些 繼 承的 類 就可以了。 這 個地方需要注意的就是 與 index部分有一定的 結(jié) 合，會在后面提到。 （ 4） front_evidence是前臺模 塊 ，完成一個 類 似于天網(wǎng)搜索引擎的前臺界面。 （ 2） index是索引模 塊 ，用于將需要 檢 索的部分建立倒排索引。其功能有點 類 似于 lucene 系 統(tǒng) ，與其不 同的是 paradise 是用 c++編 寫的。通 過這 段內(nèi)容，我 們 可以了解到 paradise 使用的基本 過 程，最 終我 們 會 發(fā)現(xiàn) ，如果想搭建其他方向的搜索引擎，使用 paradise 也是非常方便的。而 這 個概括與摘要的區(qū) 別 就是，影響 較 大的句子，可能原來的作者并沒有 想到，因此在摘要中并沒有提及（正所 謂 無心插柳柳成 蔭 ）；而摘要中提及的部分 ，影響可能反而沒有那么大。之后， 選擇 其中得分最高的k 個句子， 組 合在一起，就 獲 得了原文基于影響的概括了。 圖 表 獲 得基于影響的概括 通 過 上面的模型，可以 對 A 中的每個句子 進 行打分，然后根據(jù)所打得分數(shù) 進行 仍打到小排序。整個流程如 [ 圖 表 3]，需要用到 [ 圖 表 2]中的前三部算法 獲 得的 評論 列表。 可以看出， 對 于一個既不在 d中又不在 C中的 單詞 ， p(w | I ) = 0.對結(jié) 果也沒有影響。那 么， 對 于每一