眾多基于Bigtable技術(shù)的開源項(xiàng)目正在通過(guò)不同的方式實(shí)現(xiàn)高擴(kuò)展性、高靈活性、分布式及寬列數(shù)據(jù)存儲(chǔ)等功能，Cassandra和HBase就是其中的代表。

　　在大數(shù)據(jù)[注]這一全新的領(lǐng)域里，Bigtable數(shù)據(jù)庫(kù)技術(shù)非常值得我們關(guān)注，因?yàn)檫@一技術(shù)是由谷歌的工程發(fā)明的，而谷歌是一家公認(rèn)的非常擅長(zhǎng)管理海量數(shù)據(jù)的公司。如果你對(duì)此非常了解，那么你一家知道也熟悉Cassandra和HBase這兩個(gè)Apache數(shù)據(jù)庫(kù)項(xiàng)目。

　　谷歌在2006年的一份研究報(bào)告中首次對(duì)Bigtable進(jìn)行了闡述。有意思的是，這份報(bào)告當(dāng)時(shí)并沒有將Bigtable作為數(shù)據(jù)庫(kù)技術(shù)，而是將其作為一種“稀疏的分布式多維度”映射技術(shù)以存儲(chǔ)拍字節(jié)級(jí)數(shù)據(jù)，并在商用硬件上運(yùn)行它們。行先是以一種非常獨(dú)特的方式被索引，隨后Bigtable利用行鍵對(duì)數(shù)據(jù)進(jìn)行分割，將它們分布到集群中。列可以被迅速地定義在行中，讓Bigtable適用于大多數(shù)的非模式環(huán)境。

　　Cassandra和HBase都在很大程度上借鑒了早期Bigtable的定義。實(shí)際上，Cassandra起源于Bigtable和亞馬遜的Dynamo技術(shù)，HBase將自身定位為“開源Bigtable工具”。就其本身而論，這兩個(gè)項(xiàng)目既有許多相同的特點(diǎn)，同時(shí)又有許多重大區(qū)別。

　　同為大數(shù)據(jù)而生

　　Cassandra與HBase都是NoSQL數(shù)據(jù)庫(kù)?？傮w上看，這意味著用戶無(wú)法使用SQL數(shù)據(jù)庫(kù)。不過(guò)，Cassandra使用的是CQL（Cassandra 查詢語(yǔ)言），其語(yǔ)法有明顯模仿SQL的痕跡。

　　兩者都被設(shè)計(jì)用于管理非常大的數(shù)據(jù)集。HBase文件聲稱一個(gè)HBase數(shù)據(jù)庫(kù)可以擁有數(shù)億個(gè)，甚至是數(shù)十億個(gè)行。此外，用戶還被建議繼續(xù)使用關(guān)系型數(shù)據(jù)庫(kù)。

　　兩者都是分布式數(shù)據(jù)庫(kù)，不僅僅是在數(shù)據(jù)的存儲(chǔ)方式上，在數(shù)據(jù)訪問(wèn)方式上亦是如此?？蛻舳丝梢耘c集群中的任意節(jié)點(diǎn)相連，并訪問(wèn)任意的數(shù)據(jù)。

　　兩者都宣稱擁有近似于線型的擴(kuò)展能力。想要管理兩倍規(guī)模的數(shù)據(jù)嗎？用戶只需將集群中的節(jié)點(diǎn)擴(kuò)展兩倍即可。

　　兩者都是通過(guò)復(fù)制來(lái)防止集群節(jié)點(diǎn)故障而導(dǎo)致出現(xiàn)數(shù)據(jù)損失。被寫入數(shù)據(jù)庫(kù)的行主要由單個(gè)集群節(jié)點(diǎn)負(fù)責(zé)（行至節(jié)點(diǎn)映射取決于用戶所使用的分區(qū)模式）。數(shù)據(jù)會(huì)被鏡像到稱之為冗余節(jié)點(diǎn)的其他集群成員當(dāng)中（用戶可配置的復(fù)制因子會(huì)顯示數(shù)量）。如果主要節(jié)點(diǎn)出現(xiàn)了故障，那么數(shù)據(jù)仍然可以從另外的冗余節(jié)點(diǎn)中被讀取。

