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

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

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

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

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

Cassandra與HBase都是NoSQL數(shù)據(jù)庫。總體上看，這意味著用戶無法使用SQL數(shù)據(jù)庫。不過，Cassandra使用的是CQL（Cassandra 查詢語言），其語法有明顯模仿SQL的痕跡。

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

兩者都是分布式數(shù)據(jù)庫，不僅僅是在數(shù)據(jù)的存儲方式上，在數(shù)據(jù)訪問方式上亦是如此。客戶端可以與集群中的任意節(jié)點相連，并訪問任意的數(shù)據(jù)。

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

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

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

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

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

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

當然，Cassandra 和 HBase都是Apache軟件基金會管理的開源項目，兩者都可以通過Apache License version 2.0許可證免費獲取。

相似與差別

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

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

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

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

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

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

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

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

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

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

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

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

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

棘手之處

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

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

需要說明的是，這里并沒有確定誰是勝出者，誰是失敗者。每個數(shù)據(jù)庫的支持者都會找到一些證據(jù)來證明他們的系統(tǒng)優(yōu)于對方。通常用戶需要對兩個數(shù)據(jù)庫進行測試，然后才能確定它們執(zhí)行目標應(yīng)用的情況。