1、Bigtable 結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng) 下2010-10-20【google論文四】Bigtable：結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)(下)搜索2010-10-1622：36：43閱讀0評論0字號：大中小訂閱轉(zhuǎn)載請注明：作者phylipsbmy 7.性能評價我們建立了一個N個tablet服務(wù)器的Bigtable集群來丈量Bigtable伴隨著N的變化的性能和可擴展性。Tablet服務(wù)器配置成由含有1G內(nèi)存400GIDE硬盤的1786個機器組成的GFScell寫進(jìn)。N個客戶端為這些測試天生工作負(fù)載。(我們使用與tablet服務(wù)器相同數(shù)目的客戶端來保證客戶端不會成為瓶頸)。每個機器有一個雙核Opt

2、eron2GHz芯片，供運行的進(jìn)程使用的足夠的物理內(nèi)存，一個gigabit以太網(wǎng)鏈路。機器通過一個兩級樹狀交換機網(wǎng)絡(luò)連接，根節(jié)點總體帶寬接近100-200Gbps。所有機用具有相同的主機配置，因此任意兩個機器間的往返時間小于1ms。Tablet服務(wù)器和master，測試客戶端，GFS服務(wù)器都運行在相同的機器集合上。每個機器運行一個GFS服務(wù)器。另外這些機器要么運行一個tablet服務(wù)器要么運行一個客戶端進(jìn)程，或者一些其他同時使用這些機器的job的進(jìn)程。R是測試集中Bigtable行關(guān)鍵字的個數(shù)，通過對它的取值進(jìn)行選擇使得每個tablet服務(wù)器每個基準(zhǔn)測試讀寫接近1G的數(shù)據(jù)。順序?qū)懟鶞?zhǔn)測試使用0

3、-R-1作為行關(guān)鍵字。這個行關(guān)鍵字空間又被劃分為相同大小的10N個相同大小的區(qū)間。這些區(qū)間通過一個中心調(diào)度器分配給N個客戶端，當(dāng)客戶端處理完分配給它的前一個區(qū)間后就繼續(xù)分配給它下一個區(qū)間處理分配是動態(tài)的，中心調(diào)度器維護(hù)一個未分配集合，當(dāng)發(fā)現(xiàn)某個客戶端完成后，就給它下一個區(qū)間，而不是每個客戶端一開始就分配了10個固定區(qū)間。這種動態(tài)分配有助于減輕客戶端機器上的其他進(jìn)程造成的性能影響。在每個行關(guān)鍵字下我們寫一個字符串，這個字符串是隨機天生的，因此也是未壓縮的。另外，不同行關(guān)鍵字下的字符串是不同的，因此跨行的壓縮也是不可能的。隨機寫基準(zhǔn)測試與之類似，除了在寫之前行關(guān)鍵字是經(jīng)過hash然后模R得到的，這

4、樣對于整個測試過程來說，寫負(fù)載就可以在整個行空間上隨機分布。順序讀基準(zhǔn)測試與順序?qū)懖捎昧送耆嗤男嘘P(guān)鍵字天生方式。但是它不是在一個行關(guān)鍵字下寫，而是讀該行關(guān)鍵字下存儲的字符串(由前面調(diào)用的順序?qū)懟鶞?zhǔn)測試寫的)。類似的，隨機讀基準(zhǔn)測試的操縱對應(yīng)著隨機寫基準(zhǔn)測試操縱。掃描基準(zhǔn)測試類似于順序讀基準(zhǔn)測試，但是它使用了BigtableAPI對于掃描一個行組的所有值的操縱支持。通過使用掃描操縱，可以降低基準(zhǔn)測試程序所執(zhí)行的RPC調(diào)用次數(shù)，由于此時的一次RPC會從一個tablet服務(wù)器上獲取一大串的值。隨機讀(mem)基準(zhǔn)測試類似于隨機讀基準(zhǔn)測試，但是包含基準(zhǔn)測試數(shù)據(jù)的localitygroup是被標(biāo)記為

