<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 搜索技術剖析:使用組合器爬行 > 原文: [http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html](http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html) ![](https://img.kancloud.cn/6a/b1/6ab18e95de48eb4067d833a503a9ebf2_240x187.png) *這是垃圾郵件免費搜索引擎 blekko 的首席技術官 Greg Lindahl 撰??寫的系列文章中的第二個來賓帖子([第 1 部分](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html ),[第 3 部分](http://highscalability.com/blog/2012/7/9/data-replication-in-nosql-databases.html))。 之前,Greg 是 PathScale 的創始人兼杰出工程師,當時他是 InfiniPath 低延遲 InfiniBand HCA 的架構師,該架構用于構建緊密耦合的超級計算集群。* ## 搜尋網路有什么困難? Web 搜尋器的存在時間與 Web 差不多,在網絡出現之前,就存在用于 gopher 和 ftp 的搜尋器。 您可能會認為 25 年的經驗將使您能夠解決已解決的問題,但是網絡的迅猛發展以及垃圾郵件技術和其他不良內容的新發明不斷帶來新的挑戰。 緊密耦合的并行編程的普遍困難也抬起了頭,因為網絡已從數百萬個頁面擴展到數千億個頁面。 ## 現有的開源爬網程序和爬網 本文主要討論 blekko 的搜尋器及其組合器的用法,但是,如果您想對搜尋的困難部分進行更一般的介紹,建議您查看以下內容: * <cite>[信息檢索簡介](http://nlp.stanford.edu/IR-book/)</cite> * [Apache Nutch](http://nutch.apache.org/) 開源搜尋器 * 來自 [](http://archive.org/) 的開源抓取工具 [Heritrix](http://crawler.archive.org/) * [50 億頁](http://archive.org/) [常見爬網](http://commoncrawl.org/) ## 定向爬行 打算不對整個 Web 進行爬網的爬網程序的最重要功能是僅對最重要的頁面進行爬網的能力。 有傳言稱,谷歌的網絡爬蟲和索引超過了 1000 億個網頁,而谷歌在 2008 年宣布其“爬蟲前沿”(他們在其他網頁上看到的所有網址的列表)已經結束。 blekko 知道我們只想為僅數十億個網頁的索引編制索引并提供結果。 那只是 Google 抓取邊界中網頁的一小部分,因此我們需要非常擅長抓取最好的頁面,并且只抓取最好的頁面。 一種方法是在爬網時計算網頁的排名,包括尚未爬網的頁面的排名。 頁面的等級取決于傳入鏈接的數量和質量,以及許多其他頁面上的度量,例如頁面上的文字,與文字數量相比的廣告數量等等。 在首次抓取頁面之前無法知道頁面上的度量值,但是從抓取其他頁面開始就可以知道傳入的鏈接。 當然,使用入站鏈接對網頁進行排名是很多互聯網垃圾郵件發送者已經精心設計的方法。 這些虛假鏈接中的一些來自其他垃圾郵件發送者網站,而某些來自具有合理內容的合法網站。 我有一堆關于各種主題的舊的,排名靠前的網頁,而且我收到了無窮無盡的“鏈接交易”電子郵件,這些電子郵件大多是由自動執行鏈接交易游戲的軟件包發送的。 查找和忽略來自合法網站的錯誤鏈接要困難得多,而且通常要等到許多鏈接頁面被完全爬網后才能完成。 ## 組合器 現在,讓我們看看**組合器**(我們在[先前的博客文章](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html)中進行了討論)如何使這些計算變得更加容易。 首先,我們想對許多事物進行獨特計數:傳入鏈接的地理多樣性,傳入鏈接的網絡多樣性等等。 如果所有傳入鏈接都來自同一個 C 類 IP 網絡,那么包含大量傳入鏈接的頁面就不會那么有趣。 我們使用**對數計數**組合器來有效地計數這些數量(在時間和空間上-每個計數 16 個字節),而不會在我們爬行和重新爬行 Web 時重復計數任何東西。 使用 logcount 的缺點是計數是近似值。 對于一些重要的數量,我們選擇 logcount 的變體,它們需要多達 256 個字節的狀態,以便更好地近似精確的答案。 接下來,我們經常需要操縱到網頁的傳出和傳入鏈接列表。 在大多數關系數據庫中,此數據通常由表中的一系列行表示,并且我們將通過查詢鏈接的目的地等于特定 URL 的所有記錄來獲取此數據。 這是一項昂貴的操作,并且由于入站鏈接的數量可能很大(在許多情況下為數百萬個),因此我們需要某種方式擺脫該表中次重要(排名較低)的行,以便 保持表格大小合理。 **TopN** 組合器解決了這兩個問題。 作為一個有限大小的列表,可以通過一次操作讀取它,并且它的大小是自動修整的。 作為我們為什么要在抓取時操作此傳入網頁列表的示例,請考慮以下事實:交易或購買的鏈接通常具有相同的[錨文本](http://en.wikipedia.org/wiki/Anchor_text)。 通過在爬網頁面之前檢查傳入的錨文本,我們可以完全避免爬網。 索引時間檢查可以發現錨文本的相似性,但是為時已晚,要避免浪費資源對其進行爬網。 除了 url 級別的信息外,我們還保留爬網程序所學內容的主機級別摘要。 例如,我們有一個 TopN 摘要以及主機到主機鏈接的數量。 該摘要對于發現具有大量組內鏈接的主機組很有用。 我們使用此數據來打折這些鏈接的價值。 ## 所有其他的東西 除了我們已經討論的內容(查找傳出鏈接并計算未爬網頁面的等級)外,blekko 的搜尋器還完成了許多其他工作。 如果在網頁上找到日期,則搜尋器會立即將要創建索引的頁面發送給其他支持 blekko 的/ date 和/ daterange 功能的索引(有關 blekko 的高級功能,請參閱此 ## 爬行經驗 我們在此過程中吸取了一些教訓。 一個重要的教訓是,至關重要的是,擁有一個電子郵件地址,網站管理員可以在存在抓取工具問題時可以私下與我們聯系。 由于此,我們修復了一些錯誤。 最令人驚訝的是,網站管理員(和主要的抓取工具)未嚴格遵守 robots.txt 規范,并期望其 robots.txt 中的空白行無效。 我們還發現,很大一部分網站(包括許多美國政府網站)僅允許一小部分爬蟲白名單來爬網其頁面。 這些網站很多都是很小的,并且沒有明顯的聯系方式聯系他們的網站管理員以要求將其添加到白名單中。 ## 未來發展方向 將來,我們想在爬網系統中添加一件主要的事情:執行 JavaScript 的能力。 越來越多的網絡隱藏在 javascript 之后,盡管網站管理員謹慎地將其內容隱藏在大多數搜索引擎無法看到的地方,但許多網站管理員確實有動機隱藏其分析和廣告 ID,以便他們 不那么明顯。 ## 相關文章 * [關于黑客新聞](http://news.ycombinator.com/item?id=4033983) * [搜索技術剖析:Blekko 的 NoSQL 數據庫](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html) Heritrix 和 Common Crawl 項目的鏈接周圍有些破損。 爬網一章的鏈接已斷開。 這是正確的鏈接:http://nlp.stanford.edu/IR-book/html/htmledition/web-crawling-and-indexes-1.html(看起來連字符可能在錯誤的位置)。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看