Hbase 是Google bigtable的开源实现，它的出现弥补了Hadoop高吞吐、安全可靠但是无法做到随机存取的IO能力。
Cassandra是Amazon的dynamo 开源版本，主要是K-V实现nosql，所以Cassandra在并发的分散查询，效率非常高。
Hbase和Cassandra的比较：
Hbase 因为相近的rowkey都会存放在一个节点的某个region中，所以，如果我们要做scan批量查询，就会落到某个节点上，一批次一次查询完。但是问题是，如果这个scan查询很大，那么就出现这个节点负载过高问题。集中的查询压力很大。get操作实际底层也是scan操作。
Cassandra，因为是k-v存储，往往相近的key，都会分散到不同的节点上。所以，如果我们进行小量的查询，基本都是可以随机分散到不同的节点查询，不会出现Hbase这样的情况，某个节点负载过高。但是问题就是，Cassandra这样的设计，就无法做到大批量类似Hbase的scan操作。
以下是转载：https://yq.aliyun.com/articles/25706
HBase vs Cassandra
| HBase | Cassandra |
语言 | Java | Java |
出发点 | BigTable | BigTable and Dynamo |
License | Apache | Apache |
Protocol | HTTP/REST (also Thrift) | Custom, binary (Thrift) |
数据分布 | 表划分为多个region存在不同region server上 | 改进的一致性哈希（虚拟节点） |
存储目标 | 大文件 | 小文件 |
一致性 | 强一致性 | 最终一致性，Quorum NRW策略 |
架构 | master/slave | p2p |
高可用性 | NameNode是HDFS的单点故障点 | P2P和去中心化设计，不会出现单点故障 |
伸缩性 | Region Server扩容，通过将自身发布到Master，Master均匀分布Region | 扩容需在Hash Ring上多个节点间调整数据分布 |
读写性能 | 数据读写定位可能要通过最多6次的网络RPC，性能较低。 | 数据读写定位非常快 |
数据冲突处理 | 乐观并发控制（optimistic concurrency control） | 向量时钟 |
临时故障处理 | Region Server宕机，重做HLog | 数据回传机制：某节点宕机，hash到该节点的新数据自动路由到下一节点做 hinted handoff，源节点恢复后，推送回源节点。 |
永久故障恢复 | Region Server恢复，master重新给其分配region | Merkle 哈希树，通过Gossip协议同步Merkle Tree，维护集群节点间的数据一致性 |
成员通信及错误检测 | Zookeeper | 基于Gossip |
CAP | 1，强一致性，0数据丢失。2，可用性低。3，扩容方便。 | 1，弱一致性，数据可能丢失。2，可用性高。3，扩容方便。 |
facebook为什么放弃Cassandra？
参考：http://www.zhihu.com/question/19593207:
Facebook开发Cassandra初衷是用于Inbox Search，但是后来的Message System则使用了HBase，Facebook对此给出的解释是Cassandra的
最终一致性模型不适合Message System，HBase具有更简单的一致性模型，当然还有其他的原因。HBase更加的成熟，成功的案例也比较多等等。Twitter和Digg都曾经很高调的选用Cassandra，但是最后也都放弃了，当然Twitter还有部分项目也还在使用Cassandra，但是主要的Tweet已经不是了。
下文转自：http://blog.jobbole.com/91923/
选择倾向
“任何像样规模的企业都会使用各种不同类型的数据存储技术，为应对各种不同类型的数据。”Martin Fowler认为，现实的情况是你没有足够的精力去学习更多的存储技术。
幸运的是，选择越来越容易，因为市场主要围绕在三个NoSQL数据库上：MongoDB，Cassandra（主要由DataStax开发的，诞生于Facebook），和HBase的（和Hadoop紧密关联在一起，也被相同社区开发出来）。
补充一点，我故意排除Redis。相对于大数据存储，它主要用于高速内存缓存数据应用。
从LinkedIn的451研究数据显示，市场上最具引力的是MongoDB、Cassandra和HBase：
这是LinkedIn的个人资料数据。我们认为是数据存储引擎，它通过收集工作、搜索等数据，来了解数据库的热门程度。而Oracle，SQL Server和MySQL的占据了统治地位，MongoDB的（第5位），Cassandra（第9位），和HBase的（第15位）。
为了更好解释为什么这三个数据库技术的如此耀眼，我问的每一个具有代表性的人，以确定它们成功关键因素：Kelly Stirman，MongoDB的产品总监;Patrick McFadin，DataStax的Cassandra首席布道师;和Justin Kestelyn，Cloudera高级总监。
但首先，我们需要了解为什么使用NoSQL的原因。
世界由非结构化数据构成
我们生活在一个数据越来越丰富的世界里，但是这些数据都不能整齐的展示在一个RDBMS（Relational Database Management System，关系数据库管理系）的行和列中。移动、社交和云计算催生了庞大的海量的数据。根据估计，世界上90％的数据是在过去两年中被创造，以及80％的商业数据是非结构化的。更重要的是，非结构化数据的增长速度是结构化数据的两倍。
随着世界的变化，数据管理要求开始超越传统的关系型数据库的有效范围。最早关注这个问题解决方案的机构，包括Web技术的先驱、政府机构、从事信息技术服务的公司。
现在越来越多，形形色色的公司都希望利用类似的NoSQL和Hadoop作为替代品：通过NoSQL来建立业务运营应用，以及Hadoop来创建数据挖掘的应用程序，来帮助公司对商业数据提供有力的研究。
MongoDB：源于开发人员，为开发人员服务
在众多NoSQL的方案中，MongoDB的Stirman指出，MongoDB的瞄准了适合各种应用的平衡的方法。它的功能接近于传统的关系型数据库，MongoDB的用户不仅可以利用其横向扩展机器的云基础架构的优势，并且，因为它能够轻松定义各种灵活的数据模型，所以可以支持不同类型的数据集存储。
MongoDB通常是开发人员第一个尝试的NoSQL数据库，因为它是很容易学习。Will Shulman，MongoLab（一个MongoDB服务提供商）的CEO，是这样说的：
MongoDB中的成功在很大程度上是因为它数据结构存储的创新，让我们更容易和更具表现力地定义我们应用程序中的数据模型。在通常开发和应用场景中，和原有数据库具有相同的基本数据模型是有极大好处的，因为它简化了应用程序开发的任务，另一方面，消除了复杂的数据格式代码转换层。
当然，像任何其他技术一样，MongoDB中都有其长处和短处。 MongoDB是专门为OLTP（On-Line Transaction Processing，联机事务处理系统）模式。如果您需要复杂的事务处理，它不是一个好的选择。然而，MongoDB的简单性使其成为一个优秀的存储。
（注：MongoDB以文档的形式存储数据，不支持事务和表连接。因此查询的编写、理解和优化都容易得多。）
Cassandra：规模化安全运行
三种数据库中，至少两种数据库具有简单特性：开发简单，操作简便。而MongoDB赢得人心的原因是简单的开发应用，Cassandra赢得人心是因为易于管理的规模。
DataStax的McFadin告诉我，用户往往倾向于使用Cassandra ，是因为特别在大规模集群下，增强一个关系型数据的性能、可靠性是非常困难的。一位前甲骨文DBA，McFadin是兴高采烈地发现，“复制和可扩放性是基础”，Cassandra 特点是从一开始设计就解决这个问题。
在RDBMS中的世界，数据库功能，拓展和复制对很多开发者用户来说，是一个难题。这个问题在过往的企业规模小的时候，不是一个大问题。而在今天，它很迅速地成为大问题。
我从McFadin和其他人那里获知，Cassandra在机器拓展部署上，表现特别出色。Cassandra自带的备份机制，保证各个数据中心的数据安全。至于增加容量到集群，“你只需启动一台新机器，并告诉Cassandra那里的新节点，”McFadin说，“然后，它完成其他剩下的事情。”
优秀的可拓展性，加上出色的写入和可观的查询性能，加起来成为Cassandra高性能的核心。
NoSQL的一篇文章认为Cassandra在集群规模管理方面非常出色，但它需要一个博士学位才能上手。事实并非如此，McFadin坚持认为：
在复制、读取和写入是故意简单。你可以在几个小时内学会Cassandra的核心功能。在部署这项新技术的时候，为给开发者带来很多的信心，因为比较少引入“黑盒子”内的技术细节和复杂的故障模式原理。
这意味着主要的开发成本，是对Cassandra数据模型的理解，以及如何结合您的应用程序。鉴于Cassandra的CQL查询语言（类似于SQL，实际上不是SQL），McFadin说，学习这个也不困难。
更重要的是，他告诉我，“Cassandra回报给你的是，在一个数据库中：没有戏剧性的场景（故障）出现。这就是用户喜欢使用Cassandra的原因。”
HBase：Hadoop的知心伙伴
HBase，像Cassandra一样是个通过key-value面向列存储的服务。因为它和Hadoop有着“共同血统”，被广泛使用。事实上，正如Cloudera的Kestelyn所说的那样，“HBase提供了一个基于记录的存储层，能够快速随机读取和写入数据，正好弥补了Hadoop的缺陷，Hadoop侧重系统吞吐量，而牺牲I / O读取效率为代价。”
Kestelyn接着说：
更改有效录入到内存中，以达到最大的访问量，同时将数据保存到HDFS。这种设计使基于Hadoop的EDH（enterprise data hub，企业数据中心）服务，能够实时完成随机读写存储数据，但仍拥有HDFS的高容错性和耐用性。
Hadoop的亲和力，不是HBase数据库中的人气排名不断上升的唯一原因。类似Cassandra，HBase是Google的Bigtable的开源实现转化成的数据库，天然被设计为高可扩展性。
Hbase可以利用任何数量服务器的磁盘、内存和CPU资源，同时拥有极佳的扩展功能，如自动分片。当系统负载和性能要求不断增加，HBase的可通过简单增加服务器节点的方式无限拓展。 HBase从底层设计上保证，在确保数据一致性的同时，提供最佳性能。
但规模不是它的唯一用途。Kestelyn指出，“由于它与Hadoop的生态系统紧密集成，对于用户和应用程序来说，数据是容易获取的，可以通过SQL的方式查询（使用Cloudera的Impala，Phoenix，或Hive），甚至自由文本搜索（使用Cloudera Search）。“因此，HBase为开发人员提供了一种方法，利用现有通用的SQL语言，来建立在一个更成熟的分布式数据库。
每种数据库技术都有自己的长处和不足，但这里评论的三种数据库，在大数据技术领域，占据了重要的位置。虽然未来可能还有一种全新的NoSQL数据库技术会挑战它们前三的位置，但目前的现实是，许多开发人员以及一批强大的成熟企业已经做出了它们的选择：MongoDB、Cassandra 和 HBase。
