云計(jì)算第三版Google云計(jì)算原理與應(yīng)用講義_第1頁(yè)
云計(jì)算第三版Google云計(jì)算原理與應(yīng)用講義_第2頁(yè)
云計(jì)算第三版Google云計(jì)算原理與應(yīng)用講義_第3頁(yè)
云計(jì)算第三版Google云計(jì)算原理與應(yīng)用講義_第4頁(yè)
云計(jì)算第三版Google云計(jì)算原理與應(yīng)用講義_第5頁(yè)
已閱讀5頁(yè),還剩66頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用目錄

2.1Google文件系統(tǒng)GFS2.2分布式數(shù)據(jù)處理MapReduce2.3分布式鎖服務(wù)Chubby2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.5分布式存儲(chǔ)系統(tǒng)Megastore2.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper2.7海量數(shù)據(jù)的交互式分析工具Dremel2.8內(nèi)存大數(shù)據(jù)分析系統(tǒng)PowerDrill2.9Google應(yīng)用程序引擎云計(jì)算第三版Google云計(jì)算原理與應(yīng)用初步了解ChubbyChubby是Google設(shè)計(jì)的提供粗粒度鎖服務(wù)的一個(gè)文件系統(tǒng),它基于松耦合分布式系統(tǒng),解決了分布的一致性問題。通過使用Chubby的鎖服務(wù),用戶可以確保數(shù)據(jù)操作過程中的一致性Chubby作為一個(gè)穩(wěn)定的存儲(chǔ)系統(tǒng)存儲(chǔ)包括元數(shù)據(jù)在內(nèi)的小數(shù)據(jù)Google內(nèi)部還使用Chubby進(jìn)行名字服務(wù)(NameServer)2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Paxos算法

Paxos算法LeslieLamport最先提出的一種基于消息傳遞(MessagesPassing)的一致性算法,用于解決分布式系統(tǒng)中的一致性問題

分布式系統(tǒng)一致性問題——就是如何保證系統(tǒng)中初始狀態(tài)相同的各個(gè)節(jié)點(diǎn)在執(zhí)行相同的操作序列時(shí),看到的指令序列是完全一致的,并且最終得到完全一致的結(jié)果

一個(gè)最簡(jiǎn)單的方案——在分布式系統(tǒng)中設(shè)置一個(gè)專門節(jié)點(diǎn),在每次需要進(jìn)行操作之前,系統(tǒng)的各個(gè)部分向它發(fā)出請(qǐng)求,告訴該節(jié)點(diǎn)接下來系統(tǒng)要做什么。該節(jié)點(diǎn)接受第一個(gè)到達(dá)的請(qǐng)求內(nèi)容作為接下來的操作,這樣就能夠保證系統(tǒng)只有一個(gè)唯一的操作序列方案存在什么缺陷?云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Paxos算法缺陷——專門節(jié)點(diǎn)失效,整個(gè)系統(tǒng)就很可能出現(xiàn)不一致。為了避免這種情況,在系統(tǒng)中必然要設(shè)置多個(gè)專門節(jié)點(diǎn),由這些節(jié)點(diǎn)來共同決定操作序列

Paxos算法

proposers提出決議(Value,系統(tǒng)接下來執(zhí)行的指令)acceptors批準(zhǔn)決議learners獲取并使用已經(jīng)通過的決議

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Paxos算法proposersacceptorslearners提出決議批準(zhǔn)決議獲取并使用已經(jīng)通過的決議三類節(jié)點(diǎn)決議只有在被proposers提出后才能批準(zhǔn)每次只批準(zhǔn)一個(gè)決議只有決議確定被批準(zhǔn)后learners才能獲取這個(gè)決議三個(gè)條件2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用系統(tǒng)的約束條件p1:每個(gè)acceptor只接受它得到的第一個(gè)決議。p2:一旦某個(gè)決議得到通過,之后通過的決議必須和該決議保持一致。p2a:一旦某個(gè)決議v得到通過,之后任何acceptor再批準(zhǔn)的決議必須是v。p2b:一旦某個(gè)決議v得到通過,之后任何proposer再提出的決議必須是v。p2c:如果一個(gè)編號(hào)為n的提案具有值v,那么存在一個(gè)“多數(shù)派”,要么它們中沒有誰(shuí)批準(zhǔn)過編號(hào)小于n的任何提案,要么它們進(jìn)行的最近一次批準(zhǔn)具有值v。為了保證決議的唯一性,acceptors也要滿足一個(gè)約束條件:當(dāng)且僅當(dāng)acceptors沒有收到編號(hào)大于n的請(qǐng)求時(shí),acceptors才批準(zhǔn)編號(hào)為n的提案。2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用一個(gè)決議分為兩個(gè)階段準(zhǔn)備階段12批準(zhǔn)階段proposers選擇一個(gè)提案并將它的編號(hào)設(shè)為n將它發(fā)送給acceptors中的一個(gè)“多數(shù)派”acceptors收到后,如果提案的編號(hào)大于它已經(jīng)回復(fù)的所有消息,則acceptors將自己上次的批準(zhǔn)回復(fù)給proposers,并不再批準(zhǔn)小于n的提案。當(dāng)proposers接收到acceptors中的這個(gè)“多數(shù)派”的回復(fù)后,就向回復(fù)請(qǐng)求的acceptors發(fā)送accept請(qǐng)求,在符合acceptors一方的約束條件下,acceptors收到accept請(qǐng)求后即批準(zhǔn)這個(gè)請(qǐng)求。2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用546Chubby的設(shè)計(jì)目標(biāo)主要有以下幾點(diǎn)高可用性和高可靠性213高擴(kuò)展性支持粗粒度的建議性鎖服務(wù)服務(wù)信息的直接存儲(chǔ)支持通報(bào)機(jī)制支持緩存機(jī)制2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用系統(tǒng)設(shè)計(jì)目標(biāo)Chubby系統(tǒng)設(shè)計(jì)高可用性和高可靠性;首要目標(biāo),在保證這一目標(biāo)的基礎(chǔ)上再考慮系統(tǒng)的吞吐量和存儲(chǔ)能力

