搜尋引擎工作的基礎流程與原理
搜尋引擎最重要的是什麼?有人會說是查詢結果的準確性,有人會說是查詢結果的豐富性,但其實這些都不是搜尋引擎最最致命的地方。對於搜尋引擎來說,最最致命的是查詢時間。試想一下,如果你在百度介面上查詢一個關鍵詞,結果需要5分鐘才能將你的查詢結果反饋給你,那結果必然是你很快的捨棄掉百度。
搜尋引擎為了滿足對速度苛刻的要求(現在商業的搜尋引擎的查詢時間單位都是微秒數量級的),所以採用快取支援查詢需求的方式,也就是說我們在查詢搜尋時所得到的結果並不是及時的,而是在其伺服器已經快取好了的結果。那麼搜尋引擎工作的大體流程是什麼樣子呢?我們可以理解為三段式。
本文僅僅是對著三段工作流程進行大體上的講解與綜述,其中一些詳細的技術細節將會用其它的文章進行單獨的講解。
一、網頁蒐集
網頁蒐集,其實就是大家常說的蜘蛛抓取網頁。那麼對於蜘蛛(google稱之為機器人)來說,他們感興趣的頁面分為三類:
1.蜘蛛從未抓去過的新頁面。
2.蜘蛛抓去過,但頁面內容有改動的頁面。
3.蜘蛛抓取過,但現在已刪除了的頁面。
那麼如何行之有效的發現這三類頁面並進行抓取,就是spider程式設計的初衷與目的。那麼這裡就涉及到一個問題,蜘蛛抓取的起始點。
每一位站長只要你的網站沒有被嚴重降權,那麼通過網站後臺的伺服器,你都可以發現勤勞的蜘蛛光顧你的站點,但是你們有沒有想過從編寫程式的角度上來說,蜘蛛是怎麼來的呢?針對於此,各方有各方的觀點。有一種說法,說蜘蛛的抓取是從種子站(或叫高權重站),依照權重由高至低逐層出發的。另一種說法蜘蛛爬在URL集合中是沒有明顯先後順序的,搜尋引擎會根據你網站內容更新的規律,自動計算出何時是爬取你網站的最佳時機,然後進行抓取。
其實對於不同的搜尋引擎,其抓取出發點定然會有所區別,針對於百度,Mr.Zhao較為傾向於後者。在百度官方部落格釋出的《索引頁連結補全機制的一種辦法》(地址:http://stblog.baidu-tech.com/?p=2057)一文中,其明確指出“spider會盡量探測網頁的釋出週期,以合理的頻率來檢查網頁”,由此我們可以推斷,在百度的索引庫中,針對每個URL集合,其都計算出適合其的抓取時間以及一系列引數,然後對相應站點進行抓取。
在這裡,我要說明一下,就是針對百度來說,site的數值並非是蜘蛛已抓取你頁面的數值。比如site:www.seozhao.com,所得出的數值並不是大家常說的百度收錄數值,想查詢具體的百度收錄量應該在百度提供的站長工具裡查詢索引數量。那麼site是什麼?這個我會在今後的文章中為大家講解。
那麼蜘蛛如何發現新連結呢?其依靠的就是超連結。我們可以把所有的網際網路看成一個有向集合的聚集體,蜘蛛由起始的URL集合A沿著網頁中超連結開始不停的發現新頁面。在這個過程中,每發現新的URL都會與集合A中已存的進行比對,若是新的URL,則加入集合A中,若是已在集合A中存在,則丟棄掉。蜘蛛對一個站點的遍歷抓取策略分為兩種,一種是深度優先,另一種就是寬度優先。但是如果是百度這類商業搜尋引擎,其遍歷策略則可能是某種更加複雜的規則,例如涉及到域名本身的權重係數、涉及到百度本身伺服器矩陣分佈等。
二、預處理
預處理是搜尋引擎最複雜的部分,基本上大部分排名演算法都是在預處理這個環節生效。那麼搜尋引擎在預處理這個環節,針對資料主要進行以下幾步處理:
1.提取關鍵詞。
蜘蛛抓取到的頁面與我們在瀏覽器中檢視的原始碼是一樣的,通常程式碼雜亂無章,而且其中還有很多與頁面主要內容是無關的。由此,搜尋引擎需要做三件事情:程式碼去噪。去除掉網頁中所有的程式碼,僅剩下文字文字。②去除非正文關鍵詞。例如頁面上的導航欄以及其它不同頁面共享的公共區域的關鍵詞。③去除停用詞。停用詞是指沒有具體意義的詞彙,例如“的”“在”等。
當搜尋引擎得到這篇網頁的關鍵詞後,會用自身的分詞系統,將此文分成一個分詞列表,然後儲存在資料庫中,並與此文的URL進行一一對應。下面我舉例說明。
假如蜘蛛爬取的頁面的URL是http://www.seozhao.com/2.html,而搜尋引擎在此頁面經過上述操作後提取到的關鍵詞集合為p,且p是由關鍵詞p1,p2,……,pn組成,則在百度資料庫中,其相互間的關係是一一對應,如下圖。
2.消除重複與轉載網頁。
每個搜尋引擎其識別重複頁面的演算法均不相同,但是其中Mr.Zhao認為,如果將消重演算法理解為由100個元素組成,那麼所有的搜尋引擎恐怕其80個元素都是完全一樣的。而另外20個元素,則是根據不同的搜尋引擎針對seo的態度不同,而專門設立的對應策略。本文僅對搜尋引擎大體流程進行初步講解,具體數學模型不多做講解。
3.重要資訊分析。
在進行程式碼除噪的過程中,搜尋引擎並非簡單的將其去除掉而已,而是充分利用網頁程式碼(例如H標籤、strong標籤)、關鍵詞密度、內鏈錨文字等方式分析出此網頁中最重要的片語。
4.網頁重要度分析。
通過指向該網頁的外鏈錨文字所傳遞的權重數值,來為此網頁確定一個權重數值,同時結合上述的“重要資訊分析”,從而確立此網頁的關鍵詞集合p中每一個關鍵詞所具備的排名系數。
5.倒排檔案。
正如上文所說,使用者在查詢時所得到的查詢結果並非是及時的,而是在搜尋引擎的快取區已經大體排好的,當然搜尋引擎不會未卜先知,他不會知道使用者會查詢哪些關鍵詞,但是他可以建立一個關鍵詞詞庫,而當其處理使用者查詢請求的時候,會將其請求按照詞庫進行分詞。那麼這樣下來,搜尋引擎就可以在使用者產生查詢行為之前,將詞庫中的每一個關鍵詞其對應的URL排名先行計算好,這樣就大大節省了處理查詢的時間了。
簡單來說,搜尋引擎用控制器來控制蜘蛛爬取,然後將URL集與原始資料庫進行儲存,儲存之後再用索引器控制每個關鍵詞與URL之間的對應關係,並將其儲存在索引資料庫中。
下面我們來舉例說明。
假若http://www.seozhao.com/2.html頁面被切詞成p={p1,p2,p3,……,pn},則其在索引資料庫中由下圖方式體現。
上圖是為了方便大家便於理解而做出來的,索引資料庫實際上是搜尋引擎中對效能要求最高的資料庫,因為裡面所有因素都會受到演算法影響,所以實際上的索引資料庫我覺得應該是由多維陣列所組成的較為複雜的索引表,但其主要體現的大體作用與上圖相同。
三、查詢服務
查詢服務顧名思義,就是處理使用者在搜尋介面的查詢請求。搜尋引擎構建檢索器,然後分三步來處理請求。
1.根據查詢方式與關鍵詞進行切詞。
首先先把使用者搜尋的關鍵詞切分為一個關鍵詞序列,我們暫時用q來表示,則使用者搜尋的關鍵詞q被切分為q={q1,q2,q3,……,qn}。
然後再根據使用者查詢方式,例如是所有詞連在一起,還是中間有空格等,以及根據q中不同關鍵詞的詞性,來確定所需查詢詞中每一個詞在查詢結果的展示上所佔有的重要性。
2.搜尋結果排序。
我們有了搜尋詞集合q,q中每個關鍵詞所對應的URL排序——索引庫,同時也根據使用者的查詢方式與詞性計算出每個關鍵詞在查詢結果的展示上所佔有的重要,那麼只需要進行一點綜合性的排序演算法,搜尋結果就出來了。
3.展示搜尋結果與文件摘要。
當有了搜尋結果後,搜尋引擎就會將搜尋結果展示在使用者閱覽的介面上以供使用者使用。
在這裡,大家可以思考兩個個問題。
大家在搜尋介面中經常發現百度展示的摘要是使用者搜尋詞周圍的,如果我不僅僅只看第一頁,多往後翻一些頁,會看到有些結果由於其目標頁面本身並未完全包含搜尋詞,而在百度提取的摘要中標紅詞僅是部分搜尋詞,那麼我們可以這樣理解,百度在搜尋詞不被完全包含的情況下,是不是應該優先展現在分詞結果中被百度認為較為重要的詞呢?那麼從這些搜尋結果中我們是不是就可以看出百度分詞演算法的部分端倪呢?
②有時候頁面中會多次出現搜尋詞,而百度搜尋結果頁面中在網站摘要部分僅會顯示部分,通常這麼部分是連續的,那我們是不是可以理解在摘要部分,百度會優先展示頁面中它認為與對此搜尋詞最重要的部分呢?那麼由此我們是不是可以揣度出百度針對頁面除噪後對不同部分賦予權重的演算法呢?
這兩個問題仁者見仁智者見智,做SEO的朋友們自己去探索與摸索吧,Mr.Zhao不敢在此無人子弟。
四、現今百度的流程漏洞
請原諒我用流程漏洞來形容這個模組,但我不得不說,在如今點選器橫行的天下,我覺得說是漏洞無可厚非。
那就是除了上面三個大環節外,百度還構建了使用者行為模組,來影響原始資料庫與索引庫。而影響原始資料庫的,是百度的快照投訴,主要處理網際網路暴利的一些行為,這點無可厚非。而影響索引庫的,是使用者的點選行為,這個設計本身也無可厚非,但百度演算法的不成熟,導致了點選器作弊猖獗。
百度的使用者行為分析模組很簡單,除了自身投訴的提交入口外,就是蒐集使用者在搜尋介面的點選行為,如果此頁面結果被大部分使用者閱覽,但沒有產生點選,使用者居然大部分選擇點選第二頁甚至更後面的頁面,則此現象就會被百度工程師們所知道,則會根據這方面來微調演算法。如今百度針對不同行業,其演算法早已不同了。
如果前兩頁內某個搜尋介面被大量使用者選擇點選,則通常會在24小時候,這個搜尋結果被大幅前提,甚至會被提升至第一名。
五、搜尋引擎大體流程圖(加上使用者行為分析器)
以上就是我所對搜尋引擎工作的基礎流程與原理的理解。
最後我想說廣大的SEO從業者們應該已經發現無論是百度還是谷歌或者其它的商業搜尋引擎,他們都會要求seoer們不要去在意演算法、不要去在意搜尋引擎,而是去多關注使用者體驗。這裡我們可以理解成一個比喻,搜尋引擎是買西瓜的人,而SEO們是種西瓜的人,買西瓜的人要求我們這些種西瓜的人不要關心他們挑選西瓜的標準,而是多多在意怎麼去種出好西瓜,而對於什麼樣的西瓜是他們需要的好西瓜,他們又往往用一些模糊的概念掩蓋過去。誠然,這樣搜尋引擎得到的結果將會多樣化,他們可以在挑選結果時有更多的選擇,能夠最大限度的維護這些商業搜尋引擎自身的利益,但是請其也不要忘記,我們這些種西瓜的也要有口飯吃。
Mr.Zhao始終堅持白帽SEO,深入研究UE,做對使用者有意義的站。但與此同時,我也堅信身為seoer,我們還應該對演算法有及時瞭解,以便我們做出的站在符合使用者口味的時候,更能在搜尋引擎中得到良好的展現,因為畢竟seoer也是人,也希望過得好一點。
相關文章
- 搜尋引擎-03-搜尋引擎原理
- 搜尋引擎原理及使用
- 後端技術雜談2:搜尋引擎工作原理後端
- 程式設計師的基礎生存技能:搜尋引擎程式設計師
- Nebula 基於 ElasticSearch 的全文搜尋引擎的文字搜尋Elasticsearch
- 【預研】搜尋引擎基礎——inverted index(倒排索引)Index索引
- 搜尋引擎es-分詞與搜尋分詞
- 深度解析搜尋引擎的原理結構
- 搜尋引擎與前端SEO前端
- MPLS基礎與工作原理
- 分散式搜尋引擎Elasticsearch基礎入門學習分散式Elasticsearch
- Solr搜尋基礎Solr
- Lucene : 基於Java的全文搜尋引擎Java
- 工作流引擎的工作原理與功能
- 海量資料搜尋---搜尋引擎
- 9個基於Java的搜尋引擎框架Java框架
- 後端技術雜談1:搜尋引擎基礎倒排索引後端索引
- 搜尋引擎和知識圖譜那些事 (上).基礎篇
- 47_初識搜尋引擎_search api的基礎語法介紹API
- 自建搜尋引擎-基於美麗雲
- 基於 Elasticsearch 的站內搜尋引擎實戰Elasticsearch
- 苦苦的搜尋真正工作後開發專案流程
- Django單元測試與搜尋引擎Django
- Meta 標籤與搜尋引擎優化優化
- ElasticSearch全文搜尋引擎Elasticsearch
- 搜尋引擎語法
- 搜尋引擎命令大全
- 搜尋引擎程式碼
- 搜尋引擎面試題面試題
- 搜尋引擎必看的入門書籍——《搜尋引擎:資訊檢索實踐》
- 基於c++或C的開源搜尋引擎C++
- Elasticsearch線上搜尋引擎讀寫核心原理深度認知-搜尋系統線上實戰Elasticsearch
- python 寫的搜尋引擎Python
- 直播平臺開發,基礎搜尋方式之拼音搜尋
- 構建高效能分散式搜尋引擎(Wcf-基礎篇)一薦分散式
- 使用Google百度等搜尋引擎的常用搜尋技巧Go
- Mac上神奇的內建搜尋引擎——Spotlight(聚焦搜尋)Mac
- 8 個基於 Lucene 的開源搜尋引擎推薦