xiaofeng 2011-04-13
| Cassandra | HBase | |
| 一致性 | Quorum NRW策略
通過Gossip協議同步Merkle Tree，維護集羣節點間的數據一致性 |
單節點，無複製，強一致性 |
| 可用性 | 1，基於Consistent Hash相鄰節點複製數據，數據存在於多個節點，無單點故障。
2，某節點宕機，hash到該節點的新數據自動路由到下一節點做 hinted handoff，源節點恢復後，推送回源節點。 3，通過Gossip協議維護集羣所有節點的健康狀態，併發送同步請求，維護數據一致性。 4，SSTable，純文件，單機可靠性一般。 |
1，存在單點故障，Region Server宕機後，短時間內該server維護的region無法訪問，等待failover生效。
2，通過Master維護各Region Server健康狀況和Region分佈。 3，多個Master，Master宕機有zookeeper的paxos投票機制選取下一任Master。Master就算全宕機，也不影響Region讀寫。Master僅充當一個自動運維角色。 4，HDFS爲分佈式存儲引擎，一備三，高可靠，0數據丟失。 5，HDFS的namenode是一個SPOF。 |
| 伸縮性 | 1，Consistent Hash，快速定位數據所在節點。
2，擴容需在Hash Ring上多個節點間調整數據分佈。 |
1，通過Zookeeper定位目標Region Server，最後定位Region。
2，Region Server擴容，通過將自身發佈到Master，Master均勻分佈。 |
| 負載均
衡 |
請求Zookeeper取得整個集羣地址，然後根據Consistent Hash選擇合適的節點。client會緩存集羣地址。 | 請求Zookeeper取讀寫數據路由表定位Region Server，Master會修改這個路由表。Client自身也會緩存一部分路由信息。 |
| 數據差異比較算法 | Merkle Tree , Bloom Filter | Bloom Filter |
| 鎖與事務 | Client Timestap（Dynamo使用vector lock） | Optimistic Concurrency Control |
| 讀寫性能 | 數據讀寫定位非常快。 | 數據讀寫定位可能要通過最多6次的網絡RPC，性能較低。 |
| CAP點評 | 1，弱一致性，數據可能丟失。
2，可用性高。 3，擴容方便。 |
1，強一致性，0數據丟失。
2，可用性低。 3，擴容方便。 |
At 2011.09.20 12:24, schubert zhang said:
作爲大規模存儲系統，Cassandra有幾個致命架構問題，做小規模存儲還行：
1. 用Merkle Tree來比較和保證一致性，基本上會造成的局面是，永元有數據不同步。算一遍Markle Tree要遍歷數據，如果一個節點有幾個TB如何了得。。。
2. 說Cassandra擴容方便的一定會誤導別人。試試就知道了，如果系統負載很大了，加個節點會把整個環破壞，遷移大量數據，進一步把系統拖垮。
。。。。