文章目錄
一、誕生背景
BigTable設計的動機與目標
- 動機
需要存儲的數據種類繁多、類型多樣，例如URL.圖片、文字、視頻、html文件、用戶設置數據等；
需要處理海量的服務請求；
商用數據庫無法滿足Google的需求，底層系統技術的掌控便於系統維護和升級； - 目標
廣泛的適用性:滿足Google的系列產品的需求；
很強的可擴展性:橫向擴展和縱向擴展；
高可用性:確保系統24X7可用；
簡單:底層系統簡單減少出錯概率，爲上層應用開發提供便利；
二、 BigTable的數據模型
- 分佈式多維映射表結構
- 表中數據通過行關鍵字(Rowkey) 、列關鍵字(Columnkey)以及時間戳進行索引，所有數據以字符串形式存儲，由用戶解析數據
- 存儲邏輯表示爲(row:string,column:string. item:int64) -> string
![在這裏插入圖片描述]()
例:網頁www.cnn.com的數據片段
行名稱是倒排的URL；
便於同一地址城的網頁被存儲在表中連續的位置；
便於數據壓縮，大幅提高壓縮率；
contents列族包含了網頁內容；
anchor列族包含了任何引用這個頁面的anchor文本；
CNN的主頁被Sports Illustrated和MY-look主頁同時引用，因此，行包含了名稱爲”anchor:cnnsi.com"和”anchor:my.look.ca" 的列。
每個anchor單元格都只一個版本，contents列有三個版本，分別對應於時間戳t3,t5和t6。
三、BigTable的數據模型-Rows
- BigTable的row key是任意的字符串，大小不超過64KB
- 對於每行數據的讀寫操作都是原子的(atomic) ，不管這個行中所包含的列族數量是多少。
- BigTable中的數據按照rowkey的字典順序排序。
- .單個大規模的大表不利於數據的處理與分析，BigTable將一個表劃分成多個子表(Tablet) ，是負載均衡和數據分發的基本單位。
四、BigTable的數據模型-Column Families
- BigTable將column key組織成列族(column family)，是基本的訪問控制單元，每個列族的數據屬於同一個類型，同列族數據壓縮存
- 在把數據存放到這個列家族的某個column key下之前，必須首先創建這個列族，創建後，可以使用column key
- 表當中所包含的列族 的數量儘可能少(至多幾百個列族)，在操作過程 當中，列族很少發生變化;一個表可以包含無限數量的列。
- column key命名語法: family:qualifier
例: anchor:cnnsi.com - 訪問控制以及磁盤、內存審計在column family級別完成
五、BigTable的數據模型-timestamps
- 在BigTable中，每個單元都包含相同數據的多個版本，這些版本採用時間戳進行索引。
- 時間戳是64位整數，代表真實時間，以微秒來計算。客戶應用也可以直接分配時間戳。
- 需要避免衝突的應用必鬚生成唯一的時間戳。
- 一個單元的不同版本根據時間戳降序順序存儲，最新的版本可以被最先讀取。
- 爲了減輕版本數據的管理負擔，BigTable支持用戶設定保存單元中數據的最近n個版本，或者只保存足夠新版本(比如只保存最近7天內的數據版本)
六、Bigtable體系結構
BigTable基於Google的的三個雲計算組件
1）GFS: Google File System
➢基於廉價的商用計算機的大型分佈式文件系統
2）Chubby
➢基於松耦合分佈式系統的鎖服務
➢存儲元數據的存儲系統
➢名字服務
3）WorkQueue
➢分佈式任務調度器，用於處理分佈式系統隊列分組與調度
➢未公開
Chuby會在下一張詳細介紹。