【正文】 能干的人，不在情緒上計(jì)較，只在做事上認(rèn)真；無能的人！不在做事上認(rèn)真，只在情緒上計(jì)較。什么是奮斗？奮斗就是每天很難，可一年一年卻越來越容易。寧可累死在路上，也不能閑死在家里！寧可去碰壁，也不能面壁。這些應(yīng)用對(duì)Bigtable的要求以及使用的集群機(jī)器數(shù)量都是各不相同的，但是從實(shí)際運(yùn)行來看，Bigtable完全可以滿足這些不同需求的應(yīng)用，而這一切都得益于其優(yōu)良的構(gòu)架以及恰當(dāng)?shù)募夹g(shù)選擇。不過這種情況出現(xiàn)的概率非常小，跟它帶來的巨大好處相比這個(gè)缺點(diǎn)是可以忍受的。而且它有一個(gè)最大的好處是它絕不會(huì)將一個(gè)存在的子表判定為不存在。布隆在1970年提出的，實(shí)際上它是一個(gè)很長(zhǎng)的二進(jìn)制向量和一系列隨機(jī)映射函數(shù)，在讀操作中確定子表的位置時(shí)非常有用。3．布隆過濾器（Bloom Filter）Bigtable向用戶提供了一種稱為布隆過濾器[12]的數(shù)學(xué)工具。在文件正式轉(zhuǎn)移之前還要進(jìn)行一次壓縮，這次壓縮主要是將第一次壓縮后遺留的未壓縮空間進(jìn)行壓縮。壓縮技術(shù)還可以提高子表的恢復(fù)速度，當(dāng)某個(gè)子表服務(wù)器停止使用后，需要將上面所有的子表移至另一個(gè)子表服務(wù)器來恢復(fù)服務(wù)。通常情況下，用戶可以采用兩步壓縮的方式[8]：第一步利用Bentley amp。首先壓縮可以被用在構(gòu)成局部性群組的SSTable中，可以選擇是否對(duì)個(gè)人的局部性群組的SSTable進(jìn)行壓縮。對(duì)于一些較小的且會(huì)被經(jīng)常讀取的局部性群組，用戶可以將其SSTable文件直接加載進(jìn)內(nèi)存，這可以明顯地改善讀取效率。局部性群組如圖220所示。結(jié)合圖213的實(shí)例來看，在被Bigtable保存的網(wǎng)頁列關(guān)鍵字中，有的用戶可能只對(duì)網(wǎng)頁內(nèi)容感興趣，那么它可以通過設(shè)置局部性群組只看內(nèi)容這一列。1．局部性群組（Locality groups）Bigtable允許用戶將原本并不存儲(chǔ)在一起的數(shù)據(jù)以列族為單位，根據(jù)需要組織在一個(gè)單獨(dú)的SSTable中，以構(gòu)成一個(gè)局部性群組。這一部分主要向讀者介紹用戶可以使用的幾個(gè)重要優(yōu)化措施。這些手段在前面已經(jīng)有了簡(jiǎn)單的介紹，這里不再講解。 性能優(yōu)化上述各種操作已經(jīng)可以實(shí)現(xiàn)Bigtable的所有功能了，但是這些基本的功能很多時(shí)候并不是很符合用戶的使用習(xí)慣，或者執(zhí)行的效率較低。主壓縮其實(shí)是合并壓縮的一種，只不過它將所有的SSTable一次性壓縮成一個(gè)大的SSTable文件。由于讀操作要使用SSTable，數(shù)量過多的SSTable顯然會(huì)影響讀的速度。圖218 Bigtable數(shù)據(jù)存儲(chǔ)及讀寫操作圖219 三種形式壓縮之間的關(guān)系每一次舊的內(nèi)存表停止使用時(shí)都會(huì)進(jìn)行一個(gè)次壓縮操作，這會(huì)產(chǎn)生一個(gè)SSTable。在Bigtable中有三種形式的數(shù)據(jù)壓縮，分別是次壓縮（Minor Compaction）、合并壓縮（Merging Compaction）和主壓縮（Major Compaction）。在數(shù)據(jù)存儲(chǔ)中還有一個(gè)重要問題，就是數(shù)據(jù)壓縮的問題。數(shù)據(jù)成功提交之后就被寫入內(nèi)存表中。做寫操作（Write Op）時(shí)，首先查詢Chubby中保存的訪問控制列表確定用戶具有相應(yīng)的寫權(quán)限，通過認(rèn)證之后寫入的數(shù)據(jù)首先被保存在提交日志（Commit Log）中。這種技術(shù)在數(shù)據(jù)庫中不是很常用，但Google還是做出了這種選擇，實(shí)際運(yùn)行的效果也證明Google的選擇雖然大膽卻是正確的。3．子表數(shù)據(jù)存儲(chǔ)及讀寫操作在數(shù)據(jù)的存儲(chǔ)方面Bigtable做出了一個(gè)非常重要的選擇，那就是將數(shù)據(jù)存儲(chǔ)劃分成兩塊。其中三個(gè)用來確定信息是過時(shí)的，另外三個(gè)獲取新的地址。一旦出現(xiàn)緩存為空或緩存信息過時(shí)的情況，客戶端就需要按照?qǐng)D217所示方式進(jìn)行網(wǎng)絡(luò)的來回通信（Network Roundtrips）進(jìn)行尋址，在緩存為空的情況下需要三個(gè)網(wǎng)絡(luò)來回通信。為了減少訪問開銷，提高客戶訪問效率，Bigtable使用了緩存（Cache）和預(yù)?。≒refetch）技術(shù)，這兩種技術(shù)手段在體系結(jié)構(gòu)設(shè)計(jì)中是很常用的。這樣在查詢時(shí)，首先從Chubby中提取這個(gè)根子表的地址，進(jìn)而讀取圖217 子表地址結(jié)構(gòu)所需的元數(shù)據(jù)子表的位置，最后就可以從元數(shù)據(jù)子表中找到待查詢的子表。所有的子表地址都被記錄在元數(shù)據(jù)表中，元數(shù)據(jù)表也是由一個(gè)個(gè)的元數(shù)據(jù)子表（Metadata tablet）組成的。在Bigtable系統(tǒng)的內(nèi)部采用的是一種類似B+樹的三層查詢體系。每個(gè)子表服務(wù)器上保存的子表數(shù)量可以從幾十到上千不等，通常情況下是100個(gè)左右。Bigtable規(guī)定將日志的內(nèi)容按照鍵值進(jìn)行排序，這樣不同的子表服務(wù)器都可以連續(xù)讀取日志文件了。這樣會(huì)節(jié)省大量的空間，但在恢復(fù)時(shí)卻有一定的難度，因?yàn)椴煌淖颖砜赡軙?huì)被分配到不同的子表服務(wù)器上，一般情況下每個(gè)子表服務(wù)器都需要讀取整個(gè)共享日志來獲取其對(duì)應(yīng)的子表日志。有一點(diǎn)需要注意，那就是不同子表的SSTable可以共享，也就是說某些SSTable會(huì)參與多個(gè)子表的構(gòu)成，而由子表構(gòu)成的表則不存在子表重疊的現(xiàn)象。從概念上來講子表是表中一系列行的集合，它在系統(tǒng)中的實(shí)際組成如圖216所示。在SSTable的結(jié)尾有一個(gè)索引（Index），這個(gè)索引保存了SSTable中塊的位置信息，在SSTable打開時(shí)這個(gè)索引會(huì)被加載進(jìn)內(nèi)存，這樣用戶在查找某個(gè)塊時(shí)首先在內(nèi)存中查找塊的位置信息，然后在硬盤上直接找到這個(gè)塊，這種查找方法速度非常快。所有的SSTable文件都是存儲(chǔ)在GFS上的，用戶可以通過鍵來查詢相應(yīng)的值，圖215是SSTable格式的基本示意圖。在講解其他問題之前我們首先介紹一下SSTable的概念以及子表的基本結(jié)構(gòu)。子表服務(wù)器上的操作主要涉及子表的定位、分配以及子表數(shù)據(jù)的最終存儲(chǔ)問題。在成功完成以上四個(gè)步驟后主服務(wù)器就可以正常運(yùn)行了。如果元數(shù)據(jù)表未分配，則首先需要將根子表（Root Tablet）加入未分配的子表中。3）與所有的活躍子表服務(wù)器取得聯(lián)系以便了解所有子表的分配情況。1）從Chubby中獲取一個(gè)獨(dú)占鎖，確保同一時(shí)間只有一個(gè)主服務(wù)器?；谙到y(tǒng)出現(xiàn)故障是一種常態(tài)的設(shè)計(jì)理念（Google幾乎所有的產(chǎn)品都是基于這個(gè)設(shè)計(jì)理念），每個(gè)主服務(wù)器被設(shè)定了一個(gè)會(huì)話時(shí)間的限制。這種情況下主服務(wù)器會(huì)中止這個(gè)子表服務(wù)器并將其上的子表全部移至其他子表服務(wù)器。對(duì)此主服務(wù)器首先自己嘗試獲取這個(gè)獨(dú)占鎖，如果失敗說明Chubby服務(wù)出現(xiàn)問題，需等待Chubby服務(wù)的恢復(fù)。對(duì)于每個(gè)具體的子表服務(wù)器，主服務(wù)器會(huì)定期向其詢問獨(dú)占鎖的狀態(tài)。通過這種方式所有的子表服務(wù)器基本信息被保存在Chubby中一個(gè)稱為服務(wù)器目錄（Server Directory）的特殊目錄之中。由于系統(tǒng)設(shè)計(jì)之初就要求能達(dá)到良好的擴(kuò)展性，所以主服務(wù)器必須對(duì)子表服務(wù)器的狀態(tài)進(jìn)行監(jiān)控，以便及時(shí)檢測(cè)到服務(wù)器的加入或撤銷。創(chuàng)建新表、表合并以及較大子表的分裂都會(huì)產(chǎn)生一個(gè)或多個(gè)新子表。 主服務(wù)器主服務(wù)的主要作用如圖214所示。主服務(wù)主要進(jìn)行一些元數(shù)據(jù)的操作以及子表服務(wù)器之間的負(fù)載調(diào)度問題，實(shí)際的數(shù)據(jù)是存儲(chǔ)在子表服務(wù)器上的。從圖213中可以看出，客戶需要訪問Bigtable服務(wù)時(shí)首先要利用其庫函數(shù)執(zhí)行Open()操作來打開一個(gè)鎖（實(shí)際上就是獲取了文件目錄），鎖打開以后客戶端就可以和子表服務(wù)器進(jìn)行通信了。圖213 Bigtable基本架構(gòu)另外在Bigtable的實(shí)際執(zhí)行過程中，Google的MapReduce和Sawzall也被使用來改善其性能，不過需要注意的是這兩個(gè)組件并不是實(shí)現(xiàn)Bigtable所必需的。2）獲取子表的位置信息。在Bigtable中Chubby主要有以下幾個(gè)作用[10]。在前面已經(jīng)講過，GFS[9]是Google的分布式文件系統(tǒng)，在Bigtable中GFS主要用來存儲(chǔ)子表數(shù)據(jù)以及一些日志文件。 系統(tǒng)架構(gòu)Bigtable是在Google的另外三個(gè)云計(jì)算組件基礎(chǔ)之上構(gòu)建的，其基本架構(gòu)如圖213所示[11]。另一種就是保留限定時(shí)間內(nèi)的所有不同版本，比如可以保存最近10天的所有不同版本數(shù)據(jù)。Bigtable中的時(shí)間戳是64位整型數(shù)，具體的賦值方式可以采取系統(tǒng)默認(rèn)的方式，也可以用戶自行定義。3．時(shí)間戳Google的很多服務(wù)比如網(wǎng)頁檢索和用戶的個(gè)性化設(shè)置等都需要保存不同時(shí)間的數(shù)據(jù)，這些不同的數(shù)據(jù)版本必須通過時(shí)間戳來區(qū)分。通過這種方式組織的數(shù)據(jù)結(jié)構(gòu)清晰明了，含義也很清楚。引入了列族的概念之后，列關(guān)鍵字就采用下述的語法規(guī)則來定義：族名：限定詞（family：qualifier）族名必須有意義，限定詞則可以任意選定。有關(guān)子表的內(nèi)容會(huì)在稍后詳細(xì)講解。單個(gè)的大表由于規(guī)模問題不利于數(shù)據(jù)的處理，因此Bigtable將一個(gè)表分成了很多子表（Tablet），每個(gè)子表包含多個(gè)行。1）同一地址域的網(wǎng)頁會(huì)被存儲(chǔ)在表中的連續(xù)位置，有利于用戶查找和分析。不直接存儲(chǔ)網(wǎng)頁地址而將其倒排是Bigtable的一個(gè)巧妙設(shè)計(jì)。表中數(shù)據(jù)都是根據(jù)行關(guān)鍵字進(jìn)行排序的，排序使用的是詞典序。圖212 Bigtable數(shù)據(jù)模型1．行Bigtable的行關(guān)鍵字可以是任意的字符串，但是大小不能夠超過64KB。Bigtable對(duì)存儲(chǔ)在其中的數(shù)據(jù)不做任何解析，一律看做字符串，具體數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)需要用戶自行處理。下面就開始詳細(xì)講解Bigtable。在目標(biāo)確定之后，Google開發(fā)者就在現(xiàn)有的數(shù)據(jù)庫技術(shù)中進(jìn)行了大規(guī)模的篩選，希望各種技術(shù)之間能夠揚(yáng)長(zhǎng)避短，巧妙地結(jié)合起來。4）簡(jiǎn)單性。對(duì)于客戶來說，有時(shí)候即使短暫的服務(wù)中斷也是不能忍受的。根據(jù)需要隨時(shí)可以加入或撤銷服務(wù)器。Bigtable是為了滿足一系列Google產(chǎn)品而并非特定產(chǎn)品的存儲(chǔ)要求。在仔細(xì)考察了Google的日常需求后，Bigtable開發(fā)團(tuán)隊(duì)確定了Bigtable設(shè)計(jì)所需達(dá)到的如下幾個(gè)基本目標(biāo)。一方面現(xiàn)有商用數(shù)據(jù)庫的設(shè)計(jì)著眼點(diǎn)在于其通用性，面對(duì)Google的苛刻服務(wù)要求根本無法滿足，而且在數(shù)量龐大的服務(wù)器上根本無法成功部署普通的商用數(shù)據(jù)庫。Google運(yùn)行著目前世界上最繁忙的系統(tǒng)，它每時(shí)每刻處理的客戶服務(wù)請(qǐng)求數(shù)量是普通的系統(tǒng)根本無法承受的。包括URL、網(wǎng)頁內(nèi)容、用戶的個(gè)性化設(shè)置在內(nèi)的數(shù)據(jù)都是Google需要經(jīng)常處理的。1）需要存儲(chǔ)的數(shù)據(jù)種類繁多。通過本節(jié)的學(xué)習(xí)，讀者將會(huì)對(duì)Bigtable的數(shù)據(jù)模型、系統(tǒng)架構(gòu)、實(shí)現(xiàn)以及它使用的一些數(shù)據(jù)庫技術(shù)有一個(gè)全面的認(rèn)識(shí)。Google的工程師通過研究以及大量的實(shí)踐，完美實(shí)現(xiàn)了相關(guān)技術(shù)的選擇及融合。Google的很多數(shù)據(jù)，包括Web索引、衛(wèi)星圖像數(shù)據(jù)等在內(nèi)的海量結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，都是存儲(chǔ)在Bigtable中的。因此，如果需要的話，將代理和分區(qū)技術(shù)結(jié)合起來使用才可以明顯提高系統(tǒng)同時(shí)處理的服務(wù)請(qǐng)求量。除了少量的跨分區(qū)通信外，大部分的分區(qū)都可以獨(dú)自地處理服務(wù)請(qǐng)求。不過根據(jù)Google自己的數(shù)據(jù)統(tǒng)計(jì)表明，在所有的請(qǐng)求中，寫請(qǐng)求僅占極少的一部分，幾乎可以忽略不計(jì)。除此之外，Google的工程師們還考慮使用代理（Proxy）和分區(qū)（Partition）技術(shù)，雖然目前這兩種技術(shù)并沒有實(shí)際使用，但是在設(shè)計(jì)的時(shí)候還是被包含進(jìn)系統(tǒng)，不排除將來使用的可能。比如提高主服務(wù)器默認(rèn)的租約期、使用協(xié)議轉(zhuǎn)換服務(wù)將Chubby協(xié)議轉(zhuǎn)換成較簡(jiǎn)單的協(xié)議。其他的操作和寫操作類似。圖211 Chubby的ACL機(jī)制用戶chinacloud請(qǐng)求向文件CLOUD中寫入內(nèi)容。ACL同樣被保存在文件中，它是節(jié)點(diǎn)元數(shù)據(jù)的一部分，用戶在進(jìn)行相關(guān)操作時(shí)首先需要通過ACL來獲取相應(yīng)的授權(quán)。系統(tǒng)中有三種ACL名[13]，分別是寫ACL名（Write ACL Name）、讀ACL名（Read ACL Name）和變更ACL名（Change ACL Name）。因此，可以看出Paxos算法在分布式一致性問題中的作用是巨大的。讀操作很簡(jiǎn)單，客戶直接從主服務(wù)器上讀取所需數(shù)據(jù)即可，但是寫操作就涉及數(shù)據(jù)一致性的問題了。在實(shí)際的執(zhí)行過程中，Chubby使用Paxos算法來解決這個(gè)問題。這個(gè)過程的執(zhí)行效率非常高，僅僅需要發(fā)送一次無效標(biāo)志即可，因?yàn)橹鞣?wù)器對(duì)于沒有返回確認(rèn)的節(jié)點(diǎn)就直接認(rèn)為其是未緩存的。在客戶端保存一個(gè)和單元上數(shù)據(jù)一致的本地緩存，這樣需要時(shí)客戶可以直接從緩存中取出數(shù)據(jù)而不用再和主服務(wù)器通信。使用寬限期的好處正是如此。9）一定時(shí)間段后（1分鐘），刪除沒有被打開過的臨時(shí)文件夾。7）開始允許執(zhí)行所有的操作。5）向每個(gè)會(huì)話發(fā)送一個(gè)故障事件，促使所有的客戶端清空緩存。3）構(gòu)建處理會(huì)話和鎖所需的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。1）產(chǎn)生一個(gè)新的紀(jì)元號(hào)以便今后客戶端通信時(shí)使用，這能保證當(dāng)前的主服務(wù)器不必處理針對(duì)舊的主服務(wù)器的請(qǐng)求。2．主服