雲端磁片：網路巨頭如何存儲資料

細想支援谷歌主頁搜索框需要的技術：背後的演算法，緩存的搜索詞，和其他一些隨之而來的特性，比如當你輸入一個位於資料存儲中的查詢時，基本相當於絕大多數網路的一個全文本快照。 當你和成千上萬的其他人同時提交搜索時，這個快照也正在不斷地隨著這些變化被更新著。 與此同時，資料是由數以千計的獨立伺服器進程處理的，每個都各司其職，從計算出給你提供的相關聯廣告，到決定搜尋結果的排列順序。

支援谷歌搜尋引擎的存儲系統必須能夠承受每天由運行于數以千計的伺服器上的成千上萬的獨立進程所發出的數百萬計的讀寫請求，幾乎不能停機來備份或維護，還必須不斷擴容以容納由谷歌網頁抓取機器人添加的日益擴大的眾多頁面。 總體下來，谷歌每天要處理超過20PB。

這可不是谷歌可以從一個現成的存儲架構就能完成的。 而且對於運行超大規模的資料中心的其他網路和雲計算巨頭來說也是如此，比如亞馬遜和Facebook。 雖然大多數資料中心已經通過在一個存儲區網路添加更多硬碟容量來解決擴充存儲的問題，更多的存儲伺服器，通常是更多的資料庫伺服器，因為雲環境的性能限制，這些方法卻失效了。 在雲環境下，任何時候都可能有成千上萬的活躍使用者的資料，而且資料的讀寫在任何時刻都能達到數千TB。

這不僅僅是一個關於磁片讀寫速度的簡單問題。 以這些卷上的資料流程來講，主要的問題是存儲網路的輸送量;即使有最好的交換器和存儲伺服器，傳統的SAN架構也能成為資料處理的性能瓶頸。

接下來就是老生常談的擴大存儲的成本問題。 超大規模網路公司增加容量的頻率(舉個例子，亞馬遜現在每天為其資料中心增加的容量相當於整個公司在2001年全年的容量，根據亞馬遜副總裁傑姆斯·漢密爾頓的說法)，用大多數資料中心的同樣做法來擺平所需的存儲，依照所需的管理， 硬體和軟體成本，花費將是巨大的。 這種花費在關係資料庫被添加到混合資料庫時甚至更高，這取決於一個組織對它們的分割和複製如何處理。

對於這種不斷擴展和持久存儲的需求，驅使互聯網巨頭——谷歌，亞馬遜，Facebook，微軟等等——採取一種不同的存儲解決方案：基於物件存儲的分散式檔案系統。 這些系統至少都部分受到其他分散式集群檔案系統的啟發，如Red Hat的通用檔案系統和IBM的通用並行檔案系統。

這些雲巨頭的分散式檔案系統的架構把中繼資料(關於內容的資料)從它存儲的資料中分開。 這能通過多個副本對資料進行大量並行讀寫操作，並且拋掉了像「檔鎖定」這樣的概念。

這些分散式檔案系統的影響遠遠超出了它們為超大規模資料中心而創建的範疇——它們會直接影響那些使用公共雲服務的公司(比如亞馬遜的EC2，谷歌的AppEngine和微軟的Azure)如何開發和部署程式。 公司，大學和政府機構尋找一種快速存儲和提供大量資料訪問的方法正日益變成受雲巨頭們啟發的資料存儲系統的新階段。 因此有必要瞭解一下它們的發展史和過程中所做的工程折衷方案。

(責任編輯：蒙遺善)