5、in-memory的。因此讀操縱只需要與tablet服務(wù)器內(nèi)存交互而不需要讀GFS。對于這個基準(zhǔn)測試，我們將每個tablet服務(wù)器的數(shù)據(jù)從1GB降低到了100MB,這樣它就可以很輕易地放到tablet服務(wù)器的內(nèi)存里。圖6展示了當(dāng)我們從Bigtable讀寫1000字節(jié)的value值時的測試程序性能。其中表格展示了每個tablet服務(wù)器的每秒操縱數(shù)；圖形展示了每秒的操縱總數(shù)。單tablet服務(wù)器性能我們首先來考慮單tablet服務(wù)器性能。隨機讀要比所有其他操縱慢。每個隨機讀操縱需要將64KB大小的SSTable塊從GFS傳輸?shù)絫ablet服務(wù)器，在這些數(shù)據(jù)里只有1000字節(jié)會被使用。Tablet服

6、務(wù)器每秒大概執(zhí)行1200次讀操縱，從GFS傳輸?shù)膫鬏斔俾蚀蟾?5MB/s。在這個帶寬級別下，會由于網(wǎng)絡(luò)協(xié)議棧,SSTable解析,Bigtable代碼的耗費占掉大量的服務(wù)器的CPU，同時也幾乎占滿了我們系統(tǒng)的帶寬。大部分具有這種訪問模式的Bigtable應(yīng)用需要將塊大小設(shè)成一個更小的值，通常是8KB。從內(nèi)存中的隨機讀要更快些，由于這1000個字節(jié)的讀是從tablet的本地內(nèi)存中直接讀取的，不需要從GFS中獲取一個大的64KB塊。隨機和順序?qū)懕入S機讀的執(zhí)行效率更高是由于每個tablet服務(wù)器將所有的寫進(jìn)請求寫到一個commitlog里，然后使用按組提交來有效的將這些寫進(jìn)交給GFS。在隨機寫和順序

7、寫之間并沒有明顯的不同；在這兩種情況下，對于tablet服務(wù)器的所有寫進(jìn)都是記錄在同一個commitlog里。順序?qū)懕入S機寫執(zhí)行的更好，由于從GFS獲取的64KBSSTable塊會被存儲到我們的塊緩存里，用來為下面的64個請求服務(wù)。掃描甚至更快，由于tablet服務(wù)器可以在客戶真?zhèn)€一次RPC請求中返回更大量的value，因此RPC的耗費可以平攤到大量的value上。擴展性當(dāng)我們將tablet服務(wù)器的數(shù)目從1增長到500時，整體的吞吐率有上百倍的增長。比如從內(nèi)存中隨機讀的性能當(dāng)tablet服務(wù)器數(shù)目增長了500倍時增長了300倍。發(fā)生這種情況是由于對于這個基準(zhǔn)測試的性能瓶頸在tablet服務(wù)器C

8、PU數(shù)。然而，性能也不是線性增長的。對于大多數(shù)基準(zhǔn)測試來說，當(dāng)從1增加到50個tablet服務(wù)器時，單服務(wù)器的吞吐率有一個明顯的下降。這個下降是由于多個服務(wù)器時的負(fù)載不均衡導(dǎo)致的，通常是由于需要網(wǎng)絡(luò)和CPU的進(jìn)程引起的。我們的負(fù)載平衡算法會嘗試解決這種題目，但是無法完美的完成。主要有兩個原因：為了減少tablet的移動重新的平衡會被抑制(當(dāng)tablet移動時，它會在短時間內(nèi)不可用，通常小于1秒)，隨著測試程序的執(zhí)行它天生的負(fù)載也在變化。隨機讀基準(zhǔn)測試表現(xiàn)出最糟糕的可擴展性(當(dāng)服務(wù)器數(shù)目增長了500倍后，它只增長了100倍)。發(fā)生這種情況的原因(正如前面所述)是對于每個1000字節(jié)的讀操縱我們都

