之前在沒有接觸到云計算之前，只是對云計算有一點點模糊的概念，覺得這是一個很高大上的東西，似乎離我們的還很遠。經過老師的介紹和建議，我拜讀了Google的三大論文，不敢說理解，至少囫圇吞棗啃下了一大堆看不明白的理論。現在就我淺薄的理解，簡單聊聊Google File System
首先我們要知道Google GFS是一種檔案系統，是一個面向大規模資料密集型應用的、可擴展的分布式檔案系統。GFS雖然運行在廉價的普遍硬體設備上，但是它依然了提供災難冗余的能力，為大量客戶機提供了高性能的服務。
那么他既然是一種檔案系統，他首先就具有與過去的分布式檔案系統很多相同的目標。但是，對于GFS的設計還是以對自己的應用的負載情況和技識訓境的分析為基礎的，不管現在還是將來，GFS和早期的分布式檔案系統的設想都有明顯的不同。
一、設計思路上的不同
1.組件失效被認為是常態事件，而不是意外事件。
2.按照傳統的標準，檔案都非常大。設計中操作的引數、塊的大小必須要重新考慮。對大型的檔案的管理一定要能做到高效，對小型的檔案也必須支持，但不必優化。
3.大部分檔案的更新是通過添加新資料完成的，而不是改變已存在的資料。
4.作業量主要由兩種讀操作構成：對大量資料的流方式的讀操作和對少量資料的隨機方式的讀操作
5、作業量還包含許多對大量資料進行的、連續的、向檔案添加資料的寫操作。所寫的資料的規模和讀相似。一旦寫完，檔案很少改動。 在隨機位置對少量資料的寫操作也支持，但不必非常高效。
6、系統必須高效地實作定義完好的大量客戶同時向同一個檔案的添加操作的語意。
二、結構體系
一個GFS集群包含了一個單獨的Master節點（Master）、多臺Chunk服務器（Chunkserver），并且同時被多個客戶端（Client）訪問。
Master：管理元資料、整體協調系統活動
ChunkServer：存盤維護資料塊，讀寫檔案資料
Client：向Master請求元資料，并根據元資料訪問對應ChunkServer的Chunk
三、GFS主要需要關注的幾個問題
（1）系統由許多廉價的普通組件組成，組件失效是一種常態。系統必須持續監控自身的狀態，它必須將組件失效作為一種常態，能夠迅速地偵測、冗余并恢復失效的組件
（2）系統存盤一定數量的大檔案，以通常的標準衡量，我們的檔案非常巨大，采用管理數億個KB大小的小檔案的方式非常不明智，因此，設計的假設條件和引數，比如I/O操作和Block的尺寸都需要重新考慮
四、啟示
無論是硬體設計還是軟體設計，一個好的系統應當是一適用性廣泛、高性能、可靠性非常高的。為了達到這樣一個并不容易的目的，我們除了付出不懈努力，去提高單一部件的性能，也可以考慮通過科學的任務分配，讓一個由成本低廉的部件的集群共同分擔風險。尤其是在當前硬體技術瀕臨極限，性能需求水漲船高的當下，用數量保證質量，靠概率保證性能不失為一種可靠的選擇。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/39307.html
上一篇：未來IT計算發展趨勢