Google BigTable 原理 （翻譯）
題記：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 系統，但這需要比較公平的分割資源和計算時間
------ 編者
官方的 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 系統，但這需要比較公平的分割資源和計算時間