9、需要在網(wǎng)絡(luò)上傳輸64KB大小的一個塊。這個傳輸會消耗掉我們網(wǎng)絡(luò)的1GB共享帶寬，這樣當(dāng)我們增加機器數(shù)目的時候吞吐率就會明顯降低。8.實際應(yīng)用截至2006年8月，有388個非測試Bigtable集群運行在google機器群上，總共大概有24500個tablet服務(wù)器。表1顯示了每個集群上的tablet服務(wù)器個數(shù)的粗略分布情況。這些集群大部分是用于開發(fā)目的，因此很多時候可能都是空閑的。在14個比較忙的集群中，總共有8069個tablet服務(wù)器，每秒有超過120萬個請求，741MB/s的RPC輸進(jìn)流量，以及16GB/s的RPC輸出流量。表2提供了一些關(guān)于現(xiàn)在正在使用的表的數(shù)據(jù)。一些表為用戶存儲數(shù)據(jù)，

10、一些為批處理程序存儲數(shù)據(jù)；這些表在總大小，均勻cell大小，保存在內(nèi)存中的數(shù)據(jù)比例，以及表的schema上跨度很大。在該節(jié)的剩余部分，我們將扼要描述google的三個產(chǎn)品如何使用Bigtable。8.1google分析Google分析是一個幫助站長分析它們站點的流量模式的服務(wù)。它提供整體的統(tǒng)計，比如天天內(nèi)的不同的訪問者數(shù)目，每個URL天天的訪問數(shù)，以及一些站點反饋報告，比如那些打開了某特定頁面后的訪問者進(jìn)行了交易的比例。為了使用這項服務(wù)，站長需要在他們的頁面里嵌進(jìn)一個小javascript程序。它會將關(guān)于請求的各項信息記錄在google分析里，比如用戶標(biāo)識以及該網(wǎng)頁被獲取的信息。Google分

11、析對這些數(shù)據(jù)進(jìn)行分析并給站長使用。我們扼要描述Google分析使用的兩個表。原始的點擊表(大概200TB)為每個終端用戶會話維護(hù)一條記錄。行的名稱是一個由站點名稱，以及會話創(chuàng)建時間組成的元祖。這種schema使得那些訪問相同站點的會話是相鄰的，而且是按照時間排序的，這個表格可以壓縮到原始大小的14%。摘要表格(大概20TB)包含對每個站點各種預(yù)定義的摘要。這個表格是通過周期性調(diào)度的MapReducejobs從原始點擊表天生出來的。每個MapReducejob從原始點擊表抽取出最近的會話數(shù)據(jù)。系統(tǒng)整體的吞吐率由GFS的吞吐率決定，這個表格可以壓縮為原始大小的29%。8.2google地球Goog

12、le提供一組服務(wù)，使得用戶即可以通過網(wǎng)頁也可以通過google地球客戶端軟件訪問地球表面的高分辨率衛(wèi)星圖像。這些產(chǎn)品答應(yīng)用戶瀏覽地球表面：他們可以在不同的分辨率上拍攝，觀看，注釋衛(wèi)星圖像。系統(tǒng)使用一個表來預(yù)處理數(shù)據(jù)，用另外一些表來為用戶提供數(shù)據(jù)。預(yù)處理流程使用一個表來存儲原始圖像。在預(yù)處理期間，圖像清理合并為終極的服務(wù)數(shù)據(jù)。這個表大概有70TB數(shù)據(jù)，因此是從硬盤上提供的。圖像本來已進(jìn)行了壓縮，因此Bigtable的壓縮選項被關(guān)掉了。圖像表里的每一行對應(yīng)一個地理區(qū)域，行的命名方式保證相鄰的地理位置會被存儲到鄰近的位置。表格包含一個列族來保存每個區(qū)域的數(shù)據(jù)源。這個列族有大量的列：每個列保存一個原始

