2014-04-10 11:01:42
来 源
国外媒体
大数据
Cassandra和HBase是众多基于bigtable技术开源项目中的代表。都是NoSQL数据库,都被设计用于管理非常大的数据集,两者有着众多相似之处,但还是存在着许多重大的区别。

众多基于Bigtable技术的开源项目正在通过不同的方式实现高扩展性、高灵活性、分布式及宽列数据存储等功能,Cassandra和HBase就是其中的代表。

在大数据[注]这一全新的领域里,Bigtable数据库技术非常值得我们关注,因为这一技术是由谷歌的工程发明的,而谷歌是一家公认的非常擅长管理海量数据的公司。如果你对此非常了解,那么你一家知道也熟悉Cassandra和HBase这两个Apache数据库项目。

谷歌在2006年的一份研究报告中首次对Bigtable进行了阐述。有意思的是,这份报告当时并没有将Bigtable作为数据库技术,而是将其作为一种“稀疏的分布式多维度”映射技术以存储拍字节级数据,并在商用硬件上运行它们。行先是以一种非常独特的方式被索引,随后Bigtable利用行键对数据进行分割,将它们分布到集群中。列可以被迅速地定义在行中,让Bigtable适用于大多数的非模式环境。

Cassandra和HBase都在很大程度上借鉴了早期Bigtable的定义。实际上,Cassandra起源于Bigtable和亚马逊的Dynamo技术,HBase将自身定位为“开源Bigtable工具”。就其本身而论,这两个项目既有许多相同的特点,同时又有许多重大区别。

同为大数据而生

Cassandra与HBase都是NoSQL数据库。总体上看,这意味着用户无法使用SQL数据库。不过,Cassandra使用的是CQL(Cassandra 查询语言),其语法有明显模仿SQL的痕迹。

两者都被设计用于管理非常大的数据集。HBase文件声称一个HBase数据库可以拥有数亿个,甚至是数十亿个行。此外,用户还被建议继续使用关系型数据库。

两者都是分布式数据库,不仅仅是在数据的存储方式上,在数据访问方式上亦是如此。客户端可以与集群中的任意节点相连,并访问任意的数据。

两者都宣称拥有近似于线型的扩展能力。想要管理两倍规模的数据吗?用户只需将集群中的节点扩展两倍即可。

两者都是通过复制来防止集群节点故障而导致出现数据损失。被写入数据库的行主要由单个集群节点负责(行至节点映射取决于用户所使用的分区模式)。数据会被镜像到称之为冗余节点的其他集群成员当中(用户可配置的复制因子会显示数量)。如果主要节点出现了故障,那么数据仍然可以从另外的冗余节点中被读取。

两者都被称之为列式数据库。由于它们的名字听起来像是关系型数据库,因此用户在接触中需要在思想上进行调整,这导致用户对它们的认知会出现混淆。最容易出现混淆的地方是,数据在表面上最初是由行进行排列的,表的主要键是行键。但是与关系型数据库不同,在列式数据库中,没两个行需要相同的列。正如上面所说的那样,在表被创建后,用户能够快速在行中加入列。实际上,你能够向一行中增加许多列。虽然最高上限值难以被准确地计算出来,但是用户几乎不可能达到这样的上限,即便他们加入大量列的情况下也是如此。

除了这些源于Bigtable定义的特点外,Cassandra和HBase还有一些其他的相似之处。

首先,两者都使用相似的写入路径,即首先将写入操作记录在日志文件中以确保持久性。即便出现写入失败的提示,保存在日志当中的操作记录可以被重新开始。随后,数据被写入内存缓存中。最后,数据被通过大量的一系列写入操作写入到磁盘中(实际上是将内存缓存的副本拷贝至磁盘中)。Cassandra和HBase所使用的内存和磁盘数据结构在某种程度上都是日志结构的合并树。Cassandra的磁盘组件是SSTable,HBase中磁盘组件的是HFile。

两者提供JRuby语言的命令行外壳。两者都通过Java语言被大量写入,这是访问它们的主要编程语言,尽管在许多其他的编程语言中都有适合两者的客户端包。

当然,Cassandra 和 HBase都是Apache软件基金会管理的开源项目,两者都可以通过Apache License version 2.0许可证免费获取。

Cassandra 和 HBase相似与差别

尽管两者有着众多相似之处,但是它们之间还是存在着许多重大的区别。

尽管Cassandra和HBase中的节点都是对称的,这意味着客户端能够与集群中的任意节点相连,但是这种对称是不完全的。Cassandra需要用户将一些节点作为种子节点,让它们在集群间通信中扮演集流点的角色。在HBase中,用户必须让一些节点充当主节点,它们的功能是监控和协调地区服务器的行动。为了确保高可用性,Cassandra采取方式是允许在集群中设置多个种子节点;HBase则是利用备用主节点,如果当前的主节点发生故障,那么备份主节点将成为新的主节点。

