題記：google 的成功除了乙個個出色的創意外，還因為有 jeff dean 這樣的軟體架構天才。
------ 編者
官方的 google reader blog
中有對bigtable 的解釋。這是google 內部開發的乙個用來處理大資料量的系統。這種系統適合處理半結構化的資料比如 rss 資料來源。 以下發言
是 andrew hitchcock
在 2005 年10月18號 基於： google 的工程師 jeff dean 在華盛頓大學的一次談話 (creative commons license
).首先，bigtable 從 2004 年初就開始研發了，到現在為止已經用了將近8個月。（2023年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 s BigTable 原理 （翻譯）
題記 google 的成功除了乙個個出色的創意外，還因為有 jeff dean 這樣的軟體架構天才。編者 官方的 google reader blog 中有對bigtable 的解釋。這是google 內部開發的乙個用來處理大資料量的系統。這種系統適合處理半結構化的資料比如 rss 資料來源。以下發...
Google s BigTable 原理 （翻譯）
題記 google 的成功除了乙個個出色的創意外，還因為有 jeff dean 這樣的軟體架構天才。歡迎訂閱作者微博 編者 官方的 google reader blog 中有對bigtable 的解釋。這是google 內部開發的乙個用來處理大資料量的系統。這種系統適合處理半結構化的資料比如 rss...
Google s BigTable 原理 （翻譯）
題記 google 的成功除了乙個個出色的創意外，還因為有 jeff dean 這樣的軟體架構天才。編者 官方的 google reader blog 中有對bigtable 的解釋。這是google 內部開發的乙個用來處理大資料量的系統。這種系統適合處理半結構化的資料比如 rss 資料來源。以下發...