高擴(kuò)展性;將數(shù)據(jù)存儲(chǔ)在價(jià)格較為低廉的RAM,支持大規(guī)模用戶訪問文件

支持粗粒度的建議性鎖服務(wù);提供這種服務(wù)的根本目的是提高系統(tǒng)的性能

服務(wù)信息的直接存儲(chǔ);可直接存儲(chǔ)包括元數(shù)據(jù)、系統(tǒng)參數(shù)在內(nèi)的有關(guān)服務(wù)信息支持通報(bào)機(jī)制;客戶可以及時(shí)地了解到事件發(fā)生支持緩存機(jī)制;通過一致性緩存將常用信息保存在客戶端,避免了頻繁地訪問主服務(wù)器云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby系統(tǒng)設(shè)計(jì)Chubby中還添加了一些新的功能特性;這種設(shè)計(jì)主要是考慮到以下幾個(gè)問題

030201開發(fā)者初期很少考慮系統(tǒng)的一致性,但隨著開發(fā)進(jìn)行,問題會(huì)變得越來越嚴(yán)重。單獨(dú)的鎖服務(wù)可以保證原有系統(tǒng)架構(gòu)不會(huì)發(fā)生改變,而使用函數(shù)庫(kù)很可能需要對(duì)系統(tǒng)架構(gòu)做出大幅度的改動(dòng)系統(tǒng)中很多事件發(fā)生是需要告知其他用戶和服務(wù)器,使用一個(gè)基于文件系統(tǒng)的鎖服務(wù)可以將這些變動(dòng)寫入文件中。有需要的用戶和服務(wù)器直接訪問這些文件即可,避免因大量系統(tǒng)組件之間事件通信帶來系統(tǒng)性能下降基于鎖的開發(fā)接口容易被開發(fā)者接受。雖然在分布式系統(tǒng)中鎖的使用會(huì)有很大的不同,但是和一致性算法相比,鎖顯然被更多的開發(fā)者所熟知云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby系統(tǒng)設(shè)計(jì)Paxos算法實(shí)現(xiàn)過程中需要一個(gè)“多數(shù)派”就某個(gè)值達(dá)成一致,本質(zhì)上就是分布式系統(tǒng)中常見的quorum機(jī)制;為保證系統(tǒng)高可用性,需要若干臺(tái)機(jī)器,但使用單獨(dú)鎖服務(wù)的話一臺(tái)機(jī)器也能保證這種高可用性Chubby設(shè)計(jì)過程中一些細(xì)節(jié)問題值得關(guān)注:在Chubby系統(tǒng)中采用了建議性的鎖而沒有采用強(qiáng)制性的鎖。兩者的根本區(qū)別在于用戶訪問某個(gè)被鎖定的文件時(shí),建議性的鎖不會(huì)阻止訪問,而強(qiáng)制性的鎖則會(huì)阻止訪問,實(shí)際上這是為了方便系統(tǒng)組件之間的信息交互另外,Chubby還采用了粗粒度(Coarse-Grained)鎖服務(wù)而沒有采用細(xì)粒度(Fine-Grained)鎖服務(wù),兩者的差異在于持有鎖的時(shí)間,細(xì)粒度的鎖持有時(shí)間很短云計(jì)算第三版Google云計(jì)算原理與應(yīng)用客戶端應(yīng)用程序客戶端應(yīng)用程序Chubby程序率Chubby程序率…遠(yuǎn)程過程調(diào)用Chubby單元的五個(gè)服務(wù)器主服務(wù)器客戶端進(jìn)程Chubby的基本架構(gòu)在客戶這一端每個(gè)客戶應(yīng)用程序都有一個(gè)Chubby程序庫(kù)(ChubbyLibrary),客戶端的所有應(yīng)用都是通過調(diào)用這個(gè)庫(kù)中的相關(guān)函數(shù)來完成的。服務(wù)器一端稱為Chubby單元,一般是由五個(gè)稱為副本(Replica)的服務(wù)器組成的,這五個(gè)副本在配置上完全一致,并且在系統(tǒng)剛開始時(shí)處于對(duì)等地位??蛻舳朔?wù)器端2.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby中的Paxos單個(gè)Chubby副本結(jié)構(gòu)容錯(cuò)日志——對(duì)數(shù)據(jù)庫(kù)正確性提供重要支持;一致性由Paxos算法保證;副本之間通過特定的Paxos協(xié)議通信,同時(shí)本地文件中保存與Chubby中相同的日志數(shù)據(jù)容錯(cuò)數(shù)據(jù)庫(kù)——快照(Snapshot)和記錄數(shù)據(jù)庫(kù)操作重播日志(Replay-log);每一次的數(shù)據(jù)庫(kù)操作最終都將提交至日志中;本地文件中也保存著一份數(shù)據(jù)庫(kù)數(shù)據(jù)副本Chubby構(gòu)建在這個(gè)容錯(cuò)的數(shù)據(jù)庫(kù)之上,Chubby利用這個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)所有的數(shù)據(jù)。Chubby的客戶端通過特定的Chubby協(xié)議和單個(gè)的Chubby副本進(jìn)行通信云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby中的Paxos容錯(cuò)日志的API

ContentTitle

ContentTitleChubby中Paxos算法過程

2、協(xié)調(diào)者從客戶提交的值中選擇一個(gè),accept消息廣播給所有的副本,其他的副本收到廣播后,選擇接受或者拒絕這個(gè)值,并將決定結(jié)果反饋3、協(xié)調(diào)者收到大多數(shù)副本接受信息后,認(rèn)為達(dá)到了一致性,接著向相關(guān)副本發(fā)送一個(gè)commit消息

