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集群的调整难度会大幅下降。我们对两个数据库的集群调整难点进行了对比（如附表所示）。
需要说明的是，这里并没有确定谁是胜出者，谁是失败者。每个数据库的支持者都会找到一些证据来证明他们的系统优于对方。通常用户需要对两个数据库进行测试，然后才能确定它们执行目标应用的情况。那么从技术角度出发是否会有更好的办法呢？
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
