The Google File System
為了更好的理解公司內部的分散式搜尋系統設計原理，讀了一遍大名鼎鼎的分散式儲存系統論文"The Google File System"。這裡主要記錄自己對這篇文章的理解(翻譯)。
背景
The Google File System(GFS)是google為自己的內部應用開發的一個分散式檔案系統，雖然這篇文章是2003年釋出已經過去了16年，但是還是非常值得我這樣的分散式新手學習的。
設計假設
因為是一個google自用的分散式檔案系統，因此係統在設計之初就是儘量考慮google內部的需求而非一個通用的檔案系統，在設計上會有一些特殊的地方，並沒有完全支援POSIX風格的介面。下面介紹一下其設計理念：
-
系統由眾多的普通機器組成:這是為了方便橫向擴充套件，增加系統的負載只需要通過簡單的增加機器即可。但是隨著叢集的增加，機器故障，網路故障的可能性也逐漸增加，這使得系統在設計時認為機器是不可靠的，系統中的機器隨時可能出錯，因此容錯是非常重要的一個設計目標；
- 寫入系統的檔案多數為大檔案: 這一點是基於google內部的需求考量的，比如爬蟲儲存，機器學習資料儲存，日誌儲存等。這一假設也很重要，因為這一點決定了系統可以將檔案分為更大的儲存塊，而不是常見的檔案系統的4KB的塊大小，後面會講到這樣做的好處；
- 檔案的寫入操作多為尾插: 這一假設也是基於google的內部需求，因為google內部任務很少有隨機寫入，這一點可以很好的幫助簡化系統，因為不需要為隨機寫入進行獨特的優化；
- 同一個檔案可能會有大量的併發寫入: 這一點需求需要保證系統在設計保證併發寫入不會出錯且需要有足夠的併發效率，因為併發的向分散式系統內寫入檔案是非常耗時的操作，GFS為了提高併發效率進行了非常優秀的設計，這個後面會提到；
- 高頻寬比低延時要更重要: 這也有一點基於內部需求的意思，因為google認為對於GFS的讀寫很少有人直接參與而是大量的計算，這些操作不需要低延時而是需要足夠的頻寬以方便計算時儘快拿到足夠多的資料，或者在寫入時系統能夠承受更大的負載。
系統架構
上面講完了系統設計時的一些基礎的假設，來看看GFS的基礎架構。GFS是一個分散式的系統，系統中的機器被分為兩種其一稱為master用於管理整個叢集，另一個則是大量的承載資料的機器稱為chunk server，下面這幅圖展示的是GFS的基礎架構以及客戶端從系統中讀取檔案的過程。
chunk
檔案被分成的一個個小塊，大小固定為64MB，GFS這樣選擇這個大小的理由可能有下面幾點：1. GFS儲存的多為幾個GB大小的大檔案，分割成較大的塊也不會有資料未寫完的塊兒產生磁碟損耗，事實上因為GFS採用的是惰性分配的策略未寫完的塊也不會浪費儲存空間；2.較大的塊可以減少客戶端與master的通訊次數因為一次較大的塊允許客戶端在這個塊做更多的讀寫操作；3. 較大的塊可以減少master儲存的資訊。
檔案塊chunk在建立時即被分配全域性唯一的識別符號64bit，這可以保證每個chunk的全域性唯一性。一個chunk可以有多個副本，儲存在不同的機器上，因為如前所述的假設GFS認為機器故障資料丟失是非常常見的而非罕見的異常情況，因此需要為每個chunk建立多個副本以保證即使在機器故障時系統依舊不會丟失資料。
master
未完待續...