13、數(shù)據(jù)圖片。由于每個區(qū)域僅僅從是幾個圖片構(gòu)建出來的，因此這個列族是很稀疏的。這個預(yù)處理流程依靠于MapReduce在Bigtable上進(jìn)行數(shù)據(jù)轉(zhuǎn)換。在Masterjobs運行期間，整個系統(tǒng)的每個tablet服務(wù)器處理速度超過1MB/s。服務(wù)系統(tǒng)使用一個表來索引存儲在GFS中的數(shù)據(jù)。這個表相對小一些(大概500GB)，但是每個數(shù)據(jù)中心每秒必須要為數(shù)千個查詢提供低延時服務(wù)。因此，這個表實際上保存在幾百個tablet服務(wù)器中，而且是作為in-memory列族進(jìn)行存儲。8.3個性化搜索個性化搜索是一個用來記錄用戶在google很多產(chǎn)品比如網(wǎng)頁搜索，圖像新聞搜索的查詢和點擊記錄的可選服務(wù)。用戶可以通過瀏覽

14、搜索歷史來查看過往的查詢和點擊，可以通過他們在google歷史記錄得到個性化的搜索結(jié)果。個性化搜索將每個用戶的數(shù)據(jù)保存在Bigtable里。每個用戶具有唯一的用戶id，并分配給他一個以用戶id命名的行。所有的用戶動作保存在表中。每個類型的動作用一個獨立的列族保存(比如有一個列族保存所有的網(wǎng)頁查詢)。每個數(shù)據(jù)元素使用對應(yīng)的動作發(fā)生的時間作為它在Bigtable中的時間戳。個性化搜索通過使用一個在Bigtable上的MapReduce產(chǎn)生用戶特征。這些特征被用來實時個性化搜索結(jié)果。為了進(jìn)步可用性和降低用戶延時，個性化搜索數(shù)據(jù)備份在多個Bigtable集群上。個性化搜索團(tuán)隊起初自己在Bigtable

15、之上建立了一個用戶端備份機制來保證所有備份的一致性。現(xiàn)在的系統(tǒng)使用的備份子系統(tǒng)已經(jīng)內(nèi)建到服務(wù)端了。個性化搜索存儲系統(tǒng)的設(shè)計答應(yīng)其他團(tuán)隊在他們的列中添加新的用戶信息?，F(xiàn)在這個系統(tǒng)已經(jīng)被很多其他需要存儲用戶配置和設(shè)置信息的google產(chǎn)品使用。多個團(tuán)隊間共享一個表使得表具有大量的列族。為了支持共享，我們給Bigtable添加了一個簡單的quota機制來限制共享表的用戶的存儲消耗。這個機制為不同產(chǎn)品團(tuán)隊使用該系統(tǒng)進(jìn)行用戶信息存儲提供了獨立性。9.經(jīng)驗教訓(xùn)在Bigtable的設(shè)計，實現(xiàn)，維護(hù)和支持過程中，我們獲得了很多經(jīng)驗以及一些教訓(xùn)。我們學(xué)到的第一個經(jīng)驗是：大型分布式系統(tǒng)在很多類型的失敗眼前是很脆弱

16、的，這些失敗不僅僅是標(biāo)準(zhǔn)的網(wǎng)絡(luò)分劃，各種分布式協(xié)議中的失敗。比如我們看到了由下面的各種原因引起的失?。簝?nèi)存和網(wǎng)絡(luò)損壞，大的時鐘誤差，機器掛起，擴展的非對稱的網(wǎng)絡(luò)分劃，我們使用的其他系統(tǒng)的bug(比如chubby)，GFSquota溢出，計劃的以及臨時的硬件維護(hù)。通過改變各種協(xié)議解決這些題目，我們得到了更多經(jīng)驗。比如，我們?yōu)槲覀兊腞PC機制增加了校驗和。我們也通過消除系統(tǒng)中的一部分對另一部分的依靠來處理一些題目。比如我們不再假設(shè)Chubby只會返回一組固定錯誤集合中的錯誤可能返回任意錯誤。我們學(xué)到的另一個經(jīng)驗是：將新feature的添加延遲到它會被怎樣使用清楚了時是很重要的。比如，一開始我們計劃