1、選擇一副本為協(xié)調(diào)者(Coordinator)

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby中的PaxosChubby設(shè)計(jì)者借鑒了Paxos的兩種解決機(jī)制:給協(xié)調(diào)者指派序號(hào)或限制協(xié)調(diào)者可以選擇的值

指派序號(hào)的方法

(1)在一個(gè)有n個(gè)副本系統(tǒng)中,為每個(gè)副本分配一個(gè)id:ir,其中0≤ir≤n-1。則副本的序號(hào)s=k*n+ir,其中k的初始值為0

(2)某個(gè)副本想成為協(xié)調(diào)者之后,它就根據(jù)規(guī)則生成一個(gè)比它以前的序號(hào)更大的序號(hào)(實(shí)際上就是提高k的值),并將這個(gè)序號(hào)通過propose消息廣播給其他所有的副本

(3)如果接受到廣播的副本發(fā)現(xiàn)該序號(hào)比它以前見過的序號(hào)都大,則向發(fā)出廣播的副本返回一個(gè)promise消息,并且承諾不再接受舊的協(xié)調(diào)者發(fā)送的消息。如果大多數(shù)副本都返回了promise消息,則新的協(xié)調(diào)者就產(chǎn)生了

限制協(xié)調(diào)者可以選擇的值

Paxos強(qiáng)制新的協(xié)調(diào)者必須選擇和前任相同的值

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby中的PaxosChubby做了一個(gè)重要優(yōu)化來提高系統(tǒng)效率—在選擇某一個(gè)副本作為協(xié)調(diào)者之后就長(zhǎng)期不變,此時(shí)協(xié)調(diào)者就被稱為主服務(wù)器(Master)

客戶端的數(shù)據(jù)請(qǐng)求由主服務(wù)器完成,Chubby保證在一定時(shí)間內(nèi)有且僅有一個(gè)主服務(wù)器,這個(gè)時(shí)間就稱為主服務(wù)器租約期(MasterLease)客戶端需要確定主服務(wù)器的位置,可向DNS發(fā)送一個(gè)主服務(wù)器定位請(qǐng)求,非主服務(wù)器的副本將對(duì)該請(qǐng)求做出回應(yīng)Chubby對(duì)于Paxos論文中未提及的一些技術(shù)細(xì)節(jié)進(jìn)行了補(bǔ)充,所以Chubby的實(shí)現(xiàn)是基于Paxos,但其技術(shù)手段更加的豐富,更具有實(shí)踐性云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby文件系統(tǒng)Chubby系統(tǒng)本質(zhì)上就是一個(gè)分布式的、存儲(chǔ)大量小文件的文件系統(tǒng),它所有的操作都是在文件的基礎(chǔ)上完成Chubby最常用的鎖服務(wù)中,每一個(gè)文件就代表一個(gè)鎖,用戶通過打開、關(guān)閉和讀取文件,獲取共享(Shared)鎖或獨(dú)占(Exclusive)鎖選舉主服務(wù)器過程中,符合條件的服務(wù)器都同時(shí)申請(qǐng)打開某個(gè)文件并請(qǐng)求鎖住該文件成功獲得鎖的服務(wù)器自動(dòng)成為主服務(wù)器并將其地址寫入這個(gè)文件夾,以便其他服務(wù)器和用戶可以獲知主服務(wù)器的地址信息云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby文件系統(tǒng)Chubby的文件系統(tǒng)和UNIX類似

例如在文件名“/ls/foo/wombat/pouch”中,ls代表lockservice,這是所有Chubby文件系統(tǒng)的共有前綴;foo是某個(gè)單元的名稱;/wombat/pouch則是foo這個(gè)單元上的文件目錄或者文件名

Google對(duì)Chubby做了一些與UNIX不同的改變例如Chubby不支持內(nèi)部文件的移動(dòng);不記錄文件的最后訪問時(shí)間;另外在Chubby中并沒有符號(hào)連接(SymbolicLink,又叫軟連接,類似于Windows系統(tǒng)中的快捷方式)和硬連接(HardLink,類似于別名)的概念

在具體實(shí)現(xiàn)時(shí),文件系統(tǒng)由許多節(jié)點(diǎn)組成,分為永久型和臨時(shí)型,每個(gè)節(jié)點(diǎn)就是一個(gè)文件或目錄。節(jié)點(diǎn)中保存著包括ACL(AccessControlList,訪問控制列表)在內(nèi)的多種系統(tǒng)元數(shù)據(jù)云計(jì)算第三版Google云計(jì)算原理與應(yīng)用單調(diào)遞增的64位編號(hào)實(shí)例號(hào)InstanceNumber新節(jié)點(diǎn)實(shí)例號(hào)必定大于舊節(jié)點(diǎn)的實(shí)例號(hào)。1鎖生成號(hào)LockGenerationNumber鎖被用戶持有時(shí)該號(hào)增加。內(nèi)容生成號(hào)ContentGenerationNumber文件內(nèi)容修改時(shí)該號(hào)增加。23ACL生成號(hào)ACLGenerationNumberACL名被覆寫時(shí)該號(hào)增加。42.3分布式鎖服務(wù)Chubby云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby文件系統(tǒng)序號(hào):確定句柄由當(dāng)前還是以前的主服務(wù)器創(chuàng)建2模式信息:用于新的主服務(wù)器重新創(chuàng)建一個(gè)舊句柄

3用戶打開某個(gè)節(jié)點(diǎn)的同時(shí)會(huì)獲取一個(gè)類似于UNIX中文件描述符(FileDescriptor)的句柄,這個(gè)句柄由以下三個(gè)部分組成校驗(yàn)數(shù)位:防止其他用戶創(chuàng)建或猜測(cè)這個(gè)句柄

