【正文】 服務(wù)器對子表服務(wù)器的監(jiān)控是通過Chubby來完成的，子表服務(wù)器在初始化時都會從Chubby中得到一個獨占鎖。通過這種方式所有的子表服務(wù)器基本信息被保存在Chubby中一個稱為服務(wù)器目錄（Server Directory）的特殊目錄之中。主服務(wù)器通過檢測這個目錄就可以隨時獲取最新的子表服務(wù)器信息，包括目前活躍的子表服務(wù)器，以及每個子表服務(wù)器上現(xiàn)已分配的子表。對于每個具體的子表服務(wù)器，主服務(wù)器會定期向其詢問獨占鎖的狀態(tài)。如果子表服務(wù)器的鎖丟失或沒有回應(yīng)，則此時可能有兩種情況，要么是Chubby出現(xiàn)了問題（雖然這種概率很小，但的確存在，Google自己也做過相關(guān)測試），要么是子表服務(wù)器自身出現(xiàn)了問題。對此主服務(wù)器首先自己嘗試獲取這個獨占鎖，如果失敗說明Chubby服務(wù)出現(xiàn)問題，需等待Chubby服務(wù)的恢復(fù)。如果成功則說明Chubby服務(wù)良好而子表服務(wù)器本身出現(xiàn)了問題。這種情況下主服務(wù)器會中止這個子表服務(wù)器并將其上的子表全部移至其他子表服務(wù)器。當(dāng)在狀態(tài)監(jiān)測時發(fā)現(xiàn)某個子表服務(wù)器上負載過重時，主服務(wù)器會自動對其進行負載均衡操作。基于系統(tǒng)出現(xiàn)故障是一種常態(tài)的設(shè)計理念（Google幾乎所有的產(chǎn)品都是基于這個設(shè)計理念），每個主服務(wù)器被設(shè)定了一個會話時間的限制。當(dāng)某個主服務(wù)器到時退出后，管理系統(tǒng)就會指定一個新的主服務(wù)器，這個主服務(wù)器的啟動需要經(jīng)歷以下四個步驟[8]。1）從Chubby中獲取一個獨占鎖，確保同一時間只有一個主服務(wù)器。2）掃描服務(wù)器目錄，發(fā)現(xiàn)目前活躍的子表服務(wù)器。3）與所有的活躍子表服務(wù)器取得聯(lián)系以便了解所有子表的分配情況。4）通過掃描元數(shù)據(jù)表（Metadata Table），發(fā)現(xiàn)未分配的子表并將其分配到合適的子表服務(wù)器。如果元數(shù)據(jù)表未分配，則首先需要將根子表（Root Tablet）加入未分配的子表中。由于根子表保存了其他所有元數(shù)據(jù)子表的信息，確保了掃描能夠發(fā)現(xiàn)所有未分配的 子表。在成功完成以上四個步驟后主服務(wù)器就可以正常運行了。 子表服務(wù)器Bigtable中實際的數(shù)據(jù)都是以子表的形式保存在子表服務(wù)器上的，客戶一般也只和子表服務(wù)器進行通信，所以子表以及子表服務(wù)器是我們重點講解的概念。子表服務(wù)器上的操作主要涉及子表的定位、分配以及子表數(shù)據(jù)的最終存儲問題。其中子表分配在前面已經(jīng)有了詳細介紹，這里略過不講。在講解其他問題之前我們首先介紹一下SSTable的概念以及子表的基本結(jié)構(gòu)。1．SSTable及子表基本結(jié)構(gòu)SSTable是Google為Bigtable設(shè)計的內(nèi)部數(shù)據(jù)存儲格式。所有的SSTable文件都是存儲在GFS上的，用戶可以通過鍵來查詢相應(yīng)的值，圖215是SSTable格式的基本示意圖。圖215 SSTable結(jié)構(gòu)SSTable中的數(shù)據(jù)被劃分成一個個的塊（Block），每個塊的大小是可以設(shè)置的，一般來說設(shè)置為64KB。在SSTable的結(jié)尾有一個索引（Index），這個索引保存了SSTable中塊的位置信息，在SSTable打開時這個索引會被加載進內(nèi)存，這樣用戶在查找某個塊時首先在內(nèi)存中查找塊的位置信息，然后在硬盤上直接找到這個塊，這種查找方法速度非?？?。由于每個SSTable一般都不是很大，用戶還可以選擇將其整體加載進內(nèi)存，這樣查找起來會更快。從概念上來講子表是表中一系列行的集合，它在系統(tǒng)中的實際組成如圖216所示。圖216 子表實際組成每個子表都是由多個SSTable以及日志（Log）文件構(gòu)成的。有一點需要注意，那就是不同子表的SSTable可以共享，也就是說某些SSTable會參與多個子表的構(gòu)成，而由子表構(gòu)成的表則不存在子表重疊的現(xiàn)象。Bigtable中的日志文件是一種共享日志，也就是說系統(tǒng)并不是對子表服務(wù)器上每個子表都單獨地建立一個日志文件，每個子表服務(wù)器上僅保存一個日志文件，某個子表日志只是這個共享日志的一個片段。這樣會節(jié)省大量的空間，但在恢復(fù)時卻有一定的難度，因為不同的子表可能會被分配到不同的子表服務(wù)器上，一般情況下每個子表服務(wù)器都需要讀取整個共享日志來獲取其對應(yīng)的子表日志。Google為了避免這種情況出現(xiàn)，對日志做了一些改進。Bigtable規(guī)定將日志的內(nèi)容按照鍵值進行排序，這樣不同的子表服務(wù)器都可以連續(xù)讀取日志文件了。一般來說每個子表的大小在100MB到200MB之間。每個子表服務(wù)器上保存的子表數(shù)量可以從幾十到上千不等，通常情況下是100個左右。2．子表地址子表地址的查詢是經(jīng)常碰到的操作。在Bigtable系統(tǒng)的內(nèi)部采用的是一種類似B+樹的三層查詢體系。子表地址結(jié)構(gòu)如圖217所示[8]。所有的子表地址都被記錄在元數(shù)據(jù)表中，元數(shù)據(jù)表也是由一個個的元數(shù)據(jù)子表（Metadata tablet）組成的。根子表是元數(shù)據(jù)表中一個比較特殊的子表，它既是元數(shù)據(jù)表的第一條記錄，也包含了其他元數(shù)據(jù)子表的地址，同時Chubby中的一個文件也存儲了這個根子表的信息。這樣在查詢時，首先從Chubby中提取這個根子表的地址，進而讀取圖217 子表地址結(jié)構(gòu)所需的元數(shù)據(jù)子表的位置，最后就可以從元數(shù)據(jù)子表中找到待查詢的子表。除了這些子表的元數(shù)據(jù)之外，元數(shù)據(jù)表中還保存了其他一些有利于調(diào)試和分析的信息，比如事件日志等。為了減少訪問開銷，提高客戶訪問效率，Bigtable使用了緩存（Cache）和預(yù)?。≒refetch）技術(shù)，這兩種技術(shù)手段在體系結(jié)構(gòu)設(shè)計中是很常用的。子表的地址信息被緩存在客戶端，客戶在尋址時直接根據(jù)緩存信息進行查找。一旦出現(xiàn)緩存為空或緩存信息過時的情況，客戶端就需要按照圖217所示方式進行網(wǎng)絡(luò)的來回通信（Network Roundtrips）進行尋址，在緩存為空的情況下需要三個網(wǎng)絡(luò)來回通信。如果緩存的信息是過時的，則需要六個網(wǎng)絡(luò)來回通信。其中三個用來確定信息是過時的，另外三個獲取新的地址。預(yù)取則是在每次訪問元數(shù)據(jù)表時不僅僅讀取所需的子表元數(shù)據(jù)，而是讀取多個子表的元數(shù)據(jù)，這樣下次需要時就不用再次訪問元數(shù)據(jù)表。3．子表數(shù)據(jù)存儲及讀寫操作在數(shù)據(jù)的存儲方面Bigtable做出了一個非常重要的選擇，那就是將數(shù)據(jù)存儲劃分成兩塊。較新的數(shù)據(jù)存儲在內(nèi)存中一個稱為內(nèi)存表（Memtable）的有序緩沖里，較早的數(shù)據(jù)則以SSTable格式保存在GFS中。這種技術(shù)在數(shù)據(jù)庫中不是很常用，但Google還是做出了這種選擇，實際運行的效果也證明Google的選擇雖然大膽卻是正確的。從圖218[8]中可以看出讀和寫操作有很大的差異性。做寫操作（Write Op）時，首先查詢Chubby中保存的訪問控制列表確定用戶具有相應(yīng)的寫權(quán)限，通過認證之后寫入的數(shù)據(jù)首先被保存在提交日志（Commit Log）中。提交日志中以重做記錄（Redo Record）的形式保存著最近的一系列數(shù)據(jù)更改，這些重做記錄在子表進行恢復(fù)時可以向系統(tǒng)提供已完成的更改信息。數(shù)據(jù)成功提交之后就被寫入內(nèi)存表中。在做讀操作（Read Op）時，首先還是要通過認證，之后讀操作就要結(jié)合內(nèi)存表和SSTable文件來進行，因為內(nèi)存表和SSTable中都保存了數(shù)據(jù)。在數(shù)據(jù)存儲中還有一個重要問題，就是數(shù)據(jù)壓縮的問題。內(nèi)存表的空間畢竟是很有限的，當(dāng)其容量達到一個閾值時，舊的內(nèi)存表就會被停止使用并壓縮成SSTable格式的文件。在Bigtable中有三種形式的數(shù)據(jù)壓縮，分別是次壓縮（Minor Compaction）、合并壓縮（Merging Compaction）和主壓縮（Major Compaction）。三者之間的關(guān)系如圖219所示。圖218 Bigtable數(shù)據(jù)存儲及讀寫操作圖219 三種形式壓縮之間的關(guān)系每一次舊的內(nèi)存表停止使用時都會進行一個次壓縮操作，這會產(chǎn)生一個SSTable。但如果系統(tǒng)中只有這種壓縮的話，SSTable的數(shù)量就會無限制地增加下去。由于讀操作要使用SSTable，數(shù)量過多的SSTable顯然會影響讀的速度。而在Bigtable中，讀操作實際上比寫操作更重要，因此Bigtable會定期地執(zhí)行一次合并壓縮的操作，將一些已有的SSTable和現(xiàn)有的內(nèi)存表一并進行一次壓縮。主壓縮其實是合并壓縮的一種，只不過它將所有的SSTable一次性壓縮成一個大的SSTable文件。主壓縮也是定期執(zhí)行的，執(zhí)行一次主壓縮之后可以保證將所有的被壓縮數(shù)據(jù)徹底刪除，如此一來，既回收了空間又能保證敏感數(shù)據(jù)的安全性（因為這些敏感數(shù)據(jù)被徹底刪除了）。 性能優(yōu)化上述各種操作已經(jīng)可以實現(xiàn)Bigtable的所有功能了，但是這些基本的功能很多時候并不是很符合用戶的使用習(xí)慣，或者執(zhí)行的效率較低。有些功能Bigtable自身已經(jīng)進行了優(yōu)化，包括使用緩存、共享式的提交日志以及利用系統(tǒng)的不變性。這些手段在前面已經(jīng)有了簡單的介紹，這里不再講解。除此之外，Bigtable還允許用戶個人在基本操作基礎(chǔ)上對系統(tǒng)進行一些優(yōu)化。這一部分主要向讀者介紹用戶可以使用的幾個重要優(yōu)化措施。實際上這些技術(shù)手段都是一些已有的數(shù)據(jù)庫方法，只不過Google將它具體地應(yīng)用于Bigtable之中罷了。1．局部性群組（Locality groups）Bigtable允許用戶將原本并不存儲在一起的數(shù)據(jù)以列族為單位，根據(jù)需要組織在一個單獨的SSTable中，以構(gòu)成一個局部性群組。這實際上就是數(shù)據(jù)庫中垂直分區(qū)技術(shù)的一個應(yīng)用。結(jié)合圖213的實例來看，在被Bigtable保存的網(wǎng)頁列關(guān)鍵字中，有的用戶可能只對網(wǎng)頁內(nèi)容感興趣，那么它可以通過設(shè)置局部性群組只看內(nèi)容這一列。有的則會對諸如網(wǎng)頁語言、網(wǎng)站排名等可以用于分析的信息比較感興趣，他也可以將這些列設(shè)置到一個群組中。局部性群組如圖220所示。圖220 局部性群組通過設(shè)置局部性群組用戶可以只看自己感興趣的內(nèi)容，對某個用戶來說的大量無用信息無需讀取。對于一些較小的且會被經(jīng)常讀取的局部性群組，用戶可以將其SSTable文件直接加載進內(nèi)存，這可以明顯地改善讀取效率。2．壓縮壓縮可以有效地節(jié)省空間，Bigtable中的壓縮被應(yīng)用于很多場合。首先壓縮可以被用在構(gòu)成局部性群組的SSTable中，可以選擇是否對個人的局部性群組的SSTable進行壓縮。Bigtable中這種壓縮是對每個局部性群組獨立進行的，雖然這樣會浪費一些空間，但是在需要讀時解壓速度非?？?。通常情況下，用戶可以采用兩步壓縮的方式[8]：第一步利用Bentley amp。 McIlroy方式（BMDiff）在大的掃描窗口將常見的長串進行壓縮；第二步采取Zippy技術(shù)進行快速壓縮，它在一個16KB大小的掃描窗口內(nèi)尋找重復(fù)數(shù)據(jù)，這個過程非?？臁嚎s技術(shù)還可以提高子表的恢復(fù)速度，當(dāng)某個子表服務(wù)器停止使用后，需要將上面所有的子表移至另一個子表服務(wù)器來恢復(fù)服務(wù)。在轉(zhuǎn)移之前要進行兩次壓縮，第一次壓縮減少了提交日志中的未壓縮狀態(tài)，從而減少了恢復(fù)時間。在文件正式轉(zhuǎn)移之前還要進行一次壓縮，這次壓縮主要是將第一次壓縮后遺留的未壓縮空間進行壓縮。完成這兩步之后壓縮的文件就會被轉(zhuǎn)移至另一個子表服務(wù)器。3．布隆過濾器（Bloom Filter）Bigtable向用戶提供了一種稱為布隆過濾器[12]的數(shù)學(xué)工具。布隆過濾器是巴頓布隆在1970年提出的，實際上它是一個很長的二進制向量和一系列隨機映射函數(shù)，在讀操作中確定子表的位置時非常有用。布隆過濾器的速度快，省空間。而且它有一個最大的好處是它絕不會將一個存在的子表判定為不存在。不過布隆過濾器也有一個缺點，那就是在某些情況下它會將不存在的子表判斷為存在。不過這種情況出現(xiàn)的概率非常小，跟它帶來的巨大好處相比這個缺點是可以忍受的。目前包括Google Analytics、Google Earth、個性化搜索、Orkut和RRS閱讀器在內(nèi)的幾十個項目都使用了Bigtable。這些應(yīng)用對Bigtable的要求以及使用的集群機器數(shù)量都是各不相同的，但是從實際運行來看，Bigtable完全可以滿足這些不同需求的應(yīng)用，而這一切都得益于其優(yōu)良的構(gòu)架以及恰當(dāng)?shù)募夹g(shù)選擇。與此同時Google還在不斷地對Bigtable進行一系列的改進，通過技術(shù)改良和新特性的加入提高系統(tǒng)運行效率及穩(wěn)定性。寧可累死在路上，也不能閑死在家里！寧可去碰壁，也不能面壁。是狼就要練好牙，是羊就要練好腿。什么是奮斗？奮斗就是每天很難，可一年一年卻越來越容易。不奮斗就是每天都很容易，可一年一年越來越難。能干的人，不在情緒上計較，只在做事上認真；無能的人！不在做事上認真，只在情緒上計較。拼一個春夏秋冬！贏一個無悔人生！早安！—————獻給所有努力的人.學(xué)習(xí)參考