Cassandra在节点间通信中使用的是Gossip协议。目前Gossip服务已经与Cassandra软件整合到了一起。HBase则依托完全独立的分布式应用Zookeeper来处理相应的任务。尽管HBase与Zookeeper一同出货,但是用户常常会使用预置在HBase数据库中的Zookeeper。

虽然Cassandra和HBase都不支持实时交易控制,但是两者都提供了一定程度的一致性控制。HBase向用户提供记录级(也就是行级)的一致性。实际上,HBase在每行都支持ACID级语义。用户可以在HBase中锁定一行,但是这种行为并不被鼓励,因为这不仅影响到并发性,同时行锁定还会导致无法进行区域分割操作。此外,HBase还可以执行“检查与写入”操作,该操作在单个数据元上提供了“读取-修改-写入”的语义。

Cassandra免费的DataStax社区版包含有一个DataStax 操作中心。该中心提供了集群监控与管理功能,它可以检测数据库模式,提示键空间是否能够被编辑,以及是否可以增加或删除列族。

尽管Cassandra被描述为拥有“终极”一致性,但是读取和写入一致性可以在级别和区间方面进行调整。也就是说,你不仅可以配置必须成功完成操作的冗余节点数量,还可以设置参与的冗余节点是否跨数据中心。

此外,Cassandra还在其计算机指令系统中增加了一些轻量级的交易。Cassandra的轻量级交易采用的是“比较与集合”机制,相当于HBase的“检查与写入”功能。不过,对于HBase的“读取-修改-写入”操作功能,Cassandra则缺乏相对应的功能。最终,Cassandra的2.0版本增加了单独的行级写入功能。如果一个客户端在一行中更新了多个列,那么其他的客户端将会看到所有未更新的部分,或所有更新的部分。

在Cassandra和HBase当中,主索引是行键,但是数据被存储在磁盘中,这导致列族成员相互间非常接近。因此仔细规划列族组织非常重要。为了保持高查询性能,有着相同访问模式的列应该被放在在相同的列族当中。Cassandra允许用户创建关于列值的额外次索引。这一举措提升了对那些值具有高重复性的列(例如存储客户电子邮件地址中国家地区的列)的数据访问。HBase虽然缺乏对次索引的内置支持,但是它们有一些能够提供次索引功能的机制。这些都在HBase的在线参考指南和HBase社区博客中被提及。

如前所述,两个数据库都有发布数据操作命令的命令行外壳。由于HBase和Cassandra的壳都是以JRuby壳为基础,因此用户可以编写一些脚本,让这些脚本能够调用JRuby壳的所有资源与数据库所提供的特定API进行交互。此外,Cassandra还定义了模仿自SQL的CQL。与HBase所使用的查询语言相比,CQL的功能更加丰富,并且可以在Cassandra的壳内直接执行。

尽管Cassandra仍然支持Thrift API,但实际上Cassandra一直在推动让CQL成为数据库的主要编辑接口。Cassandra的文档列入了一些针对Java、C#和Python等使用CQL version 3的驱动。最终,Cassandra将可获得一个JDBC驱动。该驱动用CQL替代了SQL,将CQL作为数据定义与数据管理语言。

HBase也支持Thrift接口和RESTful Web服务接口,不过HBase原生的Java API向编程人员提供了丰富的功能(如附图所示)。虽然HBase的数据操作命令没有CQL丰富,但是HBase拥有一个“筛选”功能,该功能可以在会话的服务器端执行,大幅提升了扫描(搜索)的吞吐量。

HBase还引入了“协处理器”(coprocessors)这一概念,允许在HBase进程中执行用户代码。这基本上与关系型数据库中的触发和预存进程相同。目前,Cassandra还没有类似HBase协处理器的功能。

Cassandra的文档较HBase的更加醒目,并且拥有更加扁平化的学习曲线。设置一个开发用的Cassandra集群比设置HBase集群要更加简单。当然,这仅对于开发与测试目的来说非常重要。


 
附图 HBase主节点在60010端口上托管了一个Web接口。用户可以浏览包括节点执行历史、由节点管理的表、主节点域中的地区服务器等信息。

棘手之处

在必须为特定应用调整集群时,用户需要做一些工作。在指定数据集大小、创建与管理多节点集群(通常会跨多个数据中心)的复杂度后,调整工作将变得非常棘手。用户需要深刻理解集群的内存缓存、磁盘存储和节点间通信之间相互影响,仔细监控集群的活动。

HBase对Zookeeper的依赖会带来一些额外的故障点。虽然Cassandra避开了这一问题,但这并不意味着Cassandra集群的调整难度会大幅下降。我们对两个数据库的集群调整难点进行了对比(如附表所示)。

 

需要说明的是,这里并没有确定谁是胜出者,谁是失败者。每个数据库的支持者都会找到一些证据来证明他们的系统优于对方。通常用户需要对两个数据库进行测试,然后才能确定它们执行目标应用的情况。那么从技术角度出发是否会有更好的办法呢?

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。