Google s BigTable 原理 (翻譯)

2021-09-30 07:13:42 字數 3119 閱讀 1707

題記: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/s1000mb/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...