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。