1云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby文件系統(tǒng)在實(shí)際執(zhí)行中,為了避免所有的通信都使用序號(hào)帶來系統(tǒng)開銷增長(zhǎng),Chubby引入了sequencer的概念sequencer實(shí)際上就是一個(gè)序號(hào),只能由鎖的持有者在獲取鎖時(shí)向系統(tǒng)發(fā)出請(qǐng)求來獲得。這樣一來Chubby系統(tǒng)中只有涉及鎖的操作才需要序號(hào),其他一概不用。在文件操作中,用戶可以將句柄看做一個(gè)指向文件系統(tǒng)的指針

函數(shù)名稱作用Open()打開某個(gè)文件或者目錄來創(chuàng)建句柄Close()關(guān)閉打開的句柄,后續(xù)的任何操作都將中止Poison()中止當(dāng)前未完成及后續(xù)的操作,但不關(guān)閉句柄GetContentsAndStat()返回文件內(nèi)容及元數(shù)據(jù)GetStat()只返回文件元數(shù)據(jù)ReadDir()返回子目錄名稱及其元數(shù)據(jù)SetContents()向文件中寫入內(nèi)容SetACL()設(shè)置ACL名稱Delete()如果該節(jié)點(diǎn)沒有子節(jié)點(diǎn)的話則執(zhí)行刪除操作Acquire()獲取鎖Release()釋放鎖GetSequencer()返回一個(gè)sequencerSetSequencer()將sequencer和某個(gè)句柄進(jìn)行關(guān)聯(lián)CheckSequencer()檢查某個(gè)sequencer是否有效常用句柄函數(shù)及其作用

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby系統(tǒng)設(shè)計(jì)Chubby基本架構(gòu):客戶端和服務(wù)器端,兩者通過遠(yuǎn)程過程調(diào)用(RPC)來連接客戶端每個(gè)客戶應(yīng)用程序都有一個(gè)Chubby程序庫(kù)(ChubbyLibrary),所有應(yīng)用都是通過調(diào)用這個(gè)庫(kù)中相關(guān)函數(shù)來完成服務(wù)器一端Chubby單元,一般由五個(gè)稱為副本(Replica)服務(wù)器組成,它們配置上完全一致,且系統(tǒng)剛開始時(shí)處于對(duì)等地位云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby客戶端與服務(wù)器端的通信過程

從左到右的水平方向表示時(shí)間在增加,斜向上的箭頭表示一次KeepAlive請(qǐng)求,斜向下的箭頭則是主服務(wù)器的一次回應(yīng)

M1、M2、M3表示不同的主服務(wù)器租約期;C1、C2、C3則是客戶端對(duì)主服務(wù)器租約期時(shí)長(zhǎng)做出的一個(gè)估計(jì)

KeepAlive是周期發(fā)送的一種信息,它主要有兩方面的功能:延遲租約的有效期和攜帶事件信息告訴用戶更新

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用可能出現(xiàn)的兩種故障2.3分布式鎖服務(wù)Chubby客戶端租約過期主服務(wù)器出錯(cuò)12云計(jì)算第三版Google云計(jì)算原理與應(yīng)用客戶端租約過期故障處理

客戶端租約過期

客戶端向主服務(wù)器發(fā)出一個(gè)KeepAlive請(qǐng)求(上圖1)如果有需要通知的事件時(shí)則主服務(wù)器會(huì)立刻做出回應(yīng),否則等到客戶端的租約期C1快結(jié)束的時(shí)候才做出回應(yīng)(圖2),并更新主服務(wù)器租約期為M2客戶端接到回應(yīng)后認(rèn)為該主服務(wù)器仍處于活躍狀態(tài),于是將租約期更新為C2并立刻發(fā)出新的KeepAlive請(qǐng)求(圖3)寬限期內(nèi),客戶端不會(huì)立刻斷開其與服務(wù)器端的聯(lián)系,而是不斷地做探詢,當(dāng)它接到客戶端的第一個(gè)KeepAlive請(qǐng)求(圖4)時(shí)會(huì)拒絕(圖5)客戶端在主服務(wù)器拒絕后使用新紀(jì)元號(hào)來發(fā)送KeepAlive請(qǐng)求(圖6)新的主服務(wù)器接受這個(gè)請(qǐng)求并立刻做出回應(yīng)(圖7)如果客戶端接收到這個(gè)回應(yīng)的時(shí)間仍處于寬限期內(nèi),系統(tǒng)會(huì)恢復(fù)到安全狀態(tài),租約期更新為C3。如果在寬限期未接到主服務(wù)器的相關(guān)回應(yīng),客戶端終止當(dāng)前的會(huì)話云計(jì)算第三版Google云計(jì)算原理與應(yīng)用主服務(wù)器出錯(cuò)故障處理

主服務(wù)器出錯(cuò)

