細(xì)想支持谷歌主頁搜索框需要的技術(shù)：背后的算法，緩存的搜索詞，和其他一些隨之而來的特性，比如當(dāng)你輸入一個(gè)位于數(shù)據(jù)存儲中的查詢時(shí)，基本相當(dāng)于絕大多數(shù)網(wǎng)絡(luò)的一個(gè)全文本快照。當(dāng)你和成千上萬的其他人同時(shí)提交搜索時(shí)，這個(gè)快照也正在不斷地隨著這些變化被更新著。與此同時(shí)，數(shù)據(jù)是由數(shù)以千計(jì)的獨(dú)立服務(wù)器進(jìn)程處理的，每個(gè)都各司其職，從計(jì)算出給你提供的相關(guān)聯(lián)廣告，到?jīng)Q定搜索結(jié)果的排列順序。

支持谷歌搜索引擎的存儲系統(tǒng)必須能夠承受每天由運(yùn)行于數(shù)以千計(jì)的服務(wù)器上的成千上萬的獨(dú)立進(jìn)程所發(fā)出的數(shù)百萬計(jì)的讀寫請求，幾乎不能停機(jī)來備份或維護(hù)，還必須不斷擴(kuò)容以容納由谷歌網(wǎng)頁抓取機(jī)器人添加的日益擴(kuò)大的眾多頁面?？傮w下來，谷歌每天要處理超過20PB。

這可不是谷歌可以從一個(gè)現(xiàn)成的存儲架構(gòu)就能完成的。而且對于運(yùn)行超大規(guī)模的數(shù)據(jù)中心的其他網(wǎng)絡(luò)和云計(jì)算巨頭來說也是如此，比如亞馬遜和Facebook。雖然大多數(shù)數(shù)據(jù)中心已經(jīng)通過在一個(gè)存儲區(qū)網(wǎng)絡(luò)添加更多硬盤容量來解決擴(kuò)充存儲的問題，更多的存儲服務(wù)器，通常是更多的數(shù)據(jù)庫服務(wù)器，因?yàn)樵骗h(huán)境的性能限制，這些方法卻失效了。在云環(huán)境下，任何時(shí)候都可能有成千上萬的活躍用戶的數(shù)據(jù)，而且數(shù)據(jù)的讀寫在任何時(shí)刻都能達(dá)到數(shù)千TB。

這不僅僅是一個(gè)關(guān)于磁盤讀寫速度的簡單問題。以這些卷上的數(shù)據(jù)流來講，主要的問題是存儲網(wǎng)絡(luò)的吞吐量;即使有最好的交換機(jī)和存儲服務(wù)器，傳統(tǒng)的SAN架構(gòu)也能成為數(shù)據(jù)處理的性能瓶頸。

接下來就是老生常談的擴(kuò)大存儲的成本問題。超大規(guī)模網(wǎng)絡(luò)公司增加容量的頻率(舉個(gè)例子，亞馬遜現(xiàn)在每天為其數(shù)據(jù)中心增加的容量相當(dāng)于整個(gè)公司在2001年全年的容量，根據(jù)亞馬遜副總裁杰姆斯·漢密爾頓的說法)，用大多數(shù)數(shù)據(jù)中心的同樣做法來擺平所需的存儲，依照所需的管理，硬件和軟件成本，花費(fèi)將是巨大的。這種花費(fèi)在關(guān)系數(shù)據(jù)庫被添加到混合數(shù)據(jù)庫時(shí)甚至更高，這取決于一個(gè)組織對它們的分割和復(fù)制如何處理。

對于這種不斷擴(kuò)展和持久存儲的需求，驅(qū)使互聯(lián)網(wǎng)巨頭——谷歌，亞馬遜，F(xiàn)acebook，微軟等等——采取一種不同的存儲解決方案：基于對象存儲的分布式文件系統(tǒng)。這些系統(tǒng)至少都部分受到其他分布式集群文件系統(tǒng)的啟發(fā)，如Red Hat的全局文件系統(tǒng)和IBM的通用并行文件系統(tǒng)。

這些云巨頭的分布式文件系統(tǒng)的架構(gòu)把元數(shù)據(jù)(關(guān)于內(nèi)容的數(shù)據(jù))從它存儲的數(shù)據(jù)中分開。這能通過多個(gè)副本對數(shù)據(jù)進(jìn)行大量并行讀寫操作，并且拋掉了像“文件鎖定”這樣的概念。

這些分布式文件系統(tǒng)的影響遠(yuǎn)遠(yuǎn)超出了它們?yōu)槌笠?guī)模數(shù)據(jù)中心而創(chuàng)建的范疇——它們會直接影響那些使用公共云服務(wù)的公司(比如亞馬遜的EC2，谷歌的AppEngine和微軟的Azure)如何開發(fā)和部署程序。公司，大學(xué)和政府機(jī)構(gòu)尋找一種快速存儲和提供大量數(shù)據(jù)訪問的方法正日益變成受云巨頭們啟發(fā)的數(shù)據(jù)存儲系統(tǒng)的新階段。因此有必要了解一下它們的發(fā)展史和過程中所做的工程折衷方案。