HBase 和 Cassandra的浅谈

原文地址


一:简介

关于hbase和cassandra的探讨,主要从多个方面来说,从最基本的一步步往深入的说,从最基本的部署运维,到支持特性,使用功能以及各自的优势;

先从比较宏观的角度分析,HBase是基于Google的bigtable的论文实现的列式数据库,cap理论中更倾向于强调c(副本数据一致性)和p(分区容错性)。而Cassandra是号称dynamo 加上 bigtable(数据模型)的实现,cap中强调a(可用性) 和 p。而且底层都是使用lsm-tree 来做存储引擎的核心数据结构;

HBase基本上就是bigtable的开源实现,对标的bigtable的chubby(分布式锁服务)HBase有对应的zookeeper,HBase用regionserver管理region里的数据,实际上的数据副本容错的机制是交付给底层的分布式文件系统hdfs,类比bigtable的gfs,HBase有hmaster做元信息管理。Cassandra在架构上更多借鉴了dynamo,一种完全的区中心对等的分布式数据库,她的每个节点维护一份元信息,每一个节点在集群中的身份完全一样。

二:部署运维

单纯的就部署和运维hbase以及Cassandra来说,部署hbase前,需要部署的组件有zookeeper,hdfs,然后才是hbase。对应的Cassandra就比较简单很多,编译完成一个jar包,单台服务器启动一个Cassandra进程即可。

在部署hbase的时候,可能需要规划好,哪些机器跑hmaser,rs,zk,hdfs的相关进程等, 还有可能为了集群的性能,还要预先规划好多少个rs。自己人工去部署这么一个hbase集群还是比较麻烦的,更别提自己维护(阿里云ApsaraDB-HBase你值得拥有)。

Cassandra部署的时候比较简单,一个tar包搞定,由于cassandra数据落本地盘,需要人为的配置一些参数比如是否需要虚拟节点(vnode)以及多少vnode;需要基于业务的场景选择特定的key的放置策略(partitioner),这个放置策略的选择以及一些参数的配置需要一定的门槛。

简单总结下:部署运维的话,hbase依赖组件多,部署麻烦一点,但是相关资料很多,降低了难度;cassandra部署依赖少,但是配置参数多,相关资料较少。

特别是使用云HBase完全避免了部署造成的各种麻烦,比手工部署运维任何大数据数据库都方便太多。

三.特性对比

3.1.特性概述

HBase的社区文章里面有介绍hbase的特性点,翻译过来有如下的几个点:

1.强一致性的读写:HBase不是一个最终一致性的存储。

2.自动sharding:HBase的table在集群种被分布在各个region,region可以做自动切分。

3.regionserver的failover;

4.Hadoop/HDFS的集成;

5.MapReduce:支持大数据的并行处理;

6.JAVA Client 以及Thrift/RESR API 访问;

7.Block Cache 以及Bloom filter;

8.操作管理。

就上述HBase的特性,C*也有相应的自己的特性:

1.C*借鉴Dynamo的架构思想,把自己叫做一个最终一致性的系统,但是从[这篇文章](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html)可以看出,如果使用至少是QUORUM 读写,还算是一个强一致的系统。

2.C*的sharding方式:一致性hash,有2种:(1)人为配置好initial_token;2.使用vnode,集群初始化以及节点bootstrap的时候会计算token,基于这些token做数据sharding。

3.可以容忍:replicator_number - (read/write level sufficient nodes)个节点挂了,比如3个副本,读写级别QUORUM(sufficient nodes是2),能容忍1节点挂;

4.支持MapReduce;

5.Thrift、CQL访问;

6.大数据处理的bloom filter 必备;

7.自己有jmx等常见管理,且datastax 公司有提供ops center;

从上述特性来看,各个数据库各有千秋,但是有各自的适合场景,如果业务对数据一致性要求比较苛刻,那么HBase可能更合适,毕竟C* 还是存在一定的问题,比如删除数据可能复现;C*推荐放置策略用Random以及Murmur3等方式,这样把key打散的很随机,以此做节点负载均衡,这样做scan业务自己的需求数据,可能数据库要全集群都访问,当然可以使用OrderPreserving 和 ByteOrdered可以不用全集群都访问,可是负载不是很均匀,HBase这点却支持的不错;就易用性来说,Cassandra做的还是不错的,在数据库内部提供cql,一种类sql的语句。HBase还是主要JAVA API/Thrift的接口支持,但是后续HBase这方面应该会提高,前段时间的HBase 2017 Asia 阿里也介绍了sql on HBase。

后续在易用性这一块HBase应该是越来越好,会弥补上在易用性这一块的欠缺。试想下,如果Nosql都支持大部分的SQL的功能和语法,那是多完美的事情。

3.2.特性对比

本小结就 HBase 和 C*在部分相关特性上进行细一步的分析对比,大概对比的部分选择为:一致性;sharding方式;用户使用方式;数据复制;

3.2.1 一致性:

一般的一致性在这里是指副本数据的一致性,我们常用的是3副本用来做冗余。HBase的话主要是依赖底层的HDFS来支持副本冗余,一次写入被regionserver收到以后,发送给底层的HDFS,而HDFS会对应的给这个数据在整个文件系统里面写多份;这里是多份副本全部写完成才会返回。读数据的话,在底层HDFS的处理是读主要的这份数据就可以,因为多份数据都是一样的(正常情况)。

