本節書摘來自異步社群《資料中心設計與營運實戰》一書中的第2章，第2.5節,作者： 【美】luiz andré barroso , 【美】jimmy clidaras , 【瑞士】urs hölzle 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
web搜尋曾是最早的受歡迎的大規模網際網路服務之一，從20世紀90年代中期開始的網際網路内容的井噴，使處理如此大量的資訊超出了當時人工管理目錄的能力。然而，随着針對家庭和公司的網絡連接配接業務的持續增長，通過網際網路提供新的服務變得越來越有吸引力，有時甚至取代了傳統用戶端的功能。基于網頁的地圖和郵件服務就是這一發展趨勢的端倪。服務範圍的擴大也造成了應用需求極大的多樣性。例如，一個搜尋任務可能不需要一個具備細粒度更新能力的基礎架構，也就自然可以容忍硬體故障（因為web搜尋不需要每次都絕對的精準）。而對于追蹤使用者點選特定連結（廣告）的應用就是另外一回事了，每次點選廣告都是一個小型的财務交易，需要一個交易資料庫管理系統來保證。
一旦考慮多種服務的各種需求，資料中心也就必須成為通用計算系統。雖然專門的硬體解決方案對個别的服務來說非常适合，但随着需求範圍的拓寬，采用特别的硬體在操作層面越來越不現實。另外，工作負載的快速演變也使得專用硬體不可行。産品需求演變很快，聰明的程式員會汲取經驗，及時改寫底層算法和資料結構，而硬體無法做到如此快速的進化。是以，潛在風險在于當某個特别的硬體解決方案實施的時候，很可能就已經不适合原來要解決的問題了。
2.5.1 工作負載示例
這裡不會介紹網際網路服務工作負載的過多細節，主要是因為這一市場的動态特性使得這些細節在本書出版的時候已經過時。不過在較高的層面描述兩大類應用——線上服務和批（離線）處理系統——兩種工作負載還是有用的。接下來我們概述一下web搜尋應用的基本結構，以此作為一個線上服務的例子。再用一個使用mapreduce的基于引文相似度計算的例子來說明批處理工作負載。
2.5.2 線上應用：web搜尋
這是典型的“幹草垛撈針”問題。雖然很難确定任意時間點網頁的大小，但是毫無疑問網頁包含數千億的獨立文檔并且數目仍在不斷增長。假設網頁包含一千億個文檔，每個文檔壓縮後平均大小4kb，那麼“幹草垛”的規模則有約400tb之大。web搜尋資料庫就是一個建立在這個巨大存儲庫上的索引，通過倒排一系列文檔建立出如圖2.1所示的邏輯格式的存儲庫。
詞典結構把存儲庫裡的每個條目都關聯上一個id。這個條目的id标示出該條目出現過的文檔清單，以及一些前後關系資訊，比如位置和各種其他屬性等（例如該條目是否在标題檔）。
https://yqfile.alicdn.com/1fd4af69d76f64086eb8c8b8dc5a73bcf9c8d171.png" >
轉化後的索引大小取決于具體的實施情況，但仍然具備原有存儲庫的數量級。典型的搜尋查詢條件包含一組關鍵詞序列，系統的任務是找出包含該關鍵詞的所有文檔，并決定哪些文檔可能是使用者最滿意的結果。搜尋條件可以使用特殊的運算符（比如or運算符），或者限制在關鍵詞出現的特定序列（如短語符号）中搜尋。為簡單起見，這裡我們着重讨論比較普遍的and查詢。
舉例來說，比如要搜尋“紐約的飯館”。搜尋算法必須過濾所有分别包含“紐約”和“飯館”關鍵詞的釋出清單，直到找出同時包含這兩個關鍵詞的所有文檔。然後再将找到的文檔用不同的參數排序，比如文檔整體重要性（例如google采用pagerank 【116】），或者用與文檔中關鍵詞關聯的其他屬性排序（比如出現的頻率和位置等），最後将排名最靠前的結果呈現給使用者。
介于索引的龐大規模，搜尋算法的運作可能需要跨越幾千台機器。搜尋算法運作時，索引被分割成許多負載平衡的子檔案，再分布到所有機器上。索引的分區可以通過文檔或關鍵詞完成。網頁前端伺服器收到使用者搜尋請求後，将搜尋任務配置設定給索引群裡的所有機器。考慮到搜尋處理能力和容錯的必要性，索引子檔案的多個副本可以放置在不同的機器中，也就是說隻有部分機器參與了搜尋任務。索引服務的機器計算出本地結果，将預先排序得出的最優結果發送給前端系統（或中轉伺服器），前端系統再從所有叢集中選出最好的結果。這時隻有相應搜尋結果的網頁文檔id清單可知。第二階段需要計算出實際的标題、連結以及能為使用者提供搜尋關鍵詞語境的特定文檔片段。這一階段通過把文檔id清單發送給包含文檔副本的一組機器實作。如前所述，由于存儲庫内容很大，需要分區放置在大量伺服器上來完成。
上述運算的總使用者感覺延遲要求在幾分之一秒内，是以這種架構的重點在于減少延遲。不過，高吞吐量也是一項很重要的性能名額，因為有些受歡迎的服務需要支援每秒幾千條的查詢。索引是不斷頻繁更新的，但在處理單一查詢的時間粒度裡，索引可以看做隻讀結構。另外，因為索引隻有在最後合并步驟時才需要進行跨機器間查詢的互相通信，是以整個計算是非常有效率地并行運作。最終，由于不同的web搜尋任務間并無互相邏輯關聯，則更高層次的并行計算得以實作。
如果索引由文檔id進行分區，工作負載就平均帶寬而言有着相對較小的網絡需求，因為在機器間互相交換的資料量一般并不比搜尋查詢本身更大（一般在幾百位元組左右），不過也确實存在某些突發行為。一般來說，前端伺服器把單個查詢請求配置設定到大量伺服器上時就像一個流量放大器，這不僅在請求路徑上生成了一系列突發流量，在響應路徑上可能也是如此。是以，即使整體網絡使用率很低，也不能對網絡流量管理掉以輕心，這對于減少丢包至關重要。
最後，web搜尋作為線上服務将會受到正常的流量變化的影響，因為使用者每天不同時段在網頁上的活躍程度是不一樣的。圖2.2說明了這一點，高峰時段的流量是非高峰時段的兩倍以上。這種流量變化給系統營運者帶來了很大的挑戰，因為服務必須要能适應明顯高于一般行為的流量強度。
2.5.3 離線應用：學術文章相似度
要求網際網路服務提供大型計算的使用者請求例子有很多。這些計算通常是典型的資料并行處理任務，需要将資料準備好，或者打包提供給随後的線上服務使用。例如，計算pagerank或從web庫裡建立反向索引檔案就屬于這一類。再舉一個不同的例子：在學術論文期刊的庫裡搜尋相似的文章。這是網際網路服務一個非常有用的功能，擷取科學出版物，例如 “google scholar。文獻相似度關系對基于關鍵字的搜尋系統進行了補充，成為另一種發現關聯資訊的方法。找到一篇有興趣的文章後，使用者可以要求将所有與該文非常相關的文章都列出來。
計算相似度名額的方法有好幾種，用多種方法并将結果合并通常比較準确。對于學術文獻，衆所周知綜合使用不同的引文分析能計算出高品質的相似度名額。現在我們來看其中一種叫做“共引”的分析方法，其基本思路就是計算出同時引用文獻a和文獻b的文獻數量，以此做為文獻a與b之間的相似度名額。在完成所有計算并适當标準化後，我們可以得到一個文獻間相似度（共引）的數值，并建立出一個資料結構用來給每個文獻傳回一個根據共引值排序的相似文獻清單。這種資料結構周期性進行更新，每次更新後就成為線上服務的一部分。
計算開始時首先建立一個引用圖，反映出一個文獻與一組被引用文獻的映射關系。輸入資料被分成數百個相似大小的檔案（例如，可以通過提取文獻識别指紋，與輸入的檔案數量相除，再把餘數作為檔案id），進而實作高效的并行執行。我們運作一個mapreduce任務來獲得引用圖，并産生所有文獻的共引相似性名額向量。在第一個map階段，利用每個引文清單（a1、a2、a3. . .an）生成對檔案，再輸送到reduce階段計算所有對檔案出現的次數。第一步生成的結果是與所有共引對檔案相關聯的共引計數的資料結構。注意這會比平方級的計算量少很多，因為多數文檔都是零共引計數，因而被忽略不計。第二個mapreduce過程将給定的文檔輸入進行分組，将分數規範化，并以相似度分數遞減的順序生成一個文檔清單。
這種分兩步走的資料并行程式，以每個步驟相對輕量的計算任務運作在數百台伺服器上，然後每個階段的map與reduce之間出現大量的全局通信。然而與web搜尋不同，該網絡流量流動自然，對于現有的擁塞控制算法更加友好。而且與web搜尋相反，這種并行程式對并行計算延遲的敏感程度也不如搜尋任務。