HBASE的使用笔记

HBASE是列指向数据库

文件系统，推荐用HDFS

HDFS的特长是sequence read，random read and wright比较弱，用HBASE可以弥足。

HBASE是master型，有一个master节点和N个region节点，为了防止master节点down，用hotstandby master做shadow。

当master做failover的期间，region的 分配和failover是不能执行的 。

除了master型，还有 P2P型，比如Cassandra，好处就是不存在 master，也就没有SPOF

为什么HBASE擅长写。

1，追加型数据库，只有add row操作。delete只是标记为tompstone，值置为空
2，写日志（WAL write ahead log）是顺序写到HDFS
3，client过来的数据写进内存（Memstore）

为什么读到延迟低

1，block caching
2,bloom filter (空间效率很高的随机数据结构,通过极少的错误换取了存储空间的极大节省)

HBASE只有一种index，没有second index的concept
Rowkey，column，timestamp（降序）

HBASE本身是不能进行sql和join操作

CAP定理
Consistency
Availability
Partition-tolerance

2000年eric brewer提出的 分布式系统只能满足AP或者CP的模型。 （其实不正确，可以都 满足 CAP）

HBASE是CP型，Cassandra是AP型

传统RDB， 比如Mysql用shading实现数据库的 scale out，其实和HBASE的模型概念非常类似。

但缺点就是不能跨server使用join操作，也不能跨process使用transaction。其实已经不能成为RDB呢 。

HBASE的数据模型

1，Namepace是table的grouping

2，ColumnFamily是Column的grouping

3，Row可以理解为存放column值的container

4，存入数据时，会同时存入timestamp，形成version。可以通过设置TTL定时删除旧数据

HBASE的运行

1，Region是按RowKey的范围水平切分
2，根据自定的policy,达到一定程度后会spilt，但是这个操作很快完成，因为并不是真的spilt而是生成pointer，Compaction操作的时候才是真正的spilt.

Master的作用
1，管理meta data
2，监视region server的failover
3，分配region和load blancing

Region的作用
1，直接和client间交换数据
2，region自身的管理（Flush，Compaction）

client如何和HBASE交互
1，通过zookeeper得知where master is
2,向meta data要所需region的情报
3，去连接region
4,缓存连接信息到本地，以后不需要通过master
5,如果region情报失效，重复以上操作

HBASE的data结构
1，一个region一个WAL
2，一个ColumnFamily一个Memstore，多个HFILE
3，MemStore的其实是一个HFILE，并且sort完毕的，flush到HDFS后WAL被clean，等到compaction的时候重新merge成新的HFILE

大多数RDS是基于B+数的，HBASE采用的LSM-tree （Log Structured Merge）
简单说提高写性能，牺牲一部分读性能，因为会生成很多HFILE文件，读的时候会遍历这些HFILE，
所以使用缓存和bloom filter技术来提升读性能

最基本的LSM是很简单的 。将之前使用一个大的查找结构（造成随机读写，影响写性能），
变换为将写操作顺序的保存到一些相似的有序文件（也就是sstable)中。所以每个文件包
含短时间内的一些改动。因为文件是有序的，所以之后查找也会很快。文件是不可修改的，
他们永远不会被更新，新的更新操作只会写到新的文件中。读操作检查很 有的文件。
通过周期性的合并这些文件来减少文件个数。

关于compaction

minor compaction
只是单纯地把很多小的HFILE合成一个大的
Compaction continues creating fewer, larger and larger files.

Major Compaction
会物理删除被标记会delete的和TTL过期的数据

关于 Levelled Compaction

这里像Levlled DB和 Cassandra解决这个问题的方法是：
实现了一个分层的，而不是根据文件大小来执行合并操作。这
个方法可以减少在最坏情况下需要检索的文件个数，同时也减少了一次合并操作的影响。

每一层可以维护指定的文件个数，同时保证不让key重叠。也就是说把key分区到不同的文件。
因此在一层查找一个key，只用查找一个文件。第一层是特殊情况，不满足上述条件，key可以分布在多个文件中。
每次，文件只会被合并到上一层的一个文件。当一层的文件数满足特定个数时，一个文件会被选出并合并到上一层。
这明显不同与另一种合并方式：一些相近大小的文件被合并为一个大文件。这些改变表明按层合并的策略减小了合并操作的影响，同时减少了空间需求。
除此之外，它也有更好的读性能。但是对于大多数场景，总体的IO次数变的更多，一些更简单的写场景不适用。

关于Region sever的failover

当一台regionserver down了的时候，master会把对象region的WAL在其他region上执行，因为HDFS系统保证其他region也会有WAF的replication。