正常情況下舊的主服務(wù)器出現(xiàn)故障后系統(tǒng)會(huì)很快地選舉出新的主服務(wù)器,新選舉需要經(jīng)歷以下九個(gè)步驟:(1)產(chǎn)生一個(gè)新的紀(jì)元號(hào)以便今后客戶端通信時(shí)使用,這能保證當(dāng)前的主服務(wù)器不必處理針對(duì)舊的主服務(wù)器的請(qǐng)求(2)只處理主服務(wù)器位置相關(guān)的信息,不處理會(huì)話相關(guān)的信息(3)構(gòu)建處理會(huì)話和鎖所需的內(nèi)部數(shù)據(jù)結(jié)構(gòu)(4)允許客戶端發(fā)送KeepAlive請(qǐng)求,不處理其他會(huì)話相關(guān)的信息(5)向每個(gè)會(huì)話發(fā)送一個(gè)故障事件,促使所有的客戶端清空緩存(6)等待直到所有的會(huì)話都收到故障事件或會(huì)話終止(7)開始允許執(zhí)行所有的操作(8)如果客戶端使用了舊的句柄則需要為其重新構(gòu)建新的句柄(9)一定時(shí)間段后(1分鐘),刪除沒有被打開過的臨時(shí)文件夾如果這一過程在寬限期內(nèi)順利完成,則用戶不會(huì)感覺到任何故障的發(fā)生,也就是說新舊主服務(wù)器的替換對(duì)于用戶來說是透明的,用戶感覺到的僅僅是一個(gè)延遲云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.3分布式鎖服務(wù)Chubby2.3.1Paxos算法2.3.2Chubby系統(tǒng)設(shè)計(jì)2.3.3Chubby中的Paxos2.3.4Chubby文件系統(tǒng)2.3.5通信協(xié)議2.3.6正確性與性能云計(jì)算第三版Google云計(jì)算原理與應(yīng)用一致性2.3分布式鎖服務(wù)Chubby正確性與性能每個(gè)Chubby單元是由五個(gè)副本組成的,這五個(gè)副本中需要選舉產(chǎn)生一個(gè)主服務(wù)器,這種選舉本質(zhì)上就是一個(gè)一致性問題安全性采用的是ACL形式的安全保障措施。只要不被覆寫,子節(jié)點(diǎn)都是直接繼承父節(jié)點(diǎn)的ACL名性能優(yōu)化提高主服務(wù)器默認(rèn)的租約期、使用協(xié)議轉(zhuǎn)換服務(wù)將Chubby協(xié)議轉(zhuǎn)換成較簡(jiǎn)單的協(xié)議、客戶端一致性緩存等云計(jì)算第三版Google云計(jì)算原理與應(yīng)用一致性

每個(gè)Chubby單元是由五個(gè)副本組成的,這五個(gè)副本中需要選舉產(chǎn)生一個(gè)主服務(wù)器,這種選舉本質(zhì)上就是一個(gè)一致性問題。實(shí)際執(zhí)行過程中,Chubby使用Paxos算法來解決

主服務(wù)器產(chǎn)生后客戶端的所有讀寫操作都是由主服務(wù)器來完成的

讀操作很簡(jiǎn)單,客戶直接從主服務(wù)器上讀取所需數(shù)據(jù)即可

寫操作就會(huì)涉及數(shù)據(jù)一致性的問題;為了保證客戶的寫操作能夠同步到所有的服務(wù)器上,系統(tǒng)再次利用了Paxos算法云計(jì)算第三版Google云計(jì)算原理與應(yīng)用安全性Chubby用ACL形式安全保障措施。系統(tǒng)有三種ACL名:寫ACL名(WriteACLName)、讀ACL名(ReadACLName)和變更ACL名(ChangeACLName)只要不被覆寫,子節(jié)點(diǎn)都是直接繼承父節(jié)點(diǎn)的ACL名ACL同樣被保存在文件中,它是節(jié)點(diǎn)元數(shù)據(jù)的一部分,用戶在進(jìn)行相關(guān)操作時(shí)首先需要通過ACL來獲取相應(yīng)的授權(quán)

Chubby的ACL機(jī)制

用戶chinacloud提出向文件CLOUD中寫入內(nèi)容請(qǐng)求。CLOUD首先讀取自身的寫ACL名fun,接著在fun中查到了chinacloud這一行記錄,于是返回信息允許chinacloud對(duì)文件進(jìn)行寫操作,此時(shí)chinacloud才被允許向CLOUD寫入內(nèi)容。其他的操作和寫操作類似云計(jì)算第三版Google云計(jì)算原理與應(yīng)用性能優(yōu)化

為滿足系統(tǒng)高可擴(kuò)展性,Chubby目前已經(jīng)采取了一些措施:比如提高主服務(wù)器默認(rèn)的租約期、使用協(xié)議轉(zhuǎn)換服務(wù)將Chubby協(xié)議轉(zhuǎn)換成較簡(jiǎn)單的協(xié)議、客戶端一致性緩存等;除此之外,Google的工程師們還考慮使用代理(Proxy)和分區(qū)(Partition)技術(shù)

代理可以減少主服務(wù)器處理KeepAlive以及讀請(qǐng)求帶來的服務(wù)器負(fù)載,但是它并不能減少寫操作帶來的通信量

使用分區(qū)技術(shù)的話可以將一個(gè)單元的命名空間(NameSpace)劃分成N份。除了少量的跨分區(qū)通信外,大部分的分區(qū)都可以獨(dú)自地處理服務(wù)請(qǐng)求。通過分區(qū)可以減少各個(gè)分區(qū)上的讀寫通信量,但不能減少KeepAlive請(qǐng)求的通信量云計(jì)算第三版Google云計(jì)算原理與應(yīng)用目錄

2.1Google文件系統(tǒng)GFS2.2分布式數(shù)據(jù)處理MapReduce2.3分布式鎖服務(wù)Chubby2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.5分布式存儲(chǔ)系統(tǒng)Megastore2.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper2.7海量數(shù)據(jù)的交互式分析工具Dremel2.8內(nèi)存大數(shù)據(jù)分析系統(tǒng)PowerDrill2.9Google應(yīng)用程序引擎云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.4.1設(shè)計(jì)動(dòng)機(jī)與目標(biāo)2.4.2數(shù)據(jù)模型2.4.3系統(tǒng)架構(gòu)2.4.4主服務(wù)器2.4.5子表服務(wù)器2.4.6性能優(yōu)化云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表BigtableBigtable的設(shè)計(jì)動(dòng)機(jī)123需要存儲(chǔ)的數(shù)據(jù)種類繁多海量的服務(wù)請(qǐng)求商用數(shù)據(jù)庫(kù)

