搞架構的人，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 BigTable到底解决什么问题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。