hbase与cassandra比较

由于HBase和Cassandra的数据模型比较接近，所以这里就不再比较两者之间数据模型的异同了。接下来主要比较双方在数据一致性、多拷贝复制的特性。

HBase

HBase保证写入的一致性。当一份数据被要求复制N份的时候，只有N份数据都被真正复制到N台服务器上之后，客户端才会成功返回。如果在复制过程中出现失败，所有的复制都将失败。连接上任何一台服务器的客户端都无法看到被复制的数据。HBase提供行锁，但是不提供多行锁和事务。HBase基于HDFS，因此数据的多份复制功能和可靠性将由HDFS提供。HBase和MapReduce天然集成。

Cassandra

写入的时候，有多种模式可以选择。当一份数据模式被要求复制N份的时候，可以立即返回，可以成功复制到一个服务器之后返回，可以等到全部复制到N份服务器之后返回，还可以设定一个复制到quorum份服务器之后返回。Quorum后面会有具体解释。复制不会失败。最终所有节点数据都将被写入。而在未被完全写入的时间间隙，连接到不同服务器的客户端有可能读到不同的数据。在集群里面，所有的服务器都是等价的。不存在任何一个单点故障。节点和节点之间通过Gossip协议互相通信。写入顺序按照timestamp排序，不提供行锁。新版本的Cassandra已经集成了MapReduce了。

相对于配置Cassandra，配置HBase是一个艰辛、复杂充满陷阱的工作。Facebook关于为何采取HBase，里面有一句，大意是，Facebook长期以来一直关注HBase的开发并且有一只专门的经验丰富的HBase维护的team来负责HBase的安装和维护。可以想象，Facebook内部关于使用HBase和Cassandra有过激烈的斗争，最终人数更多的HBase team占据了上风。对于大公司来说，养一只相对庞大的类似DBA的team来维护HBase不算什么大的开销，但是对于小公司，这实在不是一个可以负担的起的开销。

另外HBase在高可靠性上有一个很大的缺陷，就是HBase依赖HDFS。HDFS是Google File System的复制品，NameNode是HDFS的单点故障点。而到目前为止，HDFS还没有加入NameNode的自我恢复功能。不过我相信，Facebook在内部一定有恢复NameNode的手段，只是没有开源出来而已。

相反，Cassandra的P2P和去中心化设计，没有可能出现单点故障。从设计上来看，Cassandra比HBase更加可靠。

关于数据一致性，实际上，Cassandra也可以以牺牲响应时间的代价来获得和HBase一样的一致性。而且，通过对Quorum的合适的设置，可以在响应时间和数据一致性得到一个很好的折衷值。

Cassandra优缺点

主要表现在：

配置简单，不需要多模块协同操作。功能灵活性强，数据一致性和性能之间，可以根据应用不同而做不同的设置。 可靠性更强，没有单点故障。

尽管如此，Cassandra就没有弱点吗？当然不是，Cassandra有一个致命的弱点。

这就是存储大文件。虽然说，Cassandra的设计初衷就不是存储大文件，但是Amazon的S3实际上就是基于Dynamo构建的，总是会让人想入非非地让Cassandra去存储超大文件。而和Cassandra不同，HBase基于HDFS，HDFS的设计初衷就是存储超大规模文件并且提供最大吞吐量和最可靠的可访问性。因此，从这一点来说，Cassandra由于背后不是一个类似HDFS的超大文件存储的文件系统，对于存储那种巨大的（几百T甚至P）的超大文件目前是无能为力的。而且就算由Client手工去分割，这实际上是非常不明智和消耗Client CPU的工作的。

因此，如果我们要构建一个类似Google的搜索引擎，最少，HDFS是我们所必不可少的。虽然目前HDFS的NameNode还是一个单点故障点，但是相应的Hack可以让NameNode变得更皮实。基于HDFS的HBase相应地，也更适合做搜索引擎的背后倒排索引数据库。事实上，Lucene和HBase的结合，远比Lucene结合Cassandra的项目Lucandra要顺畅和高效的多。（Lucandra要求Cassandra使用OrderPreservingPartitioner,这将可能导致Key的分布不均匀，而无法做负载均衡，产生访问热点机器）。

所以我的结论是，在这个需求多样化的年代，没有赢者通吃的事情。而且我也越来越不相信在工程界存在一劳永逸和一成不变的解决方案。当你仅仅是存储海量增长的消息数据，存储海量增长的图片，小视频的时候，你要求数据不能丢失，你要求人工维护尽可能少，你要求能迅速通过添加机器扩充存储，那么毫无疑问，Cassandra现在是占据上风的。

但是如果你希望构建一个超大规模的搜索引擎，产生超大规模的倒排索引文件（当然是逻辑上的文件，真实文件实际上被切分存储于不同的节点上），那么目前HDFS+HBase是你的首选。