搞架構的人，Google的論文是必看的，但好像大家都不愿意去啃英文論文。故把自己的讀書(shū)筆記，加入自己的思考，分享給大家。
第三部分，Google BigTable。
BigTable，很多人對它耳熟能詳，但它究竟解決什么問(wèn)題呢？這是今天要聊的話(huà)題。
什么是BigTable？
Google BigTable是一個(gè)分布式，結構化數據的存儲系統，它用來(lái)存儲海量數據。該系統用來(lái)滿(mǎn)足“大數據量、高吞吐量、快速響應”等不同應用場(chǎng)景下的存儲需求。
畫(huà)外音：本質(zhì)上，BigTable是一個(gè)存儲系統。
有BigTable之前，Google面臨什么問(wèn)題？
Google并不是一群人坐在辦公室開(kāi)會(huì )，想出來(lái)的系統，Google面臨著(zhù)很實(shí)際的業(yè)務(wù)問(wèn)題。
畫(huà)外音：
很多公司的基礎架構部，是坐在辦公室開(kāi)會(huì )，想出來(lái)的東西，然后強推業(yè)務(wù)線(xiàn)使用；
脫離業(yè)務(wù)的技術(shù)，都是耍流氓。
典型場(chǎng)景一：網(wǎng)頁(yè)存儲
Google每天要抓取很多網(wǎng)頁(yè)：
新出現的網(wǎng)頁(yè)，新URL
舊網(wǎng)頁(yè)，舊URL
對一個(gè)已抓取的網(wǎng)頁(yè)，舊URL為啥要反復抓??？
因為，網(wǎng)頁(yè)會(huì )更新，例如新浪首頁(yè)：
sina.com.cn/index.html
URL雖然沒(méi)有變，但依然會(huì )抓取。
畫(huà)外音：我去，相當于，被抓取的URL集合，只會(huì )無(wú)限增大，趨近無(wú)窮，這里面的技術(shù)難題，不知道大家感不感興趣？
這里，對于存儲系統的需求，是要存儲：不同URL，不同時(shí)間Time，的內容Content。
畫(huà)外音：URL+”Content”+Time => Binary。
網(wǎng)頁(yè)的實(shí)際內容Binary，是Spider抓取出來(lái)的。
典型場(chǎng)景二：Google Analytics
Google Analytics要給站長(cháng)展示其網(wǎng)站的流量PV，獨立用戶(hù)數UV，典型訪(fǎng)問(wèn)路徑等，以幫助站長(cháng)了解站點(diǎn)情況，優(yōu)化站點(diǎn)。
這里，對于存儲系統的需求，是要存儲，不同URL，不同時(shí)間Time，的PV和UV。
畫(huà)外音：
URL+”P(pán)V”+Time => $count
URL+”UV”+Time => $count
PV和UV的值，是MapReduce離線(xiàn)任務(wù)計算出來(lái)的。
不管是“網(wǎng)頁(yè)存儲”還是“站點(diǎn)統計”存儲，它們都有幾個(gè)共同的特點(diǎn)：
數據量極大，TB，PB級別
和時(shí)間維度相關(guān)
同一個(gè)主鍵，屬性與值有映射
畫(huà)外音：
主鍵是URL，屬性是“Content”，值是網(wǎng)頁(yè)Binary；
主鍵是URL，屬性是“PV”和“UV”，值是計數count。
這是Google曾經(jīng)遇到的難題，面對這些難題，典型的解決方案又有哪些呢？
畫(huà)外音：不是一上來(lái)就搞新方案，最先肯定是想用現有的技術(shù)要如何解決。
最容易想到的主鍵，屬性，值的存儲系統是什么？
沒(méi)錯，就是關(guān)系型數據庫：
如上圖所示，用戶(hù)表
User(uid PK, name, gender, age, sex)
就是一個(gè)典型的主鍵，屬性，值的存儲模型：
主鍵，不同用戶(hù)的uid
屬性，schema的列名
值，不同主鍵的各個(gè)列名，對應的值
使用excel來(lái)舉例是很直觀(guān)的，這是一個(gè)二維table。
畫(huà)外音：屎黃色的主鍵是一個(gè)維度，橙色的屬性是一個(gè)維度。
用二維table能不能解決Google網(wǎng)頁(yè)存儲的問(wèn)題呢？
如上圖所示，如果沒(méi)有時(shí)間維度Time，似乎是可以的：
主鍵，使用URL
屬性，schema的列名，例如content，author等
值，不同URL的內容與作者等值
但是，一旦加入時(shí)間維度Time，二維table似乎就不靈了。
畫(huà)外音：
增加一個(gè)time屬性是沒(méi)有用的；
增加一個(gè)time屬性，只能記錄同一個(gè)URL，某一個(gè)time的content，不能記錄多個(gè)time的多個(gè)content；
增加一個(gè)time屬性，聯(lián)合主鍵，URL就不是KEY了；
能不能用二維table存儲三維數據呢？
似乎可以通過(guò)trick的手段，在key上做文章，用key+time來(lái)拼接新key來(lái)實(shí)現。
如上圖所示，仍然是二維table，通過(guò)URL+Time來(lái)瓶裝key，也能夠實(shí)現，存儲同一個(gè)URL，在不同Time，的不同content、author。
但是，這種trick方案存在的問(wèn)題是：
沒(méi)法實(shí)現URL查詢(xún)
畫(huà)外音：key上無(wú)法進(jìn)行%like%查詢(xún)。
大量空洞，浪費存儲空間
這并不是一個(gè)好的方案。
況且，當數據量達到TB、PB級別時(shí)，傳統單機關(guān)系型數據庫，根本無(wú)法滿(mǎn)足Google的業(yè)務(wù)需求。
BigTable解決什么問(wèn)題？
傳統二維small table，無(wú)法解決Google面臨的存儲問(wèn)題，于是Google搞了一個(gè)big table來(lái)解決。
Google對這些業(yè)務(wù)模型進(jìn)行分析，在二維table的基礎上擴充，抽象了一個(gè)新的“三維table”：
主鍵，使用URL
屬性，schema的列名，例如content，author等
時(shí)間，timestamp
值，不同URL的內容與作者等值
如上圖所示：
第一維：key（屎黃色）
第二維：屬性（橙色）
第三維：time（藍色）
同一個(gè)key，不同屬性，不同時(shí)間，會(huì )存儲一個(gè)value。
不像以行為單位進(jìn)行存儲的傳統關(guān)系型數據庫，這個(gè)三維的大表格BigTable是一個(gè)稀疏列存儲系統。
畫(huà)外音：能夠壓縮空間。
它的數據模型的本質(zhì)是一個(gè)map：
key + column + time => value
的一個(gè)超級大map。
畫(huà)外音：
很多業(yè)務(wù)符合這一個(gè)模型；
Google的東西能解決業(yè)務(wù)問(wèn)題，所以用的人多，這一點(diǎn)很重要。
總結
BigTable是一個(gè)稀疏的、分布式的、持久化的、多維度排序的、大數據量存儲系統，它能夠解決符合上述map數據模型業(yè)務(wù)的存儲問(wèn)題。
畫(huà)外音：
GFS是文件系統；
MapReduce是計算模型；
BigTable是存儲系統。
BigTable是啥，解決啥問(wèn)題，這次終于懂了。
很多時(shí)候，定義清楚問(wèn)題比解決問(wèn)題更難。
架構師之路-分享可落地的技術(shù)文章
聯(lián)系客服
