題記：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 系統，但這需要比較公平的分割資源和計算時間。
谷歌三大核心技術 BigTable中文版
題記 google 的成功除了乙個個出色的創意外，還因為有 jeff dean 這樣的軟體架構天才。編者 官方的 google reader blog 中有對bigtable 的解釋。這是google 內部開發的乙個用來處理大資料量的系統。這種系統適合處理半結構化的資料比如 rss 資料來源。以下發...
詳解 Amazon Go 三大核心技術
12月5日，亞馬遜發布 amazon go 震驚業界，我們第一時間研究了專利檔案，並採訪資深計算機視覺演算法工程師，最終出文從2份專利檔案，一窺amazon go到底藏了什麼黑科技?今天特地採訪了無人零售商店創業者陳維龍為大家更加詳細地解讀 amazon go 以及無人零售商店專案。陳維龍畢業於中山...
UML核心技術學習 三
用例模型是把應滿足使用者需求的基本功能 集 聚合起來表示的強大工具 用例模型的基本組成部件是用例 角色和系統。用例用於描述系統的功能 角色是與系統進行互動的外部實體，可以是系統使用者 也可以是其它系統或硬體裝置 系統的邊界線以內的區域 即用例的活動區域 則抽象表示系統能夠實現的所有基本功能 引入用例...