Big Table中文翻譯

題記：google 的成功除了一個個出色的創意外，還由於有 Jeff Dean 這樣的軟件架構天才。

官方的 Google Reader blog 中有對BigTable 的解釋。這是Google 內部開發的一個用來處理大數據量的系統。這種系統適合處理半結構化的數據好比 RSS 數據源。 如下發言  是 Andrew Hitchcock  在 2005 年10月18號 基於： Google 的工程師 Jeff Dean 在華盛頓大學的一次談話 (Creative Commons License).

 

 

首先，BigTable 從 2004 年初就開始研發了，到如今爲止已經用了將近8個月。（2005年2月）目前大概有100個左右的服務使用BigTable，好比： Print,Search History,Maps和 Orkut。根據Google的一向作法，內部開發的BigTable是爲跑在廉價的PC機上設計的。BigTable 讓Google在提供新服務時的運行成本下降，最大限度地利用了計算能力。BigTable 是創建在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。

每一個Table都是一個多維的稀疏圖 sparse map。Table 由行和列組成，而且每一個存儲單元 cell 都有一個時間戳。在不一樣的時間對同一個存儲單元cell有多份拷貝，這樣就能夠記錄數據的變更狀況。在他的例子中，行是URLs ，列能夠定義一個名字，好比：contents。Contents 字段就能夠存儲文件的數據。或者列名是：」language」，能夠存儲一個「EN」的語言代碼字符串。

爲了管理巨大的Table，把Table根據行分割，這些分割後的數據統稱爲：Tablets。每一個Tablets大概有 100-200 MB，每一個機器存儲100個左右的 Tablets。底層的架構是：GFS。因爲GFS是一種分佈式的文件系統，採用Tablets的機制後，能夠得到很好的負載均衡。好比：能夠把常常響應的表移動到其餘空閒機器上，而後快速重建。

Tablets在系統中的存儲方式是不可修改的 immutable 的SSTables，一臺機器一個日誌文件。當系統的內存滿後，系統會壓縮一些Tablets。因爲Jeff在論述這點的時候說的很快，因此我沒有時間把聽到的都記錄下來，所以下面是一個大概的說明：

壓縮分爲：主要和次要的兩部分。次要的壓縮僅僅包括幾個Tablets，而主要的壓縮時關於整個系統的壓縮。主壓縮有回收硬盤空間的功能。Tablets的位置其實是存儲在幾個特殊的BigTable的存儲單元cell中。看起來這是一個三層的系統。

客戶端有一個指向METAO的Tablets的指針。若是METAO的Tablets被頻繁使用，那個這臺機器就會放棄其餘的tablets專門支持METAO這個Tablets。METAO tablets 保持着全部的META1的tablets的記錄。這些tablets中包含着查找tablets的實際位置。（老實說翻譯到這裏，我也不太明白。）在這個系統中不存在大的瓶頸，由於被頻繁調用的數據已經被提早得到並進行了緩存。

    如今咱們返回到對 列的說明：列是相似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com  也許有列：」contents:其中包含html頁面的代碼。 「 anchor:cnn.com/news」 中包含着 相對應的url，」anchor:www.search-analysis.com/」 包含着連接的文字部分。列中包含着類型信息。

    (翻譯到這裏我要插一句，之前我看過一個關於萬能數據庫的文章，當時很激動，就聯繫了做者，如今回想起來，或許google的 bigtable 纔是更好的方案，切不說分佈式的特性，就是這種建華的表結構就頗有用處。)

    注意這裏說的是列信息，而不是列類型。列的信息是以下信息，通常是：屬性/規則。 好比：保存n份數據的拷貝 或者 保存數據n天長等等。當 tablets 從新創建的時候，就運用上面的規則，剔出不符合條件的記錄。因爲設計上的緣由，列自己的建立是很容易的，可是跟列相關的功能確實很是複雜的，好比上文提到的 類型和規則信息等。爲了優化讀取速度，列的功能被分割而後以組的方式存儲在所建索引的機器上。這些被分割後的組做用於 列 ,而後被分割成不一樣的 SSTables。這種方式能夠提升系統的性能，由於小的，頻繁讀取的列能夠被單獨存儲，和那些大的不常常訪問的列隔離開來。

在一臺機器上的全部的 tablets 共享一個log，在一個包含1億的tablets的集羣中，這將會致使很是多的文件被打開和寫操做。新的log塊常常被建立，通常是64M大小，這個GFS的塊大小相等。當一個機器down掉後，控制機器就會從新發布他的log塊到其餘機器上繼續進行處理。這臺機器重建tablets而後詢問控制機器處理結構的存儲位置，而後直接對重建後的數據進行處理。

這個系統中有不少冗餘數據，所以在系統中大量使用了壓縮技術。

    Dean 對壓縮的部分說的很快，我沒有徹底記下來，因此我仍是說個大概吧：壓縮前先尋找類似的 行，列，和時間 數據。

    他們使用不一樣版本的： BMDiff 和 Zippy 技術。

   BMDiff 提供給他們很是快的寫速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 相似的。Zippy 並不像 LZW 或者 gzip 那樣壓縮比高，可是他處理速度很是快。

    Dean 還給了一個關於壓縮 web 蜘蛛數據的例子。這個例子的蜘蛛 包含 2.1B 的頁面，行按照如下的方式命名：「com.cnn.www/index.html:http」.在未壓縮前的web page 頁面大小是：45.1 TB ，壓縮後的大小是：4.2 TB ， 只是原來的 9.2%。Links 數據壓縮到原來的 13.9% , 連接文本數據壓縮到原來的 12.7%。

Google 還有不少沒有添加可是已經考慮的功能。

    1.  數據操做表達式，這樣能夠把腳本發送到客戶端來提供修改數據的功能。
    2. 多行數據的事物支持。
    3.  提升大數據存儲單元的效率。
    4. BigTable 做爲服務運行。
    好像：每一個服務好比： maps 和 search history 歷史搜索記錄都有他們本身的集羣運行 BigTable。
    他們還考慮運行一個全局的 BigTable 系統，但這須要比較公平的分割資源和計算時間。

原文地址：
http://blog.csdn.net/accesine960/archive/2006/02/09/595628.aspx

http://blog.outer-court.com/archive/2005-10-23-n61.html