Bigtable結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)下

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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