無法滿足需求包括URL、網(wǎng)頁(yè)內(nèi)容、用戶的個(gè)性化設(shè)置在內(nèi)的數(shù)據(jù)都是Google需要經(jīng)常處理的Google運(yùn)行著目前世界上最繁忙的系統(tǒng),它每時(shí)每刻處理的客戶服務(wù)請(qǐng)求數(shù)量是普通的系統(tǒng)根本無法承受的一方面現(xiàn)有商用數(shù)據(jù)庫(kù)的設(shè)計(jì)著眼點(diǎn)在于其通用性。另一方面對(duì)于底層系統(tǒng)的完全掌控會(huì)給后期的系統(tǒng)維護(hù)、升級(jí)帶來極大的便利云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表BigtableBigtable應(yīng)達(dá)到的基本目標(biāo)廣泛的適用性很強(qiáng)的可擴(kuò)展性高可用性簡(jiǎn)單性Bigtable是為了滿足一系列Google產(chǎn)品而并非特定產(chǎn)品的存儲(chǔ)要求。根據(jù)需要隨時(shí)可以加入或撤銷服務(wù)器確保幾乎所有的情況下系統(tǒng)都可用底層系統(tǒng)的簡(jiǎn)單性既可以減少系統(tǒng)出錯(cuò)的概率,也為上層應(yīng)用的開發(fā)帶來便利云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.4.1設(shè)計(jì)動(dòng)機(jī)與目標(biāo)2.4.2數(shù)據(jù)模型2.4.3系統(tǒng)架構(gòu)2.4.4主服務(wù)器2.4.5子表服務(wù)器2.4.6性能優(yōu)化云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Bigtable數(shù)據(jù)的存儲(chǔ)格式2.4分布式結(jié)構(gòu)化數(shù)據(jù)表BigtableBigtable是一個(gè)分布式多維映射表,表中的數(shù)據(jù)通過一個(gè)行關(guān)鍵字(RowKey)、一個(gè)列關(guān)鍵字(ColumnKey)以及一個(gè)時(shí)間戳(TimeStamp)進(jìn)行索引Bigtable的存儲(chǔ)邏輯可以表示為:(row:string,column:string,time:int64)→stringBigtable對(duì)存儲(chǔ)在其中的數(shù)據(jù)不做任何解析,一律看做字符串云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Bigtable數(shù)據(jù)的存儲(chǔ)格式2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable假設(shè)想要拷貝一個(gè)可能被很多項(xiàng)目都使用的、很大的網(wǎng)頁(yè)集合以及相關(guān)的信息,把這個(gè)特定的表稱為Webtable。在Webtable當(dāng)中,使用URL作為行鍵,網(wǎng)頁(yè)的不同方面作為列鍵,并把網(wǎng)頁(yè)的內(nèi)容存儲(chǔ)在contents:column中,如圖所示圖存儲(chǔ)了網(wǎng)頁(yè)數(shù)據(jù)的Webtable的一個(gè)片段。行名稱是反轉(zhuǎn)的URL,contents列家族包含了網(wǎng)頁(yè)內(nèi)容,anchor列家族包含了任何引用這個(gè)頁(yè)面的anchor文本。CNN的主頁(yè)被SportsIllustrated和MY-look主頁(yè)同時(shí)引用,因此,行包含了名稱為”anchor:”和”anchor:my.look.ca”的列。每個(gè)anchor單元格都只有一個(gè)版本,contents列有三個(gè)版本,分別對(duì)應(yīng)于時(shí)間戳t3,t5和t6。云計(jì)算第三版Google云計(jì)算原理與應(yīng)用數(shù)據(jù)模型行

Bigtable的行關(guān)鍵字可以是任意的字符串,但是大小不能超過64KB。Bigtable和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)有很大不同,它不支持一般意義上的事務(wù),但能保證對(duì)于行的讀寫操作具有原子性(Atomic)

表中數(shù)據(jù)都是根據(jù)行關(guān)鍵字進(jìn)行排序的,排序使用的是詞典序。

一個(gè)典型實(shí)例,其中n.www就是一個(gè)行關(guān)鍵字。不直接存儲(chǔ)網(wǎng)頁(yè)地址而將其倒排是Bigtable的一個(gè)巧妙設(shè)計(jì)。這樣做至少會(huì)帶來以下兩個(gè)好處

同一地址域的網(wǎng)頁(yè)會(huì)被存儲(chǔ)在表中的連續(xù)位置,有利于用戶查找和分析

倒排便于數(shù)據(jù)壓縮,可以大幅提高壓縮率

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用數(shù)據(jù)模型列

Bigtable并不是簡(jiǎn)單地存儲(chǔ)所有的列關(guān)鍵字,而是將其組織成所謂的列族(ColumnFamily),每個(gè)族中的數(shù)據(jù)都屬于同一個(gè)類型,并且同族的數(shù)據(jù)會(huì)被壓縮在一起保存。引入了列族的概念之后,列關(guān)鍵字就采用下述的語(yǔ)法規(guī)則來定義:

族名:限定詞(family:qualifier)族名必須有意義,限定詞則可以任意選定圖中,內(nèi)容(Contents)、錨點(diǎn)(Anchor)都是不同的族。而和my.look.ca則是錨點(diǎn)族中不同的限定詞族同時(shí)也是Bigtable中訪問控制(AccessControl)基本單元,也就是說訪問權(quán)限的設(shè)置是在族這一級(jí)別上進(jìn)行的云計(jì)算第三版Google云計(jì)算原理與應(yīng)用數(shù)據(jù)模型時(shí)間戳

