最近花了不少功夫在Google釋出的這些文章上。Google這幾年釋出了不少的論文來介紹它底層分布式的計算平台，其中最重要的有5篇，其中包括了大名鼎鼎的MapReduce，GFS，也有不那麼出名的chubby：
GoogleCluster： http://research.google.com/archive/googlecluster.html
Chubby：http://labs.google.com/papers/chubby.html
GFS：http://labs.google.com/papers/gfs.html
BigTable：http://labs.google.com/papers/bigtable.html
MapReduce：http://labs.google.com/papers/mapreduce.html
這裡寫的就是我看Google Cluster的一些筆記和心得。希望有時間也能把其它的幾篇都整理出來。
這個圖就是一個普通的Query所要經過的整個邏輯流程。
首先，一個query（例如www.google.com/search?q=ieee+society）被使用者輸入到浏覽器。
浏覽器會通過DNS得到對應的www.google.com的IP。由于整個google的service包含了幾個分布在全球不同地方的cluster（每個包含上千台機器），DNS需要選擇一個最合适的cluster（選擇的标準要考慮到使用者的地理位置等等）。
于是，使用者的浏覽器将這個query以HTTP的方式發送到這個cluster。這個cluster的一個LoadBalancer會将query發送到 其中的一個GoogleWebServer（GWS）機器上。這個GWS會協調整個query的執行過程，并将結果以HTML的方式傳回給浏覽器。
而上面的這個圖表示的正是query在一個cluster上的執行過程。
這個執行過程又分為兩部分。
第一部分是對索引的查找。在資訊檢索中，所有的Document會被聚合成一個很大的反向索引（inverted index），可以看成是一個很大的二維表。我們需要查找這個索引，找到哪些包含了query詞的Document并計算出相似度（google用的是 pagerank）。這個相似度決定了結果的排序。
這個索引的查找在工程上是一個很大的挑戰，因為整個反向索引是非常大的（幾十TB的級别）。google的解決思路是将整個index切分成許多小塊，這樣，對于各個小塊的查詢就可以并行進行，最後再将結果彙總（MapReduce就是這樣的...）。
最後，查找得到的結果就是一列Document的ID号。
第二部分則是對實際的Document的操作。使用第一部分得到的ID号，通過Document Server來找到對應的Document，這些Document需要進行一定的處理，例如Summary（我們搜尋後得到的結果不就是一組網站的摘要 麼），然後将結果傳回給使用者。其中，使用ID查找對應Document的過程和第一部分類似，也是通過将整個Document集合切分成許多小份再分别進 行查找。
除了這兩部分以外，可能還包括一些例如拼寫檢查或者廣告之類的子產品。如圖所示。
從上面的整個query執行過程可以看出，google總是積極地将一個application盡可能的并行化，例如将index切成小份，或者将 Document切成小份然後并行處理。在這種情況下，單純的CPU的峰值計算能力就顯得不那麼重要了，因為可以通過增加更多的機器，進而将index切 成更小份然後并行計算來提高計算能力。舉個例子，一台計算能力是4的機器所能夠達到的性能，在這種并行計算下可以通過4台計算能力為1的機器得到。正是因 為如此，是以google在挑選cluster的機器的時候，考慮的并不是機器單純的performance，而是考慮它的成本效益（price- performance ratio）和它的能耗。這一點非常重要，很多人都知道google的cluster采用的就是我們常人所用的普通的PC機，但通過這篇文章我們可以知 道，google之是以這樣做并不是因為想标新立異，而是因為采用普通的PC機并不會帶來性能的損失，而且整體費用甚至更低。
此外，google cluster還有其它一些有趣的特性。
例如，google cluster儲存資料使用了大量的副本。一份資料在cluster中都有幾份副本。這樣做有幾個好處，首先，可以提高吞吐量，因為多個副本就意味着對同一組資料可以同時進行操作，其次，還滿足了容錯性的需求。
還有，從上面的query過程我們可以發現，大部分的操作都是read-only的，update操作相對而言非常稀少。是以在一個副本的資料 update的時候，可以将正在它上面進行的query操作轉移走。也就說不存在對一個資料同時讀和寫的情況。這樣做非常有意義，因為回避了一個在普通的 DataBase中非常重要的問題，即資料的一緻性（consistency）。
google cluster的容錯也與衆不同。它甚至都沒有采用RAID這樣的措施，所有的可靠性保障和容錯性能都是基于software的。
總結
google cluster的設計原則包括：
1. 軟體層面的安全可靠保障。
2. 使用資料的副本。
3. 成本效益甚于peak performance。
4. 采用日常的PC。
不僅僅是google cluster，還包括MapReduce，GFS，他們之是以現在如此成功，我認為一個很重要的原因就在于需求非常的明确。在設計之初就沒有遵循傳統的方式，而是針對實際當中的要求給出了不同的思路，這種量身定制決定了他們的成功。
Google這篇文章的後部分主要描述了根據這些原則怎樣去挑選合适的機器，包含了大量的實踐和細節。有興趣的可以看看。
由于我自己也是剛剛開始接觸這方面的知識，有任何了解不當之處歡迎批評指正。