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 BigTable到底解决什么问题？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一文盘点数据行业的动态演变
- 下一篇： Springboot中mongodb的使