17、在API中提供一個通用目的事務(wù)支持。由于當(dāng)時我們沒有一個現(xiàn)實的使用需求，所以也沒有實現(xiàn)它?，F(xiàn)在我們有很多運行在Bigtable上的實際應(yīng)用，我們檢查它們的實際需求，發(fā)現(xiàn)大多數(shù)的應(yīng)用只需要一個單行事務(wù)。在已經(jīng)提出的分布式事務(wù)需求中，最重要的使用是用來維護(hù)secondary索引，我們計劃通過添加一個特殊的機制來滿足這個需求。新的機制不如分布式事務(wù)通用，但是會更有效(尤其是在數(shù)百行或者更多數(shù)據(jù)上進(jìn)行更新)也會能夠更好地與我們的跨數(shù)據(jù)中心的備份機制進(jìn)行交互。一個我們在進(jìn)行Bigtable支持中學(xué)到的比較特殊的經(jīng)驗是：合適的系統(tǒng)級監(jiān)控的重要性(比如即監(jiān)控Bigtable自身，同時還監(jiān)控使用Bigtabl

18、e的用戶進(jìn)程)。比如我們擴展RPC系統(tǒng)使得可以追蹤一次RPC中的重要動作。這個特點幫助我們檢測并解決了很多題目比如在tablet數(shù)據(jù)結(jié)構(gòu)上的鎖競爭，在提交Bigtable變更時的GFS上的低速寫，當(dāng)METADATAtablet不可用時造成的METADATA表不可訪問。另一個有用監(jiān)控的是每個Bigtable集群會注冊在Chubby。這就使得我們可以追蹤所有的集群，發(fā)現(xiàn)它們的大小，檢查它們使用的軟件版本，它們收到的流量，是否存在一些題目比如未預(yù)料到的大延時。我們學(xué)到的最重要的經(jīng)驗就是簡單設(shè)計的價值?？紤]到我們系統(tǒng)的規(guī)模(大概10萬行非測試代碼)，以及代碼會隨著時間的推移以不可預(yù)料的方式演變，我們發(fā)

19、現(xiàn)代碼和設(shè)計的清楚對于代碼的維護(hù)和調(diào)試有巨大的幫助。一個例子是我們的tablet服務(wù)器成員協(xié)議。我們最初的協(xié)議很簡單：master周期性的給tablet服務(wù)簽訂租約，當(dāng)租約過期后tablet服務(wù)器就會殺掉自己。不幸的是，這個協(xié)議很明顯地降低了在網(wǎng)絡(luò)題目出現(xiàn)時的可用性，而且對于master的恢復(fù)時間也很敏感。我進(jìn)行了多次設(shè)計才得到一個執(zhí)行的不錯的協(xié)議。然而終極的協(xié)議變得太復(fù)雜而且依靠于Chubby系統(tǒng)中那些很少被其他應(yīng)用所使用的feature。我們發(fā)現(xiàn)我們花費了大量時間調(diào)試令人費解的邊邊角角的題目，不僅僅是Bigtable代碼，有時還是在Chubby代碼里。最后，我們放棄了這個協(xié)議，使用了一個新

20、的簡化的協(xié)議，它只依靠于Chubby那些被廣泛使用的feature。10.相關(guān)工作Boxwood項目有些組件與Chubby，GFS，Bigtable在某些方面重疊，由于它提供了分布式協(xié)商，鎖，分布式chunk存儲，分布式B樹存儲。盡管存在這些方面的重疊，但是很明顯的是與對應(yīng)的Google服務(wù)相比Boxwood組件的定位是在更底層上。Boxwood項目的目標(biāo)是為建立上層服務(wù)比如文件系統(tǒng)或者數(shù)據(jù)庫提供基本的設(shè)施，而Bigtable的目標(biāo)則是直接支持那些需要存儲數(shù)據(jù)的用戶應(yīng)用程序。最近很多項目都是旨在解決提供分布式存儲和在廣域網(wǎng)上的上層服務(wù)的題目，通常是在整個互聯(lián)網(wǎng)范圍內(nèi)。這包括在分布式hash表上

