Google BigTable到底解決什麼問題？

搞架構的人，Google的論文是必看的，但好像你們都不肯意去啃英文論文。故把本身的讀書筆記，加入本身的思考，分享給你們。

第三部分，Google BigTable。

BigTable，不少人對它耳熟能詳，但它究竟解決什麼問題呢？這是今天要聊的話題。

什麼是BigTable？

Google BigTable是一個分佈式，結構化數據的存儲系統，它用來存儲海量數據。該系統用來知足「大數據量、高吞吐量、快速響應」等不一樣應用場景下的存儲需求。
畫外音：本質上，BigTable是一個存儲系統。

有BigTable以前，Google面臨什麼問題？

Google並非一羣人坐在辦公室開會，想出來的系統，Google面臨着很實際的業務問題。
畫外音：
不少公司的基礎架構部，是坐在辦公室開會，想出來的東西，而後強推業務線使用；
脫離業務的技術，都是耍流氓。

典型場景一：網頁存儲

Google天天要抓取不少網頁：

• 新出現的網頁，新URL
• 舊網頁，舊URL

對一個已抓取的網頁，舊URL爲啥要反覆抓取？

由於，網頁會更新，例如新浪首頁：
sina.com.cn/index.html
URL雖然沒有變，但依然會抓取。
畫外音：我去，至關於，被抓取的URL集合，只會無限增大，趨近無窮，這裏面的技術難題，不知道你們感不感興趣？

這裏，對於存儲系統的需求，是要存儲：不一樣URL，不一樣時間Time，的內容Content。
畫外音：URL+」Content」+Time => Binary。

網頁的實際內容Binary，是Spider抓取出來的。

典型場景二：Google Analytics

Google Analytics要給站長展現其網站的流量PV，獨立用戶數UV，典型訪問路徑等，以幫助站長了解站點狀況，優化站點。

這裏，對於存儲系統的需求，是要存儲，不一樣URL，不一樣時間Time，的PV和UV。
畫外音：
URL+」PV」+Time => $count
URL+」UV」+Time => $count

PV和UV的值，是MapReduce離線任務計算出來的。

無論是「網頁存儲」仍是「站點統計」存儲，它們都有幾個共同的特色：

• 數據量極大，TB，PB級別
• 和時間維度相關
• 同一個主鍵，屬性與值有映射
  畫外音：
  主鍵是URL，屬性是「Content」，值是網頁Binary；
  主鍵是URL，屬性是「PV」和「UV」，值是計數count。

這是Google曾經遇到的難題，面對這些難題，典型的解決方案又有哪些呢？
畫外音：不是一上來就搞新方案，最早確定是想用現有的技術要如何解決。

最容易想到的主鍵，屬性，值的存儲系統是什麼？

沒錯，就是關係型數據庫：

如上圖所示，用戶表
User(uid PK, name, gender, age, sex)
就是一個典型的主鍵，屬性，值的存儲模型：

• 主鍵，不一樣用戶的uid
• 屬性，schema的列名
• 值，不一樣主鍵的各個列名，對應的值

使用excel來舉例是很直觀的，這是一個二維table。
畫外音：屎黃色的主鍵是一個維度，橙色的屬性是一個維度。

用二維table能不能解決Google網頁存儲的問題呢？

如上圖所示，若是沒有時間維度Time，彷佛是能夠的：
主鍵，使用URL
屬性，schema的列名，例如content，author等
值，不一樣URL的內容與做者等值

可是，一旦加入時間維度Time，二維table彷佛就不靈了。
畫外音：
增長一個time屬性是沒有用的；
增長一個time屬性，只能記錄同一個URL，某一個time的content，不能記錄多個time的多個content；
增長一個time屬性，聯合主鍵，URL就不是KEY了；

能不能用二維table存儲三維數據呢？

彷佛能夠經過trick的手段，在key上作文章，用key+time來拼接新key來實現。

如上圖所示，仍然是二維table，經過URL+Time來瓶裝key，也可以實現，存儲同一個URL，在不一樣Time，的不一樣content、author。

可是，這種trick方案存在的問題是：

• 無法實現URL查詢
  畫外音：key上沒法進行%like%查詢。
• 大量空洞，浪費存儲空間
  這並非一個好的方案。

何況，當數據量達到TB、PB級別時，傳統單機關係型數據庫，根本沒法知足Google的業務需求。

BigTable解決什麼問題？

傳統二維small table，沒法解決Google面臨的存儲問題，因而Google搞了一個big table來解決。

Google對這些業務模型進行分析，在二維table的基礎上擴充，抽象了一個新的「三維table」：

• 主鍵，使用URL
• 屬性，schema的列名，例如content，author等
• 時間，timestamp
• 值，不一樣URL的內容與做者等值
  

如上圖所示：

• 第一維：key（屎黃色）
• 第二維：屬性（橙色）
• 第三維：time（藍色）
  同一個key，不一樣屬性，不一樣時間，會存儲一個value。

不像以行爲單位進行存儲的傳統關係型數據庫，這個三維的大表格BigTable是一個稀疏列存儲系統。
畫外音：可以壓縮空間。

它的數據模型的本質是一個map：
key + column + time => value
的一個超級大map。
畫外音：
不少業務符合這一個模型；
Google的東西能解決業務問題，因此用的人多，這一點很重要。

總結

BigTable是一個稀疏的、分佈式的、持久化的、多維度排序的、大數據量存儲系統，它可以解決符合上述map數據模型業務的存儲問題。
畫外音：
GFS是文件系統；
MapReduce是計算模型；
BigTable是存儲系統。

BigTable是啥，解決啥問題，此次終於懂了。

不少時候，定義清楚問題比解決問題更難。

架構師之路-分享可落地的技術文章

相關推薦：《Google FileSystem架構啓示》《Google MapReduce解決什麼問題？》《MapReduce，顛覆了分層架構的本質？》