Google的很多服務(wù)比如網(wǎng)頁(yè)檢索和用戶的個(gè)性化設(shè)置等都需要保存不同時(shí)間的數(shù)據(jù),這些不同的數(shù)據(jù)版本必須通過時(shí)間戳來區(qū)分。圖2中內(nèi)容列的t3、t5和t6表明其中保存了在t3、t5和t6這三個(gè)時(shí)間獲取的網(wǎng)頁(yè)。Bigtable中的時(shí)間戳是64位整型數(shù),具體的賦值方式可以采取系統(tǒng)默認(rèn)的方式,也可以用戶自行定義為了簡(jiǎn)化不同版本的數(shù)據(jù)管理,Bigtable目前提供了兩種設(shè)置:一種是保留最近的N個(gè)不同版本,圖中數(shù)據(jù)模型采取的就是這種方法,它保存最新的三個(gè)版本數(shù)據(jù)。另一種就是保留限定時(shí)間內(nèi)的所有不同版本,比如可以保存最近10天的所有不同版本數(shù)據(jù)。失效的版本將會(huì)由Bigtable的垃圾回收機(jī)制自動(dòng)處理

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.4.1設(shè)計(jì)動(dòng)機(jī)與目標(biāo)2.4.2數(shù)據(jù)模型2.4.3系統(tǒng)架構(gòu)2.4.4主服務(wù)器2.4.5子表服務(wù)器2.4.6性能優(yōu)化云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Bigtable基本架構(gòu)2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表BigtableBigtable中Chubby的主要作用作用一選取并保證同一時(shí)間內(nèi)只有一個(gè)主服務(wù)器(MasterServer)。獲取子表的位置信息。保存Bigtable的模式信息及訪問控制列表。作用二作用三云計(jì)算第三版Google云計(jì)算原理與應(yīng)用系統(tǒng)架構(gòu)

Bigtable主要由三個(gè)部分組成:客戶端程序庫(kù)(ClientLibrary)、一個(gè)主服務(wù)器(MasterServer)和多個(gè)子表服務(wù)器(TabletServer)客戶訪問Bigtable服務(wù)時(shí),首先要利用其庫(kù)函數(shù)執(zhí)行Open()操作來打開一個(gè)鎖(實(shí)際上就是獲取了文件目錄),鎖打開以后客戶端就可以和子表服務(wù)器進(jìn)行通信和許多具有單個(gè)主節(jié)點(diǎn)分布式系統(tǒng)一樣,客戶端主要與子表服務(wù)器通信,幾乎不和主服務(wù)器進(jìn)行通信,這使得主服務(wù)器的負(fù)載大大降低主服務(wù)主要進(jìn)行一些元數(shù)據(jù)操作以及子表服務(wù)器之間負(fù)載調(diào)度問題,實(shí)際數(shù)據(jù)是存儲(chǔ)在子表服務(wù)器上

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.4.1設(shè)計(jì)動(dòng)機(jī)與目標(biāo)2.4.2數(shù)據(jù)模型2.4.3系統(tǒng)架構(gòu)2.4.4主服務(wù)器2.4.5子表服務(wù)器2.4.6性能優(yōu)化云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable主服務(wù)器新子表分配子表服務(wù)器狀態(tài)監(jiān)控子服務(wù)器之間的負(fù)載均衡當(dāng)一個(gè)新的子表產(chǎn)生時(shí),主服務(wù)器通過一個(gè)加載命令將其分配給一個(gè)空間足夠的子表服務(wù)器。創(chuàng)建新表、表合并以及較大子表的分裂都會(huì)產(chǎn)生一個(gè)或多個(gè)新子表。分割完成之后子服務(wù)器需要向主服務(wù)發(fā)出一個(gè)通知。主服務(wù)器必須對(duì)子表服務(wù)器的狀態(tài)進(jìn)行監(jiān)控,以便及時(shí)檢測(cè)到服務(wù)器的加入或撤銷云計(jì)算第三版Google云計(jì)算原理與應(yīng)用主服務(wù)器Bigtable中主服務(wù)表服務(wù)器的監(jiān)控是通過Chubby完成的——子表服務(wù)器在初始化時(shí)都會(huì)從Chubby中得到一器對(duì)子個(gè)獨(dú)占鎖。通過這種方式所有子表服務(wù)器基本信息被保存在Chubby中一個(gè)稱為服務(wù)器目錄(ServerDirectory)的特殊目錄之中。主服務(wù)器通過這個(gè)目錄可以隨時(shí)獲取最新的子表服務(wù)器信息,包括:

目前活躍的子表服務(wù)器;

每個(gè)子表服務(wù)器上現(xiàn)已分配的子表。云計(jì)算第三版Google云計(jì)算原理與應(yīng)用主服務(wù)器對(duì)于每個(gè)具體的子表服務(wù)器,主服務(wù)器會(huì)定期向其詢問獨(dú)占鎖的狀態(tài)。如果子表服務(wù)器的鎖丟失或沒有回應(yīng),則此時(shí)可能有兩種情況:要么是Chubby出現(xiàn)了問題(雖然這種概率很小,但的確存在,Google自己也做過相關(guān)測(cè)試)要么是子表服務(wù)器自身出現(xiàn)了問題。對(duì)此主服務(wù)器首先自己嘗試獲取這個(gè)獨(dú)占鎖,如果失敗說明Chubby服務(wù)出現(xiàn)問題,需等待恢復(fù);如果成功則說明Chubby服務(wù)良好而子表服務(wù)器本身出現(xiàn)了問題當(dāng)在狀態(tài)監(jiān)測(cè)時(shí)發(fā)現(xiàn)某個(gè)子表服務(wù)器上負(fù)載過重時(shí),主服務(wù)器會(huì)自動(dòng)對(duì)其進(jìn)行負(fù)載均衡操作

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用主服務(wù)器

基于系統(tǒng)出現(xiàn)故障是一種常態(tài)的設(shè)計(jì)理念,每個(gè)主服務(wù)器被設(shè)定了一個(gè)會(huì)話時(shí)間的限制。當(dāng)某個(gè)主服務(wù)器到時(shí)退出后,管理系統(tǒng)就會(huì)指定一個(gè)新的主服務(wù)器,這個(gè)主服務(wù)器的啟動(dòng)需要經(jīng)歷以下四個(gè)步驟:

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable從Chubby中獲取一個(gè)獨(dú)占鎖,確保同一時(shí)間只有一個(gè)主服務(wù)器Bigtable中Chubby的主要作用掃描服務(wù)器目錄,發(fā)現(xiàn)目前活躍的子表服務(wù)器與所有的活躍子表服務(wù)器取得聯(lián)系以便了解所有子表的分配情況通過掃描元數(shù)據(jù)表(MetadataTable),發(fā)現(xiàn)未分配的子表并將其分配到合適的子表服務(wù)器步驟1