21、的工作，對應(yīng)的項目有CAN，Chord，Tapestry和Pstry。這些項目關(guān)注點與Bigtable不同，比如高可用帶寬,不可信任成員，頻繁重配置，非中心式控制，拜占庭式容錯，這些都不是Bigtable的目標(biāo)。在提供給應(yīng)用程序開發(fā)者的分布式數(shù)據(jù)存儲模型上，我們相信由分布式B樹和分布式Hash表提供的key-value對模型太有限了。Key-value對是一種很有用的構(gòu)建模式，但是它們并不是可以提供給開發(fā)者的唯一模式。我們所選擇的模型要比簡單的Key-value模式豐富，支持半結(jié)構(gòu)化數(shù)據(jù)。然而，它仍然是足夠簡單地，使得在處理flat-file格式也很有效，同時它也答應(yīng)用戶透明地調(diào)整(通過loc

22、alitygroup)系統(tǒng)的重要行為。一些數(shù)據(jù)庫廠商已經(jīng)開發(fā)出了可以用來存儲大量數(shù)據(jù)的并行數(shù)據(jù)庫。Oracle的RAC(RealApplicationCluster)數(shù)據(jù)庫使用共享磁盤來存儲數(shù)據(jù)(Bigtable使用GFS)和一個分布式鎖治理器(Bigtable使用Chubby)。IBM的DB2并行版基于類似于Bigtable的非共享架構(gòu)。每個DB2服務(wù)器負(fù)責(zé)表中行的一個子集，存儲在本地的關(guān)系數(shù)據(jù)庫中。這兩個產(chǎn)品都提供了事務(wù)支持的完全的關(guān)系模型。Bigtable的localitygroup實現(xiàn)了與其他的基于列而不是基于行的磁盤數(shù)據(jù)組織系統(tǒng)(包括C-Store,以及一些貿(mào)易性產(chǎn)品比如Sybase

23、IQ,SenSage,KDB+,MonetDB/X100中的ColumnBM存儲層)類似的壓縮率和磁盤讀性能進(jìn)步。另一種將垂直和水平數(shù)據(jù)劃分到Flat文件，并且達(dá)到了很高壓縮率的系統(tǒng)是AT&T的Daytona數(shù)據(jù)庫。localitygroup并不支持Ailamaki描述的那些CPU緩存級的優(yōu)化。Bigtable使用memtable和SSTables存儲對于tablet更新的方式類似于Log-StructuredMergeTree存儲索引數(shù)據(jù)更新的方式。在這兩個系統(tǒng)中，已排序的數(shù)據(jù)在寫到磁盤之前都是要緩存在內(nèi)存中，讀的時候必須從內(nèi)存和磁盤里merger數(shù)據(jù)。C-Store和Bigtable有很多共同點：這兩個系統(tǒng)都使用了非共享的架構(gòu)，都有兩個數(shù)據(jù)結(jié)構(gòu)，一個用來保存最近的寫，一個用來保存長期存在的數(shù)據(jù)，存在一個把數(shù)據(jù)從一個搬到另一個的機制。這兩個系統(tǒng)在它們的API上存在明顯的不同：C-Store類似于一個關(guān)系數(shù)據(jù)庫，而Bigtable提供了底層的讀寫操縱接口，而且設(shè)計得可以支持每秒每個服務(wù)器數(shù)千次這樣的操縱。C-Store也可以說是一個讀優(yōu)化的關(guān)系型DBMS，而Bigtable則為讀敏感和寫敏感的應(yīng)用都提供了好的性能。Bigtable的負(fù)載平衡器需要解決與非共享數(shù)據(jù)庫碰到的一些相同的負(fù)載和內(nèi)存均衡題目。我們的題目要簡單一些：(1)我們不需要考慮相同數(shù)