HBase模式设计

设计重点

HBase模式的重点有两个：Rowkey 和 Column Family

Rowkey的设计

Rowkey设计是HBase模式设计中最重要的事情

1、HBase数据基于Rowkey有序存储。Rowkey是HBase表的唯一索引，借助Rowkey对HBase表的访问能实现高效的二分查找，非Rowkey的访问只能通过全表扫描实现。

2、region根据有序的Rowkey进行划分

Rowkey的一个经典的设计是：id+时间戳，这种设计充分利用了HBase表中行键有序存储的特性。这种设计可以将id相关数据聚合在一起。

Rowkey要尽量均匀分布

要充分利用散列算法将Rowkey均匀分散开来，这样各个region存储的rowkey基本均衡，避免了个别region承担过多的读写负载

Rowkey的长度尽量短

1、时间尽量用long来表示，而不是字符串

2、尽量使用编码压缩

关于Join

HBase不支持表间连接！表间连接一般通过反范式设计，即冗余存储来实现。

列族设计

HBase数据表对行进行水平分片得到region。region单独完整地存储（HDFS冗余备份对上层的HBase不可见）在某台服务器上。region按列族进行垂直分片得到store，每一个列族对应一个store。store数据不断刷写得到HFile，最后HFile落实到HDFS中存储。

列族设计原则如下：

1、在满足业务需求的情况下，列族越少越好，这样可以将flush和compaction操作限制在一个region里面进行，这样可以减少不必要的I/O负载。

2、不同列族的数据要均衡

打个比方，T1表有两个列族F1、F2。F1有10w条数据，F2有1ww条数据。这样F1将会稀疏地分散到很多地region中，导致F1地扫描效率降低。这是数据条目地均衡

再打个比方，T1表有两个列族F1、F2。F1和F2在数据条目上是均衡的。可是F1每条数据的大小是1K，F2每条数据的大小是1G，那么F1依然会稀疏地分散到很多地region中，导致F1地扫描效率降低。

典型案例剖析：图书馆借书

核心业务需求：查询某同学在图书馆借了那些书，查询某本书是被谁借走了

RDBMS设计

学生表：

PK	stu_name	stu_num	stu_info

图书表

PK	book_name	book_num	book_info

借书关系

PK	FK：stu_PK	FK：book_PK

1、某同学借了那些书

1.1、根据学生学号，查到行数据（遍历学生表，如果在学号上建立了索引可以提高查询效率），取出stu_PK

1.2、根据stu_PK，查出对应的数据集（遍历借书关系表，如果在FK：stu_PK上建立了索引可以提高查询效率）

1.3、根据1.2查出的数据集取出book_PK集，到图书表中匹配，图书行数据（双遍历，取出的book_PK集*图书表book_PK，由于图书表book_PK有索引，速度会加快）

2、某书被谁借走了

跟“某同学借了那些书”差不多

HBase设计

本文暂且采取宽表设计，也可采取高表设计

学生借书表

Rowkey=stu_num	borrow_info
	stu_name	stu_info	book_num1	book_num2	...	book_numN
			1	0	1	0

图书借阅表

Rowkey=book_num	borrowed_info
	book_name	book_info	stu_num1	stu_num2	...	stu_numN
			1	0	0	0

这种设计更为直接，借书关系实际上在两张表里面都有存储。这样的冗余存储解决了HBase不支持join的缺陷。这种冗余存储方式在还书的时候出现了麻烦。理想情况下，还书的时候，希望学生借书表里面borrow:book_num*里面的计数器要修改，同时图书借阅表中stu_num*中的计数器也要修改。坑爹的是HBase又不支持跨表/行事务。这样极容易导致数据库的不一致性！其实不一致性并不可怕，只要不一致性可以得到合理的解释，HBase仍然能在不一致的情况下正确工作。我们下面结合这个例子来具体分析下：

首先，我们在还书的时候肯定要发出两条修改命令。这两条命令各自是原子的，但是整体不是原子的。这两条命令在大多数时候是可以正确运行的。不一致情况如下：

1、两条命令都成功，但是时间间隔有点长，在此间隔时间内数据库状态时不一致的

2、其中一条命令失败，此后数据库状态都是不一致的

还书的意义在于

1、证明学生名下已经没有这本书了

2、看看此书是否被占用，即是否可以被借出

我们看看第一点，证明学生名下有无这本书。这个显然要通过学生借书表来体现。

我们看看第二点，看看此书是否可以被借出。当一个学生从图书馆的书架上拿着这本书来找管理员借阅的时候，其实已经证明了书是可以借阅的。何须查询数据库，然后告诉学生可否被借阅？

这样，我们就定义不一致数据的解释：是否还书，以学生借书表为准！这样，在还书的时候，虽然还是两条修改命令都发出，但是还书操作以学生借书表是否成功修改为准。判断是否还书也以学生借书表为准！如果出现不一致状态，以学生借书表为准！