七 HBase表结构设计

表结构设计之 高表 与 宽表 选择

HBase 中的表可以设计为高表（tall-narrow table） 和 宽表（flat-wide table）。

高表 ： 列少而行多。

宽表 ： 行少而列多。
根据之前介绍的 KeyValue 信息的筛选粒度信息，用户应当尽量将需要查询的维度或信息存储在行键中，因为他的筛选数据的效率最高。此外，HBase只能按行分片，因此高表更有优势。设想用户将一个电子邮件都存储在一行中。这在大部分情况下都是合适的，但是也有人的收件箱中有大量的邮件。 大到一行数据就超过了最大 HFile 的限制，此时这个 HFile 无法拆分，同时也导致 region无法再合适的位置进行拆分。解决此问题的最好办法是把一个用户的每个电子邮件都存在单独的一行中，而行键可以是用户 userId 和消息 mesageId 的组合。



邮件系统。 用 userid + messageId（uuid） 因为 HBase 的行级原子性 可以根据用户是否批量修改 VALUE 内容
如果一个首检想中的数据现在分布在多行中，所以高表不可能在一次简单的操作中修改一个收件箱的全局属性， 如果用户不需要一次修改整个收件箱中所有邮件的消息，高表设计就非常合适。 如果用户有这种修改全局的需求，宽表将更加适合。因为HBase 能保证数据操作的行级原子性。

表结构设计之 数据块大小 选择( 65535 )
数据块小—索引大—占用更大的内存。 （同时加载进内存的数据块越小，随机查找性能就更好）
相反如果需要更好的序列扫描性能，那么一次性加载更多的HFile数据进入内存更为合理。这意味着应该讲数据块设置为更大的值。相应的，索引变小，将在随机读性能上付出更多的代价。
HFile 数据块大小可以在列族层次设置。这个数据块不同于之前谈到的HDFS数据块，默认值是65535字节，或65KB。数据块索引存储每个HFile数据块的起始键。数据块大小的设置影响数据块索引的大小。
hbase（main）：> create 'mytable',{NAME => 'colfaml',BLOCKSIZE => '65535'}

表结构设计之 数据块缓存 ( OPEN )

把数据放入缓存，并不是一定能够提升性能。如果一个表的列族只被顺序化扫描访问 或 很少被访问，则get scan操作花费时间长是可以接受的。 这种情况下可以选择关闭列族的缓存。
如果执行多次顺序化扫描（多次使用缓存）并且可能会滥用魂村， 从而把应该放进缓存获得性能提升的数据给排挤出去。如果关闭缓存，可以避免上述情况，而且可以让出更多缓存给其他表和同一表的其他列族使用。
数据块缓存默认是打开的。可以新建或更改表时关闭数据块缓存属性：
hbase(main):> create 'mytable', {NAME => 'colfam1', BLOCKCACHE => 'false' }

IN_MEMORY 参数的默认值是 false ，该值表示 HBase 除了在数据块缓存中保存这个列族相比其他列族更激进之外，并不提供其他额外保证。该参数在实际应用中设置为 true，此时访问性能不会变化太大。 设置IN_MEMORY：

hbase(main):> create 'mytable', {NAME => 'colfam1', IN_MEMORY => 'true'}

表结构设计之 布隆过滤器（NONE）

布隆过滤器可以应用在块上，检查行键，也可以应用在行内的单元格上，当访问某列表示服时先使用同样的反向检测
布隆过滤器允许对存储在每个数据块的数据做一个反向检测。查询行时，先查询布隆过滤器。（Bloom Filter）。看看该行是否不存在这个数据块， 要么返回该行不存在。要么返回不知道。
如果想要判断一个元素是不是在一个集合里，一般想到的是将所有元素保存起来，然后通过比较确定。链表，树等等数据结构都是这种思路. 但是随着集合中元素的增加，我们需要的存储空间越来越大，检索速度也越来越慢(O(n),O(logn))。不过世界上还有一种叫作散列表（又叫哈希表，Hash table）的数据结构。它可以通过一个Hash函数将一个元素映射成一个位阵列（Bit array）中的一个点。这样一来，我们只要看看这个点是不是1就可以知道集合中有没有它了。这就是布隆过滤器的基本思想。
Hash面临的问题就是冲突。假设Hash函数是良好的，如果我们的位阵列长度为m个点，那么如果我们想将冲突率降低到例如 1%, 这个散列表就只能容纳m / 100个元素。显然这就不叫空间效率了（Space-efficient）了。解决方法也简单，就是使用多个Hash，如果它们有一个说元素不在集合中，那肯定就不在。如果它们都说在，虽然也有一定可能性它们在说谎，不过直觉上判断这种事情的概率是比较低的。

存储这个额外的索引层需要占用额外的空间，占用的大小随着索引对象数据增长而增长。所以行级布隆过滤器比列标识符级布隆过滤器占用空间要小。当空间不是问题时，他们可以压榨整个系统的性能潜力

可以在列族上打布隆过滤器，代码：
hbase(main) > create 'mytable' , {NAME=>'colfam1', BLOOMFILTER => 'ROWCOL' }

NONE 布隆过滤器默认参数 。

ROW 表示 行级布隆过滤器（检查rowkey存不存在）；
ROWCOL表示 列标识符级布隆过滤器（检查 rowkey 和 列限定符存不存在）。

· 为什么用布隆过滤器。 以及数据未被刷入HFile时在MemStore中。



表结构设计之 数据压缩（NONE）
数据压缩有助于节省磁盘空间，但是读写数据时压缩和解压缩会提高CPU使用率。除非确定压缩不会提升系统的性能，否则推荐打开表的压缩。
只有在数据不能被压缩，或者因为某些原因服务器的 CPU 利用率有限制的情况下，有可能需要关闭压缩特性。

HBase使用的压缩编码： SNAPPY拥有 BSD（BSD-licensed）许可，所以它更容易和 Hadoop 及 HBase 发行版捆绑在一起。 LZO 和 SNAPPY 的压缩比例和压缩 / 解压速度差不多。

创建表时可以在列族上打开压缩：

hbase（main）> create 'mytable' , {NAME => 'colfaml' , COMPRESSION => 'SNAPPY'}

数据只在硬盘上是压缩的，在内存中（MemStore 或 BlockCache）或在网络传输时是没有压缩的。
数据的压缩编码不能经常改变，如果需要改变某个列族的压缩编码，直接更改表定义，设定新的压缩编码，当Region合并时，生成的 HFile 全部会采用新的编码压缩。这个过程不需要创建新的表和复制数据。

表结构设计之 单元时间版本( 3 Version ) .生存空间（Time To Live） TTL默认68年值
如果只需要一个版本，在创建表时可以直接将 VERSION 的参数设置为1。时间版本也是列族级的。
hbase(main) > create 'mytable' , { NAME => 'colfaml', VERSION => 1}
可以在同一个建表语句中为列族设置版本 和 生命周期

hbase(main) > create 'mytable' , { NAME => 'colfaml' , VERSION => 1, TTL => '18000'} // TTL 值默认是永久保存，（2147483647）单位是秒。 此数校验为 68 年

可以指定列族存储的最少时间版本数。

hbase(main) > create 'mytable' , { NAME => 'colfaml' , VERSION => 5, MIN_VERSION => '1' }

TTL 生存时间，用于设置单元格的生存周期。 如果单元格过期，则会将其删除。
早于指定时间的数据会在下一次大合并时将其删除。

God has given me a gift. Only one. I am the most complete fighter in the world. My whole life, I have trained. I must prove I am worthy of someting. rocky_24

来自为知笔记(Wiz)