Hbase数据存储

现在市面上流行的数据库很多，常见的例如关系型数据库：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方式操作数据。