題記：google 的成功除了一個(gè)個(gè)出色的創(chuàng )意外，還因為有 Jeff Dean 這樣的軟件架構天才。
------ 編者
官方的 Google Reader blog 中有對BigTable 的解釋。這是Google 內部開(kāi)發(fā)的一個(gè)用來(lái)處理大數據量的系統。這種系統適合處理半結構化的數據比如 RSS 數據源。 以下發(fā)言 是 Andrew Hitchcock 在 2005 年10月18號 基于： Google 的工程師 Jeff Dean 在華盛頓大學(xué)的一次談話(huà) (Creative Commons License).
首先，BigTable 從 2004 年初就開(kāi)始研發(fā)了，到現在為止已經(jīng)用了將近8個(gè)月。（2005年2月）目前大概有100個(gè)左右的服務(wù)使用BigTable，比如： Print,Search History,Maps和 Orkut。根據Google的一貫做法，內部開(kāi)發(fā)的BigTable是為跑在廉價(jià)的PC機上設計的。BigTable 讓Google在提供新服務(wù)時(shí)的運行成本降低，最大限度地利用了計算能力。BigTable 是建立在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。
每個(gè)Table都是一個(gè)多維的稀疏圖 sparse map。Table 由行和列組成，并且每個(gè)存儲單元 cell 都有一個(gè)時(shí)間戳。在不同的時(shí)間對同一個(gè)存儲單元cell有多份拷貝，這樣就可以記錄數據的變動(dòng)情況。在他的例子中，行是URLs ，列可以定義一個(gè)名字，比如：contents。Contents 字段就可以存儲文件的數據?；蛘吡忻牵?#8221;language”，可以存儲一個(gè)“EN”的語(yǔ)言代碼字符串。
為了管理巨大的Table，把Table根據行分割，這些分割后的數據統稱(chēng)為：Tablets。每個(gè)Tablets大概有 100-200 MB，每個(gè)機器存儲100個(gè)左右的 Tablets。底層的架構是：GFS。由于GFS是一種分布式的文件系統，采用Tablets的機制后，可以獲得很好的負載均衡。比如：可以把經(jīng)常響應的表移動(dòng)到其他空閑機器上，然后快速重建。
Tablets在系統中的存儲方式是不可修改的 immutable 的SSTables，一臺機器一個(gè)日志文件。當系統的內存滿(mǎn)后，系統會(huì )壓縮一些Tablets。由于Jeff在論述這點(diǎn)的時(shí)候說(shuō)的很快，所以我沒(méi)有時(shí)間把聽(tīng)到的都記錄下來(lái)，因此下面是一個(gè)大概的說(shuō)明：
壓縮分為：主要和次要的兩部分。次要的壓縮僅僅包括幾個(gè)Tablets，而主要的壓縮時(shí)關(guān)于整個(gè)系統的壓縮。主壓縮有回收硬盤(pán)空間的功能。Tablets的位置實(shí)際上是存儲在幾個(gè)特殊的BigTable的存儲單元cell中?？雌饋?lái)這是一個(gè)三層的系統。
客戶(hù)端有一個(gè)指向METAO的Tablets的指針。如果METAO的Tablets被頻繁使用，那個(gè)這臺機器就會(huì )放棄其他的tablets專(zhuān)門(mén)支持METAO這個(gè) Tablets。METAO tablets 保持著(zhù)所有的META1的tablets的記錄。這些tablets中包含著(zhù)查找tablets的實(shí)際位置。（老實(shí)說(shuō)翻譯到這里，我也不太明白。）在這個(gè)系統中不存在大的瓶頸，因為被頻繁調用的數據已經(jīng)被提前獲得并進(jìn)行了緩存。
現在我們返回到對 列的說(shuō)明：列是類(lèi)似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com 也許有列：”contents:其中包含html頁(yè)面的代碼。 “ anchor:cnn.com/news” 中包含著(zhù) 相對應的url，”anchor:www.search-analysis.com/” 包含著(zhù)鏈接的文字部分。列中包含著(zhù)類(lèi)型信息。
(翻譯到這里我要插一句，以前我看過(guò)一個(gè)關(guān)于萬(wàn)能數據庫的文章，當時(shí)很激動(dòng)，就聯(lián)系了作者，現在回想起來(lái)，或許google的 bigtable 才是更好的方案，切不說(shuō)分布式的特性，就是這種建華的表結構就很有用處。)
注意這里說(shuō)的是列信息，而不是列類(lèi)型。列的信息是如下信息，一般是：屬性/規則。 比如：保存n份數據的拷貝 或者 保存數據n天長(cháng)等等。當 tablets 重新建立的時(shí)候，就運用上面的規則，剔出不符合條件的記錄。由于設計上的原因，列本身的創(chuàng )建是很容易的，但是跟列相關(guān)的功能確實(shí)非常復雜的，比如上文提到的 類(lèi)型和規則信息等。為了優(yōu)化讀取速度，列的功能被分割然后以組的方式存儲在所建索引的機器上。這些被分割后的組作用于 列 ,然后被分割成不同的 SSTables。這種方式可以提高系統的性能，因為小的，頻繁讀取的列可以被單獨存儲，和那些大的不經(jīng)常訪(fǎng)問(wèn)的列隔離開(kāi)來(lái)。
在一臺機器上的所有的 tablets 共享一個(gè)log，在一個(gè)包含1億的tablets的集群中，這將會(huì )導致非常多的文件被打開(kāi)和寫(xiě)操作。新的log塊經(jīng)常被創(chuàng )建，一般是64M大小，這個(gè) GFS的塊大小相等。當一個(gè)機器down掉后，控制機器就會(huì )重新發(fā)布他的log塊到其他機器上繼續進(jìn)行處理。這臺機器重建tablets然后詢(xún)問(wèn)控制機器處理結構的存儲位置，然后直接對重建后的數據進(jìn)行處理。
這個(gè)系統中有很多冗余數據，因此在系統中大量使用了壓縮技術(shù)。
Dean 對壓縮的部分說(shuō)的很快，我沒(méi)有完全記下來(lái)，所以我還是說(shuō)個(gè)大概吧：壓縮前先尋找相似的 行，列，和時(shí)間 數據。
他們使用不同版本的： BMDiff 和 Zippy 技術(shù)。
BMDiff 提供給他們非?？斓膶?xiě)速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 類(lèi)似的。Zippy 并不像 LZW 或者 gzip 那樣壓縮比高，但是他處理速度非?？?。
Dean 還給了一個(gè)關(guān)于壓縮 web 蜘蛛數據的例子。這個(gè)例子的蜘蛛 包含 2.1B 的頁(yè)面，行按照以下的方式命名：“com.cnn.www/index.html:http”.在未壓縮前的web page 頁(yè)面大小是：45.1 TB ，壓縮后的大小是：4.2 TB ， 只是原來(lái)的 9.2%。Links 數據壓縮到原來(lái)的 13.9% , 鏈接文本數據壓縮到原來(lái)的 12.7%。
Google 還有很多沒(méi)有添加但是已經(jīng)考慮的功能。
1. 數據操作表達式，這樣可以把腳本發(fā)送到客戶(hù)端來(lái)提供修改數據的功能。
2. 多行數據的事物支持。
3. 提高大數據存儲單元的效率。
4. BigTable 作為服務(wù)運行。
好像：每個(gè)服務(wù)比如： maps 和 search history 歷史搜索記錄都有他們自己的集群運行 BigTable。
他們還考慮運行一個(gè)全局的 BigTable 系統，但這需要比較公平的分割資源和計算時(shí)間。
原文地址：
http://blog.csdn.net/accesine960/archive/2006/02/09/595628.aspxhttp://blog.outer-court.com/archive/2005-10-23-n61.html