C*在建表的时候会指定表的副本数(常见3副本),一次数据写入,会基于当前表的副本数以及节点的snitch策略来找到需要写的数据节点,发出多份请求(3份),然后基于传递的写入级别等待对应的响应数即可,比如A,B,C三个副本,QUORUM级别写入,可能存在的情况是,A,B成功C写入失败(无论是网络还是节点跪了),那么这个时候3个副本实际上是不一致的。但是这里对于 C *来说,她能忍。而且如果你读的级别是QUORUM可以读到最新的数据,但是如果你用ONE级别去读数据,那么存在读到老数据的风险,但是C *存在这种情况(当然这里先不考虑C *内部的机制自己修回副本数据)。

C *由于不能保证副本一致性,自己提出了几种方式来做弥补:1.读修复;2.Hinted-Handoff;3.Anti-entropy repair ;但是各种机制的引入也不是很完美的解决问题,此外还相应的会引入一些问题,比如使用1的话,那些读不到的数据存在一直数据不一致的风险;使用3的方式去进行全量/增量数据对比,会消耗很多物理资源,影响在线服务的请求,这是在线服务不能忍受的。

这种情况下来看,HBase的读写以及数据一致性模型是比较简单的。简单就是美,这对具体的业务场景进行适配也是很nice的一面,如果一个数据库的模型过于复杂,业务方拿来用也需要很高的门槛。

2.2.2 shadring 方式:

HBase 的各个regionserver 在最初负责的region,是可以在最初的建表时候,可以做预分配,也可以让hbase自己做这件事情,那么每个regionserver就会负责相应的region的数据的读写等。对于出现热点region的情况的话,hbase自己支持region的split操作,将热点region一分为二。

C* 不支持所谓的热点数据spli region的功能,那么对于这种情况的话,她做了一个预先设置,输入的数据做hash打散,也就是我们知道的一致性hash,她内部支持4种hash策略,Murmur3,Random,OrderPreserving等,其中,前2种是做了随机的hash,OrderPreserving 是类似字典序的方式,最初无论是使用vnode的方式还是initial_tokne的方式人为设置节点token,来一个请求,计算随机hash可以把key比较随机打散到集群中的某个节点,通过snitch 和 keyspace 副本方式找到落得节点信息,因为前面的随机hash可以人为是比较随机的,那么这实际上可以理解为一种负载均衡。但是如果是OrderPreserving 这种方式,实际上就会有问题;出现热点也没办法;

而且我们知道随机hash如果要做scan,实际上是很蛋疼的,基本上所有节点都要操作。字典序可以避免操作所有的数据节点,从这点看,HBase还是占点优势。

2.2.3 用户使用方式

HBase现在提供给用户主要是JAVA/THrift/REST的接口,大概的操作也就是CRUD操作;这些使用还是不是具有亲和性。比如我现在要往表“table”里面写一条数据,rowkey是“test” 列是“cn1” "cn2",value是“value1”, "value2"那么我需要进行下面的操作:

    Configuration conf = HBaseConfiguration.create();

    HTable htable = new HTable( conf, "table"); 

    Put put = new Put(Bytes.toBytes("test"));

    put.add(Bytes.toBytes("cn1"), Bytes.toBytes("qual1"), 

        Bytes.toBytes("value1"));

    put.add(Bytes.toBytes("cn2"), Bytes.toBytes("qua2"), 

        Bytes.toBytes("value2"));

    table.put(put);

但是对于C* 而言,支持2种方式,1.THrift;2.CQL;thrift我们就不讨论了,主要介绍CQL,这是一种类sql的语言,主要用于操作C*,那么通样写一条数据cql是:

INSERT INTO xxx.table (cn1, cn2) VALUES (value1, value2);

此外C* 支持多种索引,特别是有一种新的索引,sasi index支持prefix,contains等操作;

不过HBase也有支持sql的组件且也在往这边发展也不是太大问题;

2.2.4 数据复制

一般数据复制,有全量数据复制和增量数据复制2个情况,主要是为了集群的高可用做铺垫,全量复制的时候,有的使用copytble的方式,这边比较简单,但是因为是mr做批量读取写入(我们之前就是用这种方式导Cassandra的数据),但是会比较耗时,因为每次请求一个网络来回;也有基于snapshot做复制的方式,这种方式会好点;增量复制的话,使用的是复制Hlog的方式,这是一种异步的复制方式,在zk记录checkpoint,复制完log以后修改checkpoint的问位置。

C* 的数据复制,也与2种方案,但是都是需要时在Network的拓扑配置下,同cluster的不同dc环境下的操作,全量复制是一种叫做rebuild的方式,直接拖数据的stream,类似C* 做节点启动bootstrap的过程,C* 的增量复制 提供了2种方式:EACH_QUORUM,LOCAL_QUORUM 前者是同步写主备,后者是写本地,返回client,远端是否成功不care;对于这个而言的话,异步存在丢数据的风险,同步在跨region以及并发量大的情况下,请求失败率会很高。但是,上面的方式是需要部署在同clsuter下面的不同dc,不同cluster没有解决方案。此外对于同步和异步方案之间没有一种折中的方式,毕竟有的场景对性能要求高,同步复制影响线上写成功的概率,异步复制会丢数据。但是阿里HBase在这方面去做了一个同步异步并存的方式,同步异步共存复制。


原文地址

HBase 和 Cassandra的浅谈_第1张图片

你可能感兴趣的:(HBase 和 Cassandra的浅谈)