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

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

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

同為大數據而生

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

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

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

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

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

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

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

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

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

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

相似與差別

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

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

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

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

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

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

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

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

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

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

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

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

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

附圖 HBase主節點在60010端口上托管了一個Web接口。用戶可以瀏覽包括節點執行歷史、由節點管理的表、主節點域中的地區服務器等信息。

棘手之處

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

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

需要說明的是，這里并沒有確定誰是勝出者，誰是失敗者。每個數據庫的支持者都會找到一些證據來證明他們的系統優于對方。通常用戶需要對兩個數據庫進行測試，然后才能確定它們執行目標應用的情況。那么從技術角度出發是否會有更好的辦法呢？

原文鏈接：http://www.36dsj.com/archives/7179

【編輯推薦】