步驟3

步驟2

步驟4如果元數(shù)據(jù)表未分配,則首先需要將根子表(RootTablet)加入未分配的子表中。由于根子表保存了其他所有元數(shù)據(jù)子表的信息,確保了掃描能夠發(fā)現(xiàn)所有未分配的子表云計(jì)算第三版Google云計(jì)算原理與應(yīng)用2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.4.1設(shè)計(jì)動(dòng)機(jī)與目標(biāo)2.4.2數(shù)據(jù)模型2.4.3系統(tǒng)架構(gòu)2.4.4主服務(wù)器2.4.5子表服務(wù)器2.4.6性能優(yōu)化云計(jì)算第三版Google云計(jì)算原理與應(yīng)用SSTable及子表基本結(jié)構(gòu)

SSTable是Google為Bigtable設(shè)計(jì)的內(nèi)部數(shù)據(jù)存儲(chǔ)格式。所有的SSTable文件都存儲(chǔ)在GFS上

SSTable結(jié)構(gòu)

子表實(shí)際組成

每個(gè)子表都是由多個(gè)SSTable以及日志(Log)文件構(gòu)成不同子表的SSTable可以共享SSTable中數(shù)據(jù)被劃分成一個(gè)個(gè)的塊(Block),每個(gè)塊的大小是可以設(shè)置的,一般為64KB在SSTable的結(jié)尾有一個(gè)索引(Index),這個(gè)索引保存了塊的位置信息,在SSTable打開時(shí)這個(gè)索引會(huì)被加載進(jìn)內(nèi)存,用戶在查找某個(gè)塊時(shí)首先在內(nèi)存中查找塊的位置信息,然后在硬盤上直接找到這個(gè)塊由于每個(gè)SSTable一般都不是很大,用戶還可以選擇將其整體加載進(jìn)內(nèi)存,這樣查找起來會(huì)更快

Bigtable中的日志文件是一種共享日志,每個(gè)子表服務(wù)器上僅保存一個(gè)日志文件,某個(gè)子表日志只是這個(gè)共享日志的一個(gè)片段。這樣會(huì)節(jié)省大量的空間,但在恢復(fù)時(shí)卻有一定的難度Google為了避免這種情況出現(xiàn),對(duì)日志做了一些改進(jìn)。Bigtable規(guī)定將日志的內(nèi)容按照鍵值進(jìn)行排序,這樣不同的子表服務(wù)器都可以連續(xù)讀取日志文件了一般來說每個(gè)子表的大小在100MB到200MB之間。每個(gè)子表服務(wù)器上保存的子表數(shù)量可以從幾十到上千不等,通常情況下是100個(gè)左右

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用64KB塊64KB塊…SSTable索引SSTable格式的基本示意2.4分布式結(jié)構(gòu)化數(shù)據(jù)表BigtableSSTable是Google為Bigtable設(shè)計(jì)的內(nèi)部數(shù)據(jù)存儲(chǔ)格式。所有的SSTable文件都存儲(chǔ)在GFS上,用戶可以通過鍵來查詢相應(yīng)的值。云計(jì)算第三版Google云計(jì)算原理與應(yīng)用子表實(shí)際組成日志64KB塊64KB塊…SSTable索引64KB塊64KB塊…SSTable索引…2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable不同子表的SSTable可以共享每個(gè)子表服務(wù)器上僅保存一個(gè)日志文件Bigtable規(guī)定將日志的內(nèi)容按照鍵值進(jìn)行排序每個(gè)子表服務(wù)器上保存的子表數(shù)量可以從幾十到上千不等,通常情況下是100個(gè)左右云計(jì)算第三版Google云計(jì)算原理與應(yīng)用Chubby文件根子表(元數(shù)據(jù)表中第一條記錄)………………用戶表1用戶表N其他元數(shù)據(jù)子表······子表地址組成2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable……···子表地址的查詢是經(jīng)常碰到的操作。在Bigtable系統(tǒng)的內(nèi)部采用的是一種類似B+樹的三層查詢體系

云計(jì)算第三版Google云計(jì)算原理與應(yīng)用所有子表地址都被記錄在元數(shù)據(jù)表中,元數(shù)據(jù)表也是由一個(gè)個(gè)的元數(shù)據(jù)子表(Metadatatablet)組成根子表是元數(shù)據(jù)表中一個(gè)比較特殊的子表,它既是元數(shù)據(jù)表的第一條記錄,也包含了其他元數(shù)據(jù)子表的地址,同時(shí)Chubby中的一個(gè)文件也存儲(chǔ)了這個(gè)根子表的信息。查詢時(shí),首先從Chubby中提取這個(gè)根子表的地址,進(jìn)而讀取所需的元數(shù)據(jù)子表的位置,最后就可以從元數(shù)據(jù)子表中找到待查詢的子表。除了這些子表的元數(shù)據(jù)之外,元數(shù)據(jù)表中還保存了其他一些有利于調(diào)試和分析的信息,比如事件日志等云計(jì)算第三版Google云計(jì)算原理與應(yīng)用為了減少訪問開銷,提高客戶訪問效率,Bigtable使用了緩存(Cache)和預(yù)?。≒refetch)技術(shù)

子表的地址信息被緩存在客戶端,客戶在尋址時(shí)直接根據(jù)緩存信息進(jìn)行查找。一旦出現(xiàn)緩存為空或緩

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論