　　兩者都被稱之為列式數(shù)據(jù)庫(kù)。由于它們的名字聽起來(lái)像是關(guān)系型數(shù)據(jù)庫(kù)，因此用戶在接觸中需要在思想上進(jìn)行調(diào)整，這導(dǎo)致用戶對(duì)它們的認(rèn)知會(huì)出現(xiàn)混淆。最容易出現(xiàn)混淆的地方是，數(shù)據(jù)在表面上最初是由行進(jìn)行排列的，表的主要鍵是行鍵。但是與關(guān)系型數(shù)據(jù)庫(kù)不同，在列式數(shù)據(jù)庫(kù)中，沒兩個(gè)行需要相同的列。正如上面所說(shuō)的那樣，在表被創(chuàng)建后，用戶能夠快速在行中加入列。實(shí)際上，你能夠向一行中增加許多列。雖然最高上限值難以被準(zhǔn)確地計(jì)算出來(lái)，但是用戶幾乎不可能達(dá)到這樣的上限，即便他們加入大量列的情況下也是如此。

　　除了這些源于Bigtable定義的特點(diǎn)外，Cassandra和HBase還有一些其他的相似之處。

　　首先，兩者都使用相似的寫入路徑，即首先將寫入操作記錄在日志文件中以確保持久性。即便出現(xiàn)寫入失敗的提示，保存在日志當(dāng)中的操作記錄可以被重新開始。隨后，數(shù)據(jù)被寫入內(nèi)存緩存中。最后，數(shù)據(jù)被通過(guò)大量的一系列寫入操作寫入到磁盤中（實(shí)際上是將內(nèi)存緩存的副本拷貝至磁盤中）。Cassandra和HBase所使用的內(nèi)存和磁盤數(shù)據(jù)結(jié)構(gòu)在某種程度上都是日志結(jié)構(gòu)的合并樹。Cassandra的磁盤組件是SSTable，HBase中磁盤組件的是HFile。

　　兩者提供JRuby語(yǔ)言的命令行外殼。兩者都通過(guò)Java語(yǔ)言被大量寫入，這是訪問(wèn)它們的主要編程語(yǔ)言，盡管在許多其他的編程語(yǔ)言中都有適合兩者的客戶端包。

　　當(dāng)然，Cassandra 和 HBase都是Apache軟件基金會(huì)管理的開源項(xiàng)目，兩者都可以通過(guò)Apache License version 2.0許可證免費(fèi)獲取。

　　相似與差別

　　盡管兩者有著眾多相似之處，但是它們之間還是存在著許多重大的區(qū)別。

　　盡管Cassandra和HBase中的節(jié)點(diǎn)都是對(duì)稱的，這意味著客戶端能夠與集群中的任意節(jié)點(diǎn)相連，但是這種對(duì)稱是不完全的。Cassandra需要用戶將一些節(jié)點(diǎn)作為種子節(jié)點(diǎn)，讓它們?cè)诩洪g通信中扮演集流點(diǎn)的角色。在HBase中，用戶必須讓一些節(jié)點(diǎn)充當(dāng)主節(jié)點(diǎn)，它們的功能是監(jiān)控和協(xié)調(diào)地區(qū)服務(wù)器的行動(dòng)。為了確保高可用性，Cassandra采取方式是允許在集群中設(shè)置多個(gè)種子節(jié)點(diǎn)；HBase則是利用備用主節(jié)點(diǎn)，如果當(dāng)前的主節(jié)點(diǎn)發(fā)生故障，那么備份主節(jié)點(diǎn)將成為新的主節(jié)點(diǎn)。

