Cassandra VS HBase

	HBase（dfs三副本，syncwal）	Cassandra(N=3,W=2,R=2, batch commitlog)
CAP	CP	CA
数据存储模型	LSM	LSM
数据写入网络开销	Rpc 没有压缩，1份原始数据，占用大约3倍流量	Rpc 有压缩，1份原始数据，占用大概（[三份数据写入流量，一份coordinator流量]4*0.2）倍网络流量（1：5压缩比，三份）
内存使用效率	一份数据对应一份memstore开销 一份数据对应一份cache开销	一份数据对应三份memtable开销 一份数据对应三份cache开销
sql支持	None，有第三方phoenix实现，操作不透明，业务场景简单的场景下推荐使用原生客户端	CQL，primarykey机制稍复杂，支持二级索引，但是性能不高，官方不推荐使用
数据模型	稀疏表	cql，有限兼容sql
Compaction开销	1. 计算量1倍，网络3倍压缩数据量 2. flush文件偏小，一般需要多做一层compaction，最大会有几G级别的hfile文件	计算量三倍，不需要网络开销 flush下来的文件可以较hbase大一个数量级，但是每台机器分摊的数据比较多，最大会有百G级别的sstable文件
水平扩展开销	1. 一次性加入机器，水平扩展完成，需要一定的时间通过compaciton做数据本地化，写性能可以做到瞬间扩展	1. 一台一台加入,数据需要通过Streaming模块从原节点流向新节点，加入比较缓慢
可用性【短时间单机宕机场景】	1. 需要几分钟级别的故障恢复时间，故障恢复期间，宕机服务器上原来提供服务的region暂时不可用	1. 单机宕机，不影响读写，写操作会通过hinted handoff写入其他节点，恢复后再写回；读操作从其他节点获取
数据一致性	1. 保证一致	为了实现一致性，r + w > n.  对读写操作有一定放大。 不满足r+w > n的场景下会有数据不一致的情况发生；数据不一致产生的原因很多样，修复方式也多样，主要有以下三种： 反熵修复 （耗时，永久宕机修复） Hinted handoff (临时宕机修复) Read repair （读修复）
跨机房复制	1. 类似binlog的异步复制	1. 设置多DC，可以通过写入策略调整是多机房同步写入还是类异步写入
写入性能(同步wal模式)	1. 忽略内存操作，写三个dn节点的pipeline，并行写入	（r=2, w=2, n=3） 1. 忽略内存操作，并行写2节点成功即可
读性能（冷数据）	1. 一个节点磁盘io操作 2. 磁盘io数目一般10个以内	（r=2, w=2, n=3） 并行读两节点成功 每个节点操作需要磁盘io数目一般大于10， cassandra单表单节点sstables数目一般多于10个 如果发现不一致，还要异步执行写修复
运维成本	初始搭建成本高 后期运维操作方便	初始搭建成本低 后期运维操作繁琐
TTL	支持ttl自动过期，columnfamily级别	支持默认ttl，也支持写入的时候指定数据的ttl
多版本	支持多版本，columnfamily级别	不支持
前缀扫描	支持任意rowkey位置的scan	支持相同partition key下的clusterkey顺序的scan