Hbase数据存储

2020-05-22 00:00:00 数据 操作 文件 设计 方式

现在市面上流行的数据库很多,常见的例如关系型数据库:mysql,oracle。同时随着近些年大数据的发展,出现了一批又一批的数据存储方式。以key-value为代表的MongoDB,ElasticSearch等,以文件为存储方式的hadoop文件存储方式。本文中讲述的大数据存储Hbase。

hbase底层也是采用hdfs的文件式存储结构,上层通过hbase进行封装提供给开发人员。都知道关系型数据的是为了方便查询,比如mysql,采用的B树的方式来进行查询,同时设计各种索引来提高搜索效率。但是当考虑写入的时候,又有多少数据库有考虑呢,hbase就是在这个基础上进行考虑。google开发的BIgTableu就是基于宽表的设计。

hbase主要用在日志存储,因为日志的需求是写入比较多,而查询相对比较少。因此在这样的场景下,应该尽量考虑写入而不是查询。底层所采用的算法是LSM算法,与mysql的B+树相比。

简单的说,LSM被设计来提供比传统的B+树或者ISAM更好的写操作吞吐量,通过消去随机的本地更新操作来达到这个目标。

那么为什么这是一个好的方法呢?这个问题的本质还是磁盘随机操作慢,顺序读写快的老问题。这二种操作存在巨大的差距,无论是磁盘还是SSD。

所以,让我们想想,如果我们对写操作的吞吐量敏感,我们好怎么做?一个好的办法是简单的将数据添加到文件。这个策略经常被使用在日志或者堆文件,因为他们是完全顺序的,所以可以提供非常好的写操作性能,大约等于磁盘的理论速度,也就是200~300 MB/s。
因为简单和高效,基于日志的策略在大数据之间越来越流行,同时他们也有一些缺点,从日志文件中读一些数据将会比写操作需要更多的时间,需要倒序扫描,直接找到所需的内容。
这说明日志仅仅适用于一些简单的场景:1. 数据是被整体访问,像大部分数据库的WAL(write-ahead log) 2. 知道明确的offset,比如在Kafka中。

1.hbase是基于宽表设计的,因此其中空白区域并不占用内存。

2.hbase设计关键(rowkey设计):time+uuid

由于hbase只支持api方式访问,因此开发难度比较大,但是可以考虑接入phoenix来达到sql方式操作数据。

相关文章