　　Cassandra在節(jié)點(diǎn)間通信中使用的是Gossip協(xié)議。目前Gossip服務(wù)已經(jīng)與Cassandra軟件整合到了一起。HBase則依托完全獨(dú)立的分布式應(yīng)用Zookeeper來(lái)處理相應(yīng)的任務(wù)。盡管HBase與Zookeeper一同出貨，但是用戶常常會(huì)使用預(yù)置在HBase數(shù)據(jù)庫(kù)中的Zookeeper。

　　雖然Cassandra和HBase都不支持實(shí)時(shí)交易控制，但是兩者都提供了一定程度的一致性控制。HBase向用戶提供記錄級(jí)（也就是行級(jí)）的一致性。實(shí)際上，HBase在每行都支持ACID級(jí)語(yǔ)義。用戶可以在HBase中鎖定一行，但是這種行為并不被鼓勵(lì)，因?yàn)檫@不僅影響到并發(fā)性，同時(shí)行鎖定還會(huì)導(dǎo)致無(wú)法進(jìn)行區(qū)域分割操作。此外，HBase還可以執(zhí)行“檢查與寫入”操作，該操作在單個(gè)數(shù)據(jù)元上提供了“讀取-修改-寫入”的語(yǔ)義。

　　Cassandra免費(fèi)的DataStax社區(qū)版包含有一個(gè)DataStax 操作中心。該中心提供了集群監(jiān)控與管理功能，它可以檢測(cè)數(shù)據(jù)庫(kù)模式，提示鍵空間是否能夠被編輯，以及是否可以增加或刪除列族。

　　盡管Cassandra被描述為擁有“終極”一致性，但是讀取和寫入一致性可以在級(jí)別和區(qū)間方面進(jìn)行調(diào)整。也就是說(shuō)，你不僅可以配置必須成功完成操作的冗余節(jié)點(diǎn)數(shù)量，還可以設(shè)置參與的冗余節(jié)點(diǎn)是否跨數(shù)據(jù)中心。

　　此外，Cassandra還在其計(jì)算機(jī)指令系統(tǒng)中增加了一些輕量級(jí)的交易。Cassandra的輕量級(jí)交易采用的是“比較與集合”機(jī)制，相當(dāng)于HBase的“檢查與寫入”功能。不過(guò)，對(duì)于HBase的“讀取-修改-寫入”操作功能，Cassandra則缺乏相對(duì)應(yīng)的功能。最終，Cassandra的2.0版本增加了單獨(dú)的行級(jí)寫入功能。如果一個(gè)客戶端在一行中更新了多個(gè)列，那么其他的客戶端將會(huì)看到所有未更新的部分，或所有更新的部分。

　　在Cassandra和HBase當(dāng)中，主索引是行鍵，但是數(shù)據(jù)被存儲(chǔ)在磁盤中，這導(dǎo)致列族成員相互間非常接近。因此仔細(xì)規(guī)劃列族組織非常重要。為了保持高查詢性能，有著相同訪問(wèn)模式的列應(yīng)該被放在在相同的列族當(dāng)中。Cassandra允許用戶創(chuàng)建關(guān)于列值的額外次索引。這一舉措提升了對(duì)那些值具有高重復(fù)性的列（例如存儲(chǔ)客戶電子郵件地址中國(guó)家地區(qū)的列）的數(shù)據(jù)訪問(wèn)。HBase雖然缺乏對(duì)次索引的內(nèi)置支持，但是它們有一些能夠提供次索引功能的機(jī)制。這些都在HBase的在線參考指南和HBase社區(qū)博客中被提及。

　　如前所述，兩個(gè)數(shù)據(jù)庫(kù)都有發(fā)布數(shù)據(jù)操作命令的命令行外殼。由于HBase和Cassandra的殼都是以JRuby殼為基礎(chǔ)，因此用戶可以編寫一些腳本，讓這些腳本能夠調(diào)用JRuby殼的所有資源與數(shù)據(jù)庫(kù)所提供的特定API進(jìn)行交互。此外，Cassandra還定義了模仿自SQL的CQL。與HBase所使用的查詢語(yǔ)言相比，CQL的功能更加豐富，并且可以在Cassandra的殼內(nèi)直接執(zhí)行。

