HBase的一些应用设计tip

1，对于HBase的存储设计，要考虑它的存储结构是：rowkey+columnFamily:columnQualifier+timestamp(version)+value = KeyValue in HBase，一个KeyValue依次按照rowkey，columnkey和timestamp有序。一个rowkey加一个column信息定位了hbase表的一个逻辑的行结构。

2，从逻辑存储结构到实际的物理存储结构要经历一个fold过程，所有的columnFamily下的内容被有序的合并，因为HBase把一个ColumnFamily存储为一个StoreFile。

3，把HBase的查询等价为一个逐层过滤的行为，那么在设计存储时就应该明白，使设计越趋向单一的keyvalue性能会越好；如果是因为复杂的业务逻辑导致查询需要确定rowkey、column、timestamp，甚至更夸张的是用到了HBase的Filter在server端做value的处理，那么整个性能会非常低。

4，因此在表结构设计时，HBase里有tall narrow和flat wide两种设计模式，前者行多列少，整个表结构高且窄；后者行少列多，表结构平且宽；但是由于HBase只能在行的边界做split，因此如果选择flat wide的结构，那么在特殊行变的超级大（超过file或region的上限）时，那么这种行为会导致compaction，而这样做是要把row读内存的~~因此，强烈推荐使用tall narrow模式设计表结构，这样结构更趋近于keyvalue，性能更好。

5，一种优雅的行设计叫做partial row scan，我们一般rowkey会设计为<key1>-<key2>-<key3>...，每个key都是查询条件，中间用某种分隔符分开，对于只想查key1的所有这样的情况，在不使用filter的情况下（更高性能），我们可以为每个key设定一个起始和结束的值，比如key1作为开始，key1+1作为结束，这样scan的时候可以通过设定start row和stop row就能查到所有的key1的value，同理迭代，每个子key都可以这样被设计到rowkey中。

6，对于分页查询，推荐的设计方式也不是利用filter，而是在scan中通过offset和limit的设定来模拟类似RDBMS的分页。具体过程就是首先定位start row，接着跳过offset行，读取limit行，最后关闭scan，整个流程结束。

7，对于带有时间范围的查询，一种设计是把时间放到一个key的位置，这样设计有个弊端就是查询时一定要先知道查询哪个维度的时间范围值，而不能直接通过时间查询所有维度的值；另一种设计是把timestamp放到前面，同时利用hashcode或者MD5这样的形式将其打散，这样对于实时的时序数据，因为将其打散导致自动分到其他region可以提供更好的并发写优势。

8，对于读写的平衡，下面这张图更好的说明了key的设计：salting等价于hash，promoted等价于在key中加入其他维度，而random就是MD这样的形式了。

9，还有一种高级的设计方式是利用column来当做RDBMS类似二级索引的应用设计，rowkey的存储达到一定程度后，利用column的有序，完成类似索引的设计，比如，一个CF叫做data存放数据本身，ColumnQualifier是一个MD5形式的index，而value是实际的数据；再建一个CF叫做index存储刚才的MD5，这个index的CF的ColumnQualifier是真正的索引字段（比如名字或者任意的表字段，这样可以允许多个），而value是这个索引字段的MD5。每次查询时就可以先在index里找到这个索引（查询条件不同，选择的索引字段不同），然后利用这个索引到data里找到数据，两次查询实现真正的复杂条件业务查询。

10，实现二级索引还有其他途径，比如：1，客户端控制，即一次读取将所有数据取回，在客户端做各种过滤操作，优点自然是控制力比较强，但是缺点在性能和一致性的保证上；2，Indexed-Transactional HBase，这是个开源项目，扩展了HBase，在客户端和服务端加入了扩展实现了事务和二级索引；3，Indexed-HBase；4，Coprocessor。

11，HBase集成搜索的方式有多种：1，客户端控制，同上；2，Lucene；3，HBasene，4，Coprocessor。

12，HBase集成事务的方式：1，ITHBase；2，ZooKeeper，通过分布式锁。

13，timestamp虽然叫这个名字，但是完全可以存放任何内容来形成用户自定义的版本信息。

本文链接