Cassandra與HBase的大資料對決 誰是勝者？

在大資料這一全新的領域裡，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集群的調整難度會大幅下降。 我們對兩個資料庫的集群調整難點進行了對比（如附表所示）。

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