癸巳即將過去，總得點禮物吧，思來想去，覺得寫寫GOOGLE分佈式數據庫技術發展情況，以此作爲禮物獻給自己，聊以自慰，由於時間有限，加之對於GOOGLE的分佈式數據庫理解也只能盲人摸象，難免有錯誤之處，敬請諒解。
GOOGLE的分佈式數據庫系統從BIGTABLE的正式推出後，先後對外發布了Bigtable、Dremel、 Spanner等不同的分佈式數據庫產品，有的是引入新的設計實現，有的是針對原有的技術進行改進和優化，用於滿足不同的GOOGLE的應用場景，支持日益增加的數據量管理要求。
GOOGLE分佈式數據庫技術，從個人理解看，可以分爲三個階段，第一階段以Bigtable產品爲代表，實現了數據的分佈式存儲、行數據的事務性管理和較好的擴展性，從存儲WEB頁面而生，創造性提出了KEY-VALUE這種MAP數據結構，並廣泛應用到GOOGLE的各種應用中，與GOOGLE的MapReduce GFS技術搭配，構成了GOOGLE分佈式雲計算的三架馬車，對應開源社區推出HBASE產品，也在近年得到了廣泛應用。
第二個階段以Dremel產品爲代表，Dremel產品採用了與Bigtable不同的數據結構，立足實時對於海量數據進行分析，據說在秒級可以完成PB級別的數據分析和處理，可以做是分佈式數據庫實時處理的傑作，其實時處理能力達到令人驚豔的速度。
第三階段以Spanner數據庫技術爲代表，Spanner數據庫在可以做到多數據表事務一致性管理，利用原子時鐘（TrueTime）和Paxos協議解決了分佈式數據庫多表事務一致性管理的難題，打破的CAP不可三者兼得的理論神話，使得分佈式數據庫技術得到了革命性的進步。
嚴格來講Dremel與Bigtable和Spanner解決的問題有所不同，Dremel側重於對應海量數據的實時處理，而Bigtable和Spanner更側重於傳統的關係型數據庫支持功能對齊和替換，並不是簡單產品替換關係。從GOOGLE的分佈式數據庫技術的發展歷程看，這些技術得以成功推出，有創造性的新銳視角和解決方案，更有其堅持在廉價PC服務器上面構築海量數據處理系統的理想和情懷，更有起高超的技術實力和團隊合作，這些因素的結合，使得技術難關被不斷的突破，分佈式數據庫產品得以大成，這些產品的確值得技術人員去深入學習和體會。
爲了更好的對比和分析GOOGLE的分佈式數據庫技術，本文從Bigtable、Dremel、Spanner數據模型、系統架構、數據查詢原理、應用場景進行深入分析，最後對於其特點進行對比，從而使得讀者對應GOOGLE的分佈式數據庫技術有一個初步的認識。
2 BIGTABLE開山壁祖
2.1 Bigtable的數據模型
2.1.1 Bigtable的Key-Value數據結構
Bigtable採用Key-Value數據結構，Key由行關鍵字、列關鍵字、時間戳組合而成，Value爲對應數據內容，行關鍵字和列關鍵字都是字符串數據類型，時間戳是一個64位的長整數，精確到毫秒的時間戳，這三個屬性在一個數據庫中全局唯一，由Key和Value構成的KV數據結構稱爲一個數據項，考慮到分佈式數據庫的多複本的特性，數據項會按照時間戳進行排序，並對於過期的數據項進行過期回收，其數據結構如圖2-1所示。
圖2-1 Bigtable KV結構示意圖
2.1.2 Bigtable的數據模型層次
Bigtable數據模型由下而上，主要部件可以初分爲四個層面，最底層爲SSTABLE，存放在GFS分佈式文件系統中，爲數據存儲MAP結構體，第二層TABLET結構體，一個表可以由一個或者多個Tablet構成，由一系列的SSTABLE構成，第三層TABLET服務器，管理一組TABLET數據體，最上層Bigtable數據庫，由多個TABLET服務器和一個Master服務器、客戶端訪問連接支持軟件構成，最終形成了一個分佈式數據庫，對外提供數據庫服務，層次關係如圖2-2所示。
圖2-2 Bigtable各級數據模型視圖
數據項基於一種叫做SSTABLE的數據格式，SSTABLE是一種持久化、排序的、不可更改的MAP數據結構，每一個SSTABLE由一系列數據塊構成，在每一個SSTABLE的最後存儲着塊索引，SSTABLE使用這些索引來定位數據塊，在每一個SSTABLE被打開時，塊索引會自動加載到內存中。SSTABLE提供了二種數據訪問方式，第一種方式，使用二分法查找內存中的塊索引，根據對應的塊索引把對應的數據塊讀取到內存中，此種方式只會發起一次磁盤尋址，第二種方式是把整個SSTABLE都整體加載到內存中。SSTABLE基於GOOGLE GFS全局文件系統基礎上，實現對應文件系統層面的負載均衡和IO能力分擔，
從特點看，BIGTABLE不直接支持對應數據的修改操作，通過時間戳方式來間接支持數據修改。數據讀取方式，提供了二種不同的機制，二分法的塊索引定位加載，類似於ORACLE提供的索引訪問方式；SSTABLE的全部加載，類似於ORACLE提供的全表掃描機制，從技術角度看，不管分佈式數據庫技術本身如何發展，對小粒度數據精確加載和整體數據加載的場景，從這點看,所有的數據庫存儲結構應該都是殊途同歸。
一個TABLET由TABLET Log存儲TABLET的提交數據的Redo 記錄數據，MEMTABLE是內存緩存，存儲最近訪問的記錄數據，數據持久化到一組SSTABLE文件中。
最上層Bigtable數據庫服務層，對外提供Bigtable的數據庫服務功能，爲Bigtable的最頂層結構。
2.2 Bigtable的系統架構
Bigtable由客戶端連接庫、Master服務器、TABLET服務器組構成，客戶端鏈接庫提供數據庫客戶端訪問功能，提供服務端訪問，比如對於數據尋址的緩存信息； Master服務器負責TABLET服務器組的管理，根據負載情況，可以動態的增加和刪除TABLET服務器，維護TABLET服務器組；TABLET服務器管理該服務器上面的TABLET集合，完成TABLET數據讀取和寫入操作，當TABLET太大時，對TABLET進行拆分，在一個Bigtable中只能有一個Master服務器，通過Chubby保證Master服務器的唯一性；Chubby服務提供了TABLET根信息服務、系統Master管理和TABLET服務出錯的善後處理任務，保存Bigtable數據庫Schema信息。Bigtable整個系統架構如圖2-3所示。
圖2-3 Bigtable系統架構圖
2.3 Bigtable的數據查詢
2.3.1 Bigtable的數據定位
Bigtable數據查詢，首先是對於數據所在tablet進行定位，Bigtable的位置定位，分爲三個步驟。
第一步，客戶端程序在緩存中查找tablet位置是否在緩存中存在，如果在緩存中存在就直接讀取，如果不存在，通過Chubby服務器查詢tablet的根節點，取到Bigtable根節點tablet信息；
第二步，根據Bigtable根節點的tablet信息，找到數據對應METADATA的數據表，該數據表中存儲着所有的用戶數據tablet的位置信息；
第三步，根據METADATA的數據表存儲的用戶數據tablet信息，找到數據對應tablet信息，根據該位置信息，讀取到tablet數據到客戶端。
2.3.2 Bigtable的數據讀取
Bigtable數據讀取時以Tablet爲單位，必須讀取到構成該Tablet所有涉及到SSTABLE，發起讀取操作時，首先要對操作完整性和權限做檢查，檢查通過後，首先在Tablet服務器所在的緩存裏面查找，Bigtable提供二級緩存緩存，一種是以Key-Value形式的一級數據緩存，如果在這種級別中的緩存中無法找到，訪問二級數據緩存，二級數據是SSTABLE的BLOCK數據緩存，對於熱點局部性數據來講，這種BLOCK環境命中率很高，對於系統性能改善更加有效。
在數據緩存中如果沒有找到對應的讀取數據，啓動數據定位的三個步驟，完成對於TABLET的位置信息讀取，TABLET信息讀取轉換爲對應SSTABLE數據，根據SSTABLE數據是否進行了壓縮，對於涉及到該TABLET的SSTABLE進行解壓操作，完成讀取後返回到客戶端。
2.3.3 Bigtable的數據寫入
Bigtable數據寫入時，首先是堅持該操作數據格式是否正確，並判斷該操作發起者是否有該操作的權限，權限判斷是通過存儲在Chubby服務器上面的權限控制表來判斷。判斷操作發起者具備該操作的權限後，會發起具體寫入數據動作，該動作是一個事務操作，操作必須保證對於Tablet中數據寫入成功，否則不會寫入TABLET，如果寫入成功後，會把提交該操作修改到Tablet對應的Redo日誌中，同時該寫入內容會插入到MEMTABLE中。
2.4 應用場景
2.4.1 應用場景
Bigtable從數據存儲特點看，屬於行式數據庫存儲模型，雖然Bigtable具備把列分配到不同的SSTABLE，形成不同的列簇的情況。由於Bigtable採用按照行存儲模型，因此對於數據表中的一行可以實現事務性操作，實現數據單表上的事務控制，雖然Bigtable提供了批量數據的訪問接口，但是還不支持跨行的事務操作。
而Bigtable採用的KV結構，可以按照Key中的行關鍵字和列關鍵字，對於海量數據進行列維度和行維度的切片管理，分別到同步到TABLET服務器上面。在一個BIGTABLE系統中，TABLET服務器的數量可以根據負載要求，做動態的調整，對於TABLET服務器數量無上限，這樣就可以支持對於數據庫負載的水平擴展，根據GOOGLE提供的數據，單TABLET服務器在BLOCK爲64KB時，KEY-VALUE中的VALUE爲1K的長度是，可以支持1200次請求，一個TABLET服務器可以處理75M數據讀取，當TABLET服務器數量增加後，其讀取數據的能力可以提升，當並不會嚴格的遵循線性關係，可以從GOOGLE在BIGTABLE中提供的測試數據看出，TABLET服務器增加和整體系統吞吐能力提升的關係，參見圖2-4。
可以看出對於TABLET的掃描和在TABLET中內存中的隨機讀，提升效率最爲明顯，這是由於在TABLET服務器增加過程中，此類操作都是在內存中進行，因此服務器越多，支持吞吐量就會更大。順序讀、隨機寫、順序寫提升比率低於前兩種操作，順序讀由於讀取SSTABLE到TABLET服務器時，一個BLOCK被讀取時，SSTABLE中相鄰接的BOLCK會被加載到BLOCK緩存中，後續會在緩存中被讀取到該BLOCK，不在需要在從SSTABLE中讀取。隨機寫和序列寫在採用了批量提交的方式，通過數據流的方式來進行處理，此種操作方式隨TABLET的增加，提升效果還是比較明顯。誰TABLET服務器提升效果最低的爲隨機讀，原因是隨機讀取時，爲了訪問KEY-VALUE值中，VALUE爲1K的數據時，會同步把整個SSTABLE中一個BLOCK都讀取出來，當隨機讀取請求數量增加時，整個網絡帶寬會急劇上升，導致每個TABLET服務器吞吐能力下降，整個系統能夠處理的隨機請求數量變少。
圖2-4 tablet 服務器與系統IO吞吐量關係圖
2.4.2 應用場景下技術難題
從Bigtable應用場景看，BIGTABLE系統設計需要解決下面的核心技術
技術難題一系統魯棒性
對於分佈式環境，對於網絡受損、內存數據損壞、時間誤差，機器硬件損壞這這種常見的問題出現後，系統的容錯處理能力，要求Bigtable系統具有較強的魯棒性和容錯性。
技術難題二 系統容錯和負載與效率的平衡
TABLET副本數量增加會增加系統容錯能力，但是會增加系統管理代價和同步成本，效率就會相應的下降；系統負載和效率增加，有限制了數據副本數量、副本數量下降會導致系統容錯性減低，GOOGLE具體處理算法，這些在GOOGLE對外公佈的論文中沒有進行詳細的描述，在開源產品HBASE遇到問題看，這些都是一些技術難點。
技術難題三 不同查詢特點的應對
由於系統不同查詢特點，數據特點，對於BIGTABLE中的各種關鍵配置參數的配置方式，比如SSTABLE中BLOCK大小的選擇、緩存算法設計細節。
上面的這些技術難題相信已經被GOOGLE很好的解決，不過這些解決經驗和具體技術細節GOOGLE並沒有進行公開。
2.4.3 BIGTABLE後續發展
Bigtable做爲GOOGLE公佈的第一代分佈式數據庫技術，結合下層的GFS文件系統，上結合MAP-REDUCE框架完成數據的分片計算，構成了GOOGLE的分佈式計算體系。而BIGTABLE目前只有在一個系統只支持一個Master服務器，同時對於多表事務性無法支持，這些都是Bigtable後續要解決的技術問題。對於不同特點數據庫查詢請求，不同特點存放數據，BIGTABLE的關鍵參數應該如何配置，是否有一種完美的配置參數，可以完全滿足各種不同特點的查詢場景，從目前來看，還不能做到的，還必須根據數據特點，對BIGTABLE的參數做相應定製，包括一些BIGTABLE要使用的GFS文件配置參數、網絡配置參數，這些都成爲使用Bigtable數據庫過程中一些較爲複雜問題，整個Bigtable數據庫使用技術門檻仍然比較高。
--未完，後續抓緊寫，爭取馬年前寫完。