細(xì)數(shù)Google HBase與BigTable區(qū)別在哪里？
HBase是Google的BigTable架構(gòu)的一個(gè)開(kāi)源實(shí)現(xiàn)。但是我個(gè)人覺(jué)得，要做到充分了解下面兩點(diǎn)還是有點(diǎn)困難的：
一 HBase涵蓋了BigTable規(guī)范的哪些部分？
二 HBase與BigTable仍然有哪些區(qū)別？
下面我將對(duì)這兩個(gè)系統(tǒng)做些比較。
在做比較之前，我要指出一個(gè)事實(shí)：HBase是非常接近BigTable論文描述的東西。撇開(kāi)一些細(xì)微的不同，比如HBase 0.20使用ZooKeeper做它的分布式協(xié)調(diào)服務(wù)，HBase已經(jīng)基本實(shí)現(xiàn)了BigTable所有的功能，所以我下面的篇幅重點(diǎn)落在它們細(xì)微的區(qū)別上，當(dāng)然也可以說(shuō)是HBase小組正在努力改進(jìn)的地方上。
比較范圍
本文比較的是基于七年前發(fā)表的論文（OSDI’06）所描敘的Google BigTable系統(tǒng),該系統(tǒng)從2005年開(kāi)始運(yùn)作。就在論文發(fā)表的2006年末到2007年初，作為Hadoop的子項(xiàng)目的HBase也產(chǎn)生了。在那時(shí)，HBase的版本是0.15.0. 如今大約2年過(guò)去了，Hadoop 0.20.1和HBase 0.20.2都已發(fā)布，你當(dāng)然希望有一些真正的改進(jìn)。要知道我所比較的是一篇14頁(yè)的技術(shù)論文和一個(gè)從頭到腳都一覽無(wú)余的開(kāi)源項(xiàng)目。所以下面的比較內(nèi)容里關(guān)于HBase怎么做的講得比較多點(diǎn)。
在文章的結(jié)尾，我也會(huì)討論一些BigTable的如今的新功能，以及HBase跟它們比較如何。好，我們就從術(shù)語(yǔ)開(kāi)始。
術(shù)語(yǔ)
有少數(shù)幾個(gè)不同的術(shù)語(yǔ)被兩個(gè)系統(tǒng)用來(lái)描述同樣的事物。最顯著的莫過(guò)于HBase中的regions和BigTable中的tablet。自然地，它們各自把一連串的行（Rows）切分交給許多Region server或者tablet server管理。
特性比較接下來(lái)的就是特性比較列表，列表中是BigTable跟HBase的特性比較。有的是一些實(shí)現(xiàn)細(xì)節(jié)，有的是可配置的選項(xiàng)等。讓人感到有困惑的是，將這些特性分類很難。
| 特性 | BigTable |
HBase |
說(shuō)明 |
| 讀 / 寫(xiě) / 修改的原子性 | 支持，每行 | 支持，每行 |
因?yàn)?BigTable 不像關(guān)系型數(shù)據(jù)庫(kù)，所以不支持事務(wù)。最接近事務(wù)的就是讓對(duì)每行數(shù)據(jù)訪問(wèn)具有原子性。 HBase 同樣實(shí)現(xiàn)了”行鎖”的 API ，讓用戶訪問(wèn)數(shù)據(jù)時(shí)給一行或者幾行數(shù)據(jù)加鎖。 |
| 詞典順序的行排序 | 支持 | 支持 | 所有行都按照詞典順序排序 |
| 數(shù)據(jù)塊支持 | 支持 | 支持 |
在數(shù)據(jù)存儲(chǔ)文件中，數(shù)據(jù)是由更小的數(shù)據(jù)塊構(gòu)成的。這使從大的存儲(chǔ)文件讀取數(shù)據(jù)更快。數(shù)據(jù)塊的大小是可配置的，典型配置是 64K 。 |
| 數(shù)據(jù)塊壓縮 |
支持，按 Column Family |
支持，按 Column Family |
Google 使用 BMDiff 和 Zippy 做兩步處理。 BMDiff 工作得很好是因?yàn)榇鎯?chǔ)文件中相鄰的 key-value 對(duì)的內(nèi)容經(jīng)常非常相似。因?yàn)閿?shù)據(jù)支持多個(gè)版本，幾個(gè)版本的內(nèi)容會(huì)被排序然后被存在一起，它們之間有很多相同的內(nèi)容?；蛘?row key 也會(huì)被用這樣的方式處理，比如如果用 URL 來(lái)作為 row key ，而這些 URL 來(lái)自統(tǒng)一個(gè)網(wǎng)站，那么 row key 也會(huì)有很多相似之處。 Zippy 使用的是改進(jìn)的 LZW 算法。 HBase 使用的是 Java 支持的標(biāo)準(zhǔn)的 GZip ，以及一點(diǎn)點(diǎn) GPL licensed LZO 格式支持。 Hadoop 也有想使用 BMDiff 和 Zippy 的征兆。 |
| Column Family 數(shù)量限制 | 最多幾百 |
小于 100 |
理論上行數(shù)和列數(shù)是無(wú)限的，可是列族（ column family ）卻不是。這個(gè)只是設(shè)計(jì)上的一些折中考率 . |
| Column Famil 命名格式 | 可打印 | 可打印 |
HBase 這樣做的主要原因是 Column Famil 的名稱會(huì)被作為文件系統(tǒng)中的目錄名稱 |
| Qualifier 命名的格式 | 任意 | 任意 | 任意的字節(jié)數(shù)組 |
| Key/Value 對(duì)的格式 | 任意 | 任意 | 任意的字節(jié)數(shù)組 |
| 訪問(wèn)控制 | 支持 | 無(wú) |
BigTable 支持 column family 級(jí)別的訪問(wèn)控制。 HBase 暫不支持 |
| Cell 多版本 | 支持 | 支持 |
多版本支持是基于時(shí)間戳。 版本數(shù)目限制可以基于 cloumn family 級(jí)別自由配置 |
| 自定義時(shí)間戳 | 支持 | 支持 | 兩個(gè)系統(tǒng)都支持用戶設(shè)定時(shí)間戳，如果用戶不指定，則使用當(dāng)前時(shí)間作為時(shí)間戳。 |
| 數(shù)據(jù) TTL | 支持 | 支持 |
除了數(shù)據(jù)可以有多個(gè)版本，用戶還可制定 TTL （ time-to-live ），當(dāng)數(shù)據(jù)到期后會(huì)被清除 |
| 批量寫(xiě)入 | 支持 | 支持 | 都支持批量表操作 |
| 值計(jì)數(shù)器 | 支持 | 支持 |
兩者都可使用特定的列作為原子計(jì)數(shù)器。 HBase 實(shí)現(xiàn)是：當(dāng)計(jì)數(shù)器的值要增長(zhǎng)時(shí)，它必須獲得行鎖。 |
| 行過(guò)濾器 | 支持 | 支持 | 兩者都支持掃描行時(shí)支持行過(guò)濾器 |
| 客戶端腳本執(zhí)行 | 支持 | 不支持 |
BigTable 使用 Sawzall 使客戶端可以處理存儲(chǔ)的數(shù)據(jù)。 |
| MapReduce 支持 | 支持 | 支持 |
兩者都有方便的工具類讓 MapReduce Job 掃描表。 |
| 底層文件系統(tǒng) | GFS | HDFS,S3, S3N, EBS |
BigTable 工作在 GFS 之上， HBase 可以使用任何文件系統(tǒng)，只要有該文件系統(tǒng)的代理或者驅(qū)動(dòng)即可。 |
| 存儲(chǔ)文件格式 | SSTable | HFile | |
| 塊索引 | 在文件*** | 在文件*** | 兩者都有相似的塊結(jié)構(gòu)化的存儲(chǔ)文件格式，并且塊索引被放在文件的*** |
| 內(nèi)存映射 | 支持 | 不支持 |
BigTable 可以讓存儲(chǔ)文件直接映射到內(nèi)存。 |
| 鎖服務(wù) | Chubby | ZooKeeper |
ZooKeeper 被 HBase 用來(lái)協(xié)調(diào)任務(wù)并非當(dāng)成鎖服務(wù)?？傮w說(shuō)來(lái)， HBase 使用 ZooKeeper 達(dá)到了 BigTable 使用 Chubby 的效果，只有語(yǔ)義有點(diǎn)細(xì)微區(qū)別。 |
| 單個(gè) Master | 是 | 不是 |
HBase 近來(lái)支持多個(gè) Master 。多個(gè) Master 是”熱”待命模式工作，它們都偵聽(tīng) ZooKeeper 上的 Master 節(jié)點(diǎn)。 |
| Tablet/Region 數(shù)目 | 10-1000 | 10-1000 |
兩個(gè)系統(tǒng)都推薦每個(gè) Region server 分配相同數(shù)目的 region 。當(dāng)然這決定于很多因素，由于兩個(gè)系統(tǒng)都使用普通電腦，出于負(fù)載考慮，它們推薦相同的數(shù)目 |
| Tablet/Region 大小 | 100-200MB | 256MB |
在兩個(gè)系統(tǒng)中，單個(gè) Region 大小是可配置的，在 HBase 中，默認(rèn)大小為 256MB |
| Root 位置 | 1st META / Chubby | -ROOT- / ZooKeeper |
HBase 會(huì)使用一個(gè)只有單個(gè) Region 的自身表來(lái)存儲(chǔ) Root 表。二者啟動(dòng)時(shí)都會(huì)把 Root region 所在機(jī)器的地址放到 ZooKeeper 或者 Chubby 中。 |
| 客戶端 Region 信息緩存 | 支持 | 不支持 |
二者客戶端都支持 Region 位置信息緩存并且有相應(yīng)的機(jī)制去除過(guò)時(shí)的緩存和更新緩存 |
| Meta 預(yù)讀 | 支持 | 不支持（？） |
BigTable 的一個(gè)設(shè)計(jì)就是會(huì)預(yù)讀超過(guò) 1 個(gè) Meta Region 信息并將之放入客戶端緩存。 |
| Region 事件記錄 | 支持 | 支持 |
Region 相關(guān)事件（切分，分配，再分配）都會(huì)記錄在 Meta 表中 |
| 存儲(chǔ)位置分組（ Locality Groups ） | 支持 | 不支持 |
這不是很確定，但是看起來(lái) BigTable 中的任何東西都有個(gè)位置分組的屬相。如果多個(gè)列族的位置分組相同，那么它們將被存放在一起，并且擁有相同的配置參數(shù)。單個(gè)列族就可能是一個(gè)擁有一個(gè)成員的位置分組。 HBase 不支持這種選項(xiàng)，并將不同的列族分開(kāi)存儲(chǔ)。 |
| 完全內(nèi)存 Column Family 存儲(chǔ) | 支持 | 支持 | 這是為需要高速存取小表準(zhǔn)備的 |
| KeyValue 緩存 | 支持 | 不支持 |
緩存熱點(diǎn) Cell 數(shù)據(jù) |
| 數(shù)據(jù)塊緩存 | 支持 | 支持 | 數(shù)據(jù)塊從存儲(chǔ)文件讀入到在可配置的緩存中 |
| 布隆過(guò)濾器 (Bloom Filters) | 支持 | 支持 |
這些過(guò)濾器會(huì)消耗一些內(nèi)存，但是可以快速檢查一個(gè)指定的 cell 是否在一個(gè) Region Server 上存在 |
| Write-Ahead Log (WAL) | 支持 | 支持 |
每個(gè) Region Server 都會(huì)記錄被它管理的所有 Region 上的數(shù)據(jù)改動(dòng) |
| Secondary Log | 支持 | 不支持 |
出于性能考慮，一旦 WAL 性能下降， BigTable 還有別的 log 可以使用 |
| 忽略 Write-Ahead Log | ？ | 支持 |
在大量數(shù)據(jù)導(dǎo)入時(shí)， HBase 的客戶端可以選擇忽略 WAL |
| 快速 Region 切分 | 支持 | 支持 |
切分 region 是快速的，因?yàn)榍蟹殖鰜?lái)的子 region 暫時(shí)還會(huì)去讀取原存儲(chǔ)文件直到一個(gè) compaction 將數(shù)據(jù)寫(xiě)入 region 的自有的存儲(chǔ)文件 |
BigTable 新特性
OSDI’06 BigTable論文發(fā)表已有幾年，BigTable當(dāng)然也有改進(jìn)。杰夫.迪恩—一個(gè)在Google的家伙在近來(lái)的一些演講和演示中提到了 BigTable的新特性。我們就來(lái)瞧瞧部分新特性吧。
| 特性 | BigTable | HBase | 說(shuō)明 |
| 客戶端隔離 | 支持 | 不支持 |
BigTable 可以內(nèi)在地被用來(lái)服務(wù)很多單獨(dú)的客戶端，并且使它們的數(shù)據(jù)隔離不互相影響 |
|
協(xié)同處理（ Coprocessors ） |
支持 | 暫不支持 |
BigTable 在 region 中運(yùn)行的代碼可以隨著 region 的被切分，代碼也被會(huì)切分到新的 region 上運(yùn)行。 |
| 數(shù)據(jù)錯(cuò)誤安全 | 支持 | 不支持 |
BigTable 使用 CRC 校驗(yàn)碼確認(rèn)數(shù)據(jù)是否被安全寫(xiě)入。 HBase 沒(méi)有這個(gè)特性，問(wèn)題是： Hadoop 是否會(huì)包含這個(gè)特性？ |
| 數(shù)據(jù)中心間數(shù)據(jù)復(fù)制 | 支持 | 暫不支持 |
HBase 的一個(gè) issue ： HBASE-1295 就是關(guān)于這個(gè)特性的。 |
變化和差異
上面討論的一些特性比較可以看出有些特性差異并不是可以簡(jiǎn)單歸結(jié)為”是或否”類的問(wèn)題，對(duì)這類問(wèn)題我將在下面單獨(dú)探討。
鎖服務(wù)
下面的來(lái)自BigTable論文
BigTable用Chubby來(lái)完成一些不同的任務(wù)：保證在任何時(shí)候只有一個(gè)活動(dòng)的Master；存儲(chǔ)BigTable引導(dǎo)區(qū)地址；發(fā)現(xiàn)tablet server以及在table server死亡時(shí)做善后工作；存儲(chǔ)BigTable的schema信息（每個(gè)表的列族信息）；存儲(chǔ)訪問(wèn)控制列表。如果Chubby在一段較長(zhǎng)的時(shí)候變得不可用，那么BigTable系統(tǒng)就會(huì)變得不可用。
BigTable如何使用Chubby跟HBase如何使用ZooKeeper有很多異曲同工之處。但有一個(gè)區(qū)別就是：HBase并不把 Schema信息存儲(chǔ)在ZooKeeper中。它們都非常依賴鎖服務(wù)的正常運(yùn)作。根據(jù)我自身的經(jīng)驗(yàn)以及我閱讀HBase郵件列表所得到的，我們經(jīng)常低估當(dāng) ZooKeeper無(wú)法取得足夠的資源去作出實(shí)時(shí)回應(yīng)時(shí)的后果。寧可讓ZooKeeper集群運(yùn)行在相對(duì)較老舊的但是什么別的事都不干的機(jī)器上，而不是運(yùn)行在已被Hadoop或者HBase進(jìn)程搞得不堪重負(fù)的機(jī)器上。一旦你的ZooKeeper沒(méi)有足夠的資源提供服務(wù)，就會(huì)引發(fā)多米諾骨式的效應(yīng)，HBase將會(huì)掛掉—包括master節(jié)點(diǎn)。
更新：在跟ZooKeeper開(kāi)發(fā)小組討論后，我想指出的是這并不真正意義上是ZooKeeper的一個(gè)問(wèn)題。因?yàn)槿绻\(yùn)行ZooKeeper的機(jī)器負(fù)荷很重，那么存取ZooKeeper上的資源很可能會(huì)超時(shí)。在這種情形下，HBase的Region Server甚至Master可能會(huì)認(rèn)為協(xié)調(diào)服務(wù)已經(jīng)壞了，它們就會(huì)讓自己停工關(guān)閉。 帕特里克 . 亨特已經(jīng)通過(guò)郵件和發(fā)帖對(duì)此作出回應(yīng)。你可以讀他的郵件或者帖子，然后檢查自己的 ZooKeeper 是否有能力處理負(fù)荷。我個(gè)人建議是將 ZooKeeper 集群跟 HBase 集群分開(kāi)。你可以把 ZooKeeper 集群運(yùn)行在一組空閑的稍微有點(diǎn)過(guò)時(shí)但是性能還相當(dāng)不錯(cuò)的機(jī)器上。這樣你可以單獨(dú)監(jiān)控 ZooKeeper 集群和 HBase 集群中的機(jī)器，而不必有以下的煩惱：當(dāng)一個(gè)機(jī)器的 CPU 負(fù)荷 100% 的時(shí)候，你搞不清楚這個(gè)負(fù)荷究竟來(lái)自哪個(gè)進(jìn)程或者有什么后果。
另外一個(gè)重要區(qū)別是： ZooKeeper 并不是一個(gè)像 Chubby 一樣的鎖服務(wù)系統(tǒng)，但是目前為止，這并不是 HBase 所關(guān)心的。 ZooKeeer 提供一個(gè)分布式的協(xié)調(diào)服務(wù)，讓 HBase 可以選舉出 Master 節(jié)點(diǎn)。它也可以提供用以表示狀態(tài)或者某個(gè)動(dòng)作需要的信號(hào)量。當(dāng) Chubby 生成一個(gè)鎖文件來(lái)表示一個(gè) tablet 活動(dòng)的，與此相對(duì)應(yīng)的一個(gè) Region server 會(huì)在 ZooKeeper 中生成一個(gè)節(jié)點(diǎn)來(lái)表示自己的存在。這個(gè)節(jié)點(diǎn)創(chuàng)建以后，只要 ZooKeeper 不掛，它會(huì)一直存在。在 BigTable 中，當(dāng)一個(gè) tablet server 的鎖文件被刪除時(shí)就表示與這個(gè) tablet server 的租約失效。在 HBase 中，因?yàn)?/span> ZooKeeper 相對(duì)少點(diǎn)限制的架構(gòu)，這種行為會(huì)被處理得有所不同。它們只是語(yǔ)義上有所差別，并不意味著誰(shuí)優(yōu)誰(shuí)劣，僅僅有所不同而已。
在Chubby中，***層級(jí)的文件包含著根tablet的位置信息。根tablet包含著一個(gè)特別的名叫METADATA（元數(shù)據(jù)）表的所有的tablet的位置信息。每個(gè)METADATA的tablet包含著一組用戶表的tablet的位置信息。根tablet僅僅是METADATA表中***個(gè)tablet，但是它被特別的看待—它從不會(huì)被切分，這是為了保證tablet的位置層級(jí)不會(huì)超過(guò)3層。
就如上面所說(shuō)的，在HBase中，根region是一個(gè)只有單個(gè)region的表。要說(shuō)有什么區(qū)別的話，那就是根region并不是meta表中的***個(gè)不可切分的region。它們是相同的功能，只是實(shí)現(xiàn)上有差別。
METADATA表存儲(chǔ)著tablet的位置信息，跟在起始row key和末尾row key以及表名之后。
HBase的做法有點(diǎn)不同，它也會(huì)為每個(gè)region存儲(chǔ)起始的row key和末尾row key，但是末尾的row key并不是屬于當(dāng)前的region的，它會(huì)是另一個(gè)region的起始row key.
Master的行為
為了偵測(cè)一個(gè)tablet server是否不再為它的tablets服務(wù)，master會(huì)定期地查看每個(gè)tablet server鎖文件的狀態(tài)。當(dāng)一個(gè)tablet server報(bào)告它丟失了鎖文件，或者master經(jīng)過(guò)幾次嘗試后未能聯(lián)系上tablet server, master就會(huì)嘗試在tablet server的鎖文件上獲得獨(dú)占鎖。如果master可以獲得這個(gè)鎖，還有Chubby是良好工作的，這時(shí)如果tablet server已經(jīng)死亡或者已經(jīng)把錯(cuò)誤上報(bào)給Chubby，這時(shí)master就可以確定該tablet server不可能恢復(fù)，于是會(huì)刪除它的鎖文件。一旦一個(gè)tablet server的鎖文件被刪除，本來(lái)被該tablet server服務(wù)的tablets會(huì)被移到?jīng)]被分配的tablets集合中去。為了保證master和Chubby之間網(wǎng)絡(luò)暢通，只要master的Chubby session過(guò)期，master將會(huì)自殺。
直到0.20.2版本，HBase的行為都相當(dāng)不同。Region server利用heartbeat協(xié)議給master定期報(bào)告，master接到報(bào)告就知道region server還活著。
Master啟動(dòng)
Master啟動(dòng)有以下步驟：（1）Master從Chubby中獲取唯一的master鎖，用來(lái)防止多個(gè)master的初始化（2）Master 掃描Chubby中的server目錄找到活動(dòng)的server.(3) Master跟多個(gè)活動(dòng)的tablet server通訊，收集tablets的分配情況（4）Master掃描METADATA表得知所有的tablets集合。（4）Master如果發(fā)現(xiàn)有tablet并沒(méi)有分配到tablet server，它會(huì)將之放入未被分配tablets集合，這樣這個(gè)tablet就會(huì)被認(rèn)為是可以被分配的。
就如我上面提到的，HBase實(shí)際上會(huì)等待所有的region server上報(bào)它負(fù)責(zé)的region情況。當(dāng)然，它也會(huì)掃描.META. 表去了解有哪些region以及它們是分配到哪些region server上了。
ZooKeeper僅僅用來(lái)發(fā)布-ROOT- region所在的region server的地址。
Tablet/Region切分
在切分通知被丟失時(shí)（因?yàn)閠ablet server掛了或者master掛了）的情況下，當(dāng)master要求tablet server裝載被切分的那個(gè)tablet時(shí)，master會(huì)發(fā)現(xiàn)新的tablet. Tablet server會(huì)將此次切分通知master，因?yàn)樗鼤?huì)發(fā)現(xiàn)在METADATA中找到的tablet只是master要求它裝載的tablet的一部分。
Master節(jié)點(diǎn)會(huì)單獨(dú)利用.META.表去發(fā)現(xiàn)一個(gè)region去切分，但是切分事件消息被丟失的情況。Master會(huì)按往常一樣掃描.META.去發(fā)現(xiàn)，哪些region并沒(méi)有被分配。一旦發(fā)現(xiàn)沒(méi)有被分配的region，master會(huì)用默認(rèn)的策略將之分配到一個(gè)region server上。
壓緊（Compaction）
隨著寫(xiě)動(dòng)作的執(zhí)行，內(nèi)存表的大小會(huì)不斷增長(zhǎng)。當(dāng)內(nèi)存表的容量到達(dá)一個(gè)臨界點(diǎn)時(shí)，內(nèi)存表將被凍結(jié)，一個(gè)新的內(nèi)存表將會(huì)被創(chuàng)建，被凍結(jié)的內(nèi)存表將被會(huì)轉(zhuǎn)換成SSTable并被寫(xiě)入到GFS中。這種minor compaction操作有2個(gè)目的：1降低tablet server的內(nèi)存用量，2當(dāng)一個(gè)tablet server死而復(fù)生從commit log讀取數(shù)據(jù)時(shí)，減少數(shù)據(jù)總量。當(dāng)壓緊動(dòng)作發(fā)生時(shí)，認(rèn)可繼續(xù)執(zhí)行讀寫(xiě)操作。
HBase也有相應(yīng)的操作，不過(guò)被命名為”flush”。對(duì)應(yīng)BigTable的”minor compaction”，HBase會(huì)把最近生成的很多較小的存儲(chǔ)文件重寫(xiě)為一個(gè)包含較多數(shù)據(jù)的大文件。
…我們將限制此類文件的數(shù)目，方式是定期地在后臺(tái)執(zhí)行合并壓緊操作。合并壓緊操作就是讀取幾個(gè)SSTable和內(nèi)存表的內(nèi)容，然后寫(xiě)到一個(gè)新的SSTable中去。一旦合并壓緊操作完成，老的SSTable和內(nèi)存表就將可被丟棄。
這個(gè)動(dòng)作跟HBase中的”minor compaction”差不多。
讀取所有的SSTable，重新寫(xiě)成一個(gè)SSTable的合并壓緊操作被稱為是major compaction
相應(yīng)的在HBase中，一個(gè)major compaction就是把所有的存儲(chǔ)文件(HFile)重寫(xiě)成一個(gè)新的文件。
文件不可修改
要知道文件一旦被寫(xiě)入將不能修改，BigTable有如下的假定：
唯一可以被修改的數(shù)據(jù)結(jié)構(gòu)就是讀寫(xiě)都可以的內(nèi)存表（memtable）。為了避免同時(shí)讀寫(xiě)內(nèi)存表的沖突，我們?cè)趯?xiě)內(nèi)存表的數(shù)據(jù)行的時(shí)候，會(huì)先復(fù)制一個(gè)副本，這樣讀寫(xiě)就可以并行處理了。
我相信HBase中的做法跟此類似，但不是很確定?？梢源_定是，根據(jù)HDFS的架構(gòu)，文件一旦被寫(xiě)入就是不能被修改的。
我唯一的建議就是你自己去閱讀BigTable的相關(guān)資料以形成自己的見(jiàn)解。這篇帖子的靈感來(lái)自一個(gè)念頭：BigTable究竟實(shí)現(xiàn)了哪些特性，HBase涵蓋了BigTable的哪些特性？寫(xiě)這片帖子的困難毫無(wú)疑問(wèn)是我們對(duì)BigTable的細(xì)節(jié)所知不多。但是關(guān)于它的論文數(shù)量–即便是 2006年的論文列表都給人留下難以磨滅的印象。HBase作為一個(gè)開(kāi)源項(xiàng)目，而且項(xiàng)目的貢獻(xiàn)者是為數(shù)不多的有著全職工作的人，現(xiàn)在雖不能說(shuō)跟 BigTable相提并論，但怎么說(shuō)都我都認(rèn)為現(xiàn)在的成果是一個(gè)巨大的成就。看看0.21和0.22的路線圖，將來(lái)它們之間不大的差距將會(huì)變得更加縮小。
原文鏈接：http://tangay.javaeye.com/blog/724487
【編輯推薦】
- 專家講解 Hadoop:HBASE松散數(shù)據(jù)存儲(chǔ)設(shè)計(jì)
- Hadoop創(chuàng)建Hbase表方法指導(dǎo)
- Hadoop集群與Hadoop性能優(yōu)化
- HadoopHBase實(shí)現(xiàn)配置簡(jiǎn)單的單機(jī)環(huán)境
- 深入剖析Hadoop HBase
