從底層看 HBase 和 Cassandra 的不同

資料庫可以分成關聯式資料庫和非關聯式(NoSQL)資料庫兩種，在非關聯式資料庫領域中，比較知名的 NoSQL 開源專案像是 HBase 和 Cassandra，兩者都是從 Google Bigtable 發展而來，但 Cassandra 有參考 Dynamo 的設計架構。

今天這篇文章，會從以下兩點探討 HBase 和 Cassandra 底層實現邏輯的不同：

系統架構
寫入行為

系統架構

在系統架構上，HBase 是 master/slave 模式，Cassandra 則沒有 master 的概念，每個節點承擔的角色都是相同的。

在 HBase 中，節點可以分成 HMaster 和 HRegionServer。HMaster 負責管理、紀錄整個集群的狀態，當 client 需要讀寫資料時，需要和 HMaster 溝通，然後再去找 HRegionServer 進行讀寫動作。

在 Cassandra 中，每個節點都是相等的。那麼在查找資料時，怎麼知道資料在哪個節點手上呢？這邊就要用到 token 的概念。token 是經過 hash function 計算過的 key，Cassandra 規定了 token 的範圍，每個節點負責一部份。舉例來說，假設有 3 個節點，token 範圍則是 0-100，則 3 個節點各負責 0-33, 34-66, 67-100 的範圍，因此得出了 token 後，就知道要去哪個節點上拿資料。Cassandra 的每個節點上都有關於這個叢集的狀態表，紀錄每個節點負責哪段 token，因此不需要 master。當有新節點加入時，新節點會詢問 seed node，seed node 會分配一段 token 給新節點，然後把這個資訊 broadcast 給所有節點。

這兩種系統在架構上的差異，說明了他們在 CAP 理論中的取捨：HBase 重視 Consistency，而 Cassandra 則是強調 Availability。系統設計差異也影響了部署的方便性，HBase 的部署相對複雜，除了要在不同機器上設定是 master 或 region server，還有串接 HDFS、Zookeeper 等東西。Cassandra 的部署容易很多，單台機器就可啟動，後續的管理維護也更方便。

另一個影響可能是效能瓶頸。對於 master/slave 架構的系統來說，由於每次讀寫過程 client 都要和 master 溝通，當讀寫需求大於 master 的吞吐量，可能就會有延遲問題。而 Cassandra 沒有 master 這個角色，相對來說比較不容易出現這個問題。

寫入行為

在寫入過程中，HBase 只會寫入一次檔案，不考慮 replication。replication 會交由 HDFS 去進行備份，HBase 是不會受到影響的。

Cassandra 則會在寫入同時一起考慮 replication 這件事。寫入時為了避免數據儀式，通常會先寫 WAL(write-ahead-log)，完成後寫 Memtable，最後再將資料存到 SSTable 裡面。Cassandra 其實在不同節點上做重複的動作，如果 replica=3，三個節點都要進行一次 WAL、Memtable、SSTable 的流程；但 HBase 只需要在第一個節點進行這個動作，完成後再直接把檔案複製到其他節點上。因此就寫入成本來看，Cassandra 的成本是比較高的。