众多基于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许可证免费获取。 |