　　盡管Cassandra仍然支持Thrift API，但實(shí)際上Cassandra一直在推動(dòng)讓CQL成為數(shù)據(jù)庫(kù)的主要編輯接口。Cassandra的文檔列入了一些針對(duì)Java、C#和Python等使用CQL version 3的驅(qū)動(dòng)。最終，Cassandra將可獲得一個(gè)JDBC驅(qū)動(dòng)。該驅(qū)動(dòng)用CQL替代了SQL，將CQL作為數(shù)據(jù)定義與數(shù)據(jù)管理語(yǔ)言。

　　HBase也支持Thrift接口和RESTful Web服務(wù)接口，不過(guò)HBase原生的Java API向編程人員提供了豐富的功能（如附圖所示）。雖然HBase的數(shù)據(jù)操作命令沒有CQL豐富，但是HBase擁有一個(gè)“篩選”功能，該功能可以在會(huì)話的服務(wù)器端執(zhí)行，大幅提升了掃描（搜索）的吞吐量。

　　HBase還引入了“協(xié)處理器”（coprocessors）這一概念，允許在HBase進(jìn)程中執(zhí)行用戶代碼。這基本上與關(guān)系型數(shù)據(jù)庫(kù)中的觸發(fā)和預(yù)存進(jìn)程相同。目前，Cassandra還沒有類似HBase協(xié)處理器的功能。

　　Cassandra的文檔較HBase的更加醒目，并且擁有更加扁平化的學(xué)習(xí)曲線。設(shè)置一個(gè)開發(fā)用的Cassandra集群比設(shè)置HBase集群要更加簡(jiǎn)單。當(dāng)然，這僅對(duì)于開發(fā)與測(cè)試目的來(lái)說(shuō)非常重要。

　　附圖 HBase主節(jié)點(diǎn)在60010端口上托管了一個(gè)Web接口。用戶可以瀏覽包括節(jié)點(diǎn)執(zhí)行歷史、由節(jié)點(diǎn)管理的表、主節(jié)點(diǎn)域中的地區(qū)服務(wù)器等信息。

　　棘手之處

　　在必須為特定應(yīng)用調(diào)整集群時(shí)，用戶需要做一些工作。在指定數(shù)據(jù)集大小、創(chuàng)建與管理多節(jié)點(diǎn)集群（通常會(huì)跨多個(gè)數(shù)據(jù)中心）的復(fù)雜度后，調(diào)整工作將變得非常棘手。用戶需要深刻理解集群的內(nèi)存緩存、磁盤存儲(chǔ)和節(jié)點(diǎn)間通信之間相互影響，仔細(xì)監(jiān)控集群的活動(dòng)。

　　HBase對(duì)Zookeeper的依賴會(huì)帶來(lái)一些額外的故障點(diǎn)。雖然Cassandra避開了這一問(wèn)題，但這并不意味著Cassandra集群的調(diào)整難度會(huì)大幅下降。我們對(duì)兩個(gè)數(shù)據(jù)庫(kù)的集群調(diào)整難點(diǎn)進(jìn)行了對(duì)比（如附表所示）。

　　需要說(shuō)明的是，這里并沒有確定誰(shuí)是勝出者，誰(shuí)是失敗者。每個(gè)數(shù)據(jù)庫(kù)的支持者都會(huì)找到一些證據(jù)來(lái)證明他們的系統(tǒng)優(yōu)于對(duì)方。通常用戶需要對(duì)兩個(gè)數(shù)據(jù)庫(kù)進(jìn)行測(cè)試，然后才能確定它們執(zhí)行目標(biāo)應(yīng)用的情況。那么從技術(shù)角度出發(fā)是否會(huì)有更好的辦法呢？