Hbase表属性②

HBase表属性（续）
1.版本：
创建多版本的表
create 'testVersion', {NAME => 'f1', VERSIONS => 5}


put 'testVersion','[e-mail]','f1:emailetitle','gf'
put 'testVersion','[e-mail]','f1:emailetitle','bf'
put 'testVersion','[e-mail]','f1:emailetitle','jy'


get 'testVersion','[e-mail]',{COLUMN => 'f1', VERSIONS => 3}
COLUMN               CELL                                                   
 f1:emailetitle      timestamp=1495855693860, value=jy                      
 f1:emailetitle      timestamp=1495855688060, value=by                      
 f1:emailetitle      timestamp=1495855679967, value=gf 




  2.COMPRESSION压缩




3.memstore 和 blockcache
hfile.block.cache.size=0.4
HFile文件的块缓存大小占堆内存大小的比例，如果对读性能要求很高，可稍微调大一点。
memstore是主要负责写,blockcache主要负责读
读数据的时候,先读memstore,再读blockcache,最后再查磁盘
读出来的数据会保存到blockcache
BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)之后,就会启动淘汰机制,淘汰最老的一批数据  【最近最少使用淘汰LRU】
一个Regionserver对应一个blockcache


block的队列优先级
也就是blockcache在hbase中的等级,分为三级:
1. single -- 25%
如果block第一次被访问,则放在single中

2. multi -- 50%
如果block被超过一次访问到,则放在multi中

3. in-memory -- 25%
被标注为in-memory的数据,如果首次被访问就会被放置在in-memory中,如果没有标注in-memory,则会被放置在single中

## 在采用LRU淘汰机制的时候,被淘汰的顺序是:
1.single;2.multi;3.in-memory

## in-memory
in-memory的block确实不同于其他两种block的地方在于它的这个“in-memory”特征是静态指定的（在column family上设置），不会像其他两种cache会因访问频率而发生改变，这就决定了它的独立性，另外两种block访问次数再多也不会被放到in-memory的区段里去，in-memory的block不管是第几次访问，总是被放置到in-memory的区段中。


从in-memory cache的这些特性上来看，需要特别强调的是：
标记IN_MEMORY=>'true'的column family的总体积最好不要超过in-memory cache的大小（in-memory cache = heap size * hfile.block.cache.size * 0.85 * 0.25），特别是当总体积远远大于了in-memory cache时，会在in-memory cache上发生严重的颠簸。
换个角度再看，普遍提到的使用in-memory cache的场景是把元数据表的column family声明为IN_MEMORY=>'true。实际上这里的潜台词是：元数据表都很小。其时我们也可以大胆地把一些需要经常访问的，总体积不会超过in-memory cache的column family都设为IN_MEMORY=>'true'从而更加充分地利用cache空间。就像前面提到的，普通的block永远是不会被放入in-memory cache的，只存放少量metadata是对in-memory cache资源的浪费（未来的版本应该提供三种区段的比例配置功能）。


手动flush
hbase> flush 'REGIONNAME'

> flush 't2,,1482129525576.b9de5c52a9c3fb4580ee9cacb6520e7f.'

日常维护：
1，flush 'testtable'，将所有memstore刷新到hdfs，通常如果发现regionserver的内存使用过大，造成该机的 regionserver很多线程block，可以执行一下flush操作，这个操作会造成hbase的storefile数量剧增，应尽量避免这个操 作，还有一种情况，在hbase进行迁移的时候，如果选择拷贝文件方式，可以先停写入，然后flush所有表，拷贝文件。


compact 合并
## 1. major compactions
会将store中的所有storefile合并成一个文件
会删除已经过期的cells
## 2. minor compactions
一般会合并一些临近的小的storefile文件
不会删除已经过期的cells
偶尔也会将所有storefile文件合并成一个文件,此时它已经将自己提升为一个major compactions

minor compaction，轻量级
将符合条件的最早生成的几个storefile合并生成一个大的storefile文件，它不会删除被标记为“删除”的数据和已过期的数据，并且执行过一次minor合并操作后还会有多个storefile文件。

major compaction，重量级
把所有的storefile合并成一个单一的storefile文件，在文件合并期间系统会删除标记为"删除"标记的数据和过期失效的数据，同时会block所有客户端对该操作所属的region的请求直到合并完毕，最后删除已合并的storefile文件。

日常维护：
2，major_compact 'testtable'，通常生产环境会关闭自动major_compact(配置文件中hbase.hregion.majorcompaction设 为0)，选择一个晚上用户少的时间窗口手工major_compact，如果hbase更新不是太频繁，可以一个星期对所有表做一次 major_compact，这个可以在做完一次major_compact后，观看所有的storefile数量，如果storefile数量增加到 major_compact后的storefile的近二倍时，可以对所有表做一次major_compact，时间比较长，操作尽量避免高锋期。

eg:
删除前：scan  'nsa:users'
10010   column=info:name, timestamp=1498812410496, value=murongfu
                  
delete 'nsa:users','10010','info:name'


再次查询：scan  'nsa:users'
已无对应记录

查询删除数据：打上了删除标记
scan 'nsa:users',{RAW => true,VERSIONS => 1}
10010            column=info:name, timestamp=1499093816706, type=
                  DeleteColumn                                    
10010            column=info:name, timestamp=1498812410496, value
                  =murongfu
====================================
通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。
手动flush
flush 'nsa:users'

手动major_compact
major_compact 'nsa:users'
scan 'nsa:users',{RAW => true,VERSIONS => 1}


=============================================
减少Region Split次数
region split是提升写性能的一大障碍。减少region split次数可以从两方面入手，一是预分配region(该内容会在下章节表设计优化里详述)。其二是适当提升hbase.hregion.max.filesize
 
提升region的file容量也可以减少split的次数。具体的值需要按照你的数据量，region数量，row key分布等情况具体考量。一般来说，3~4G是不错的选择。
手动split
split 'tableName'  ## 默认从表的中间进行切分
> split 'so_detail_hbase'

split 'regionName', 'splitKey'
## 从指定的key将region进行切分
> split 'so_detail_hbase,,1482198683093.417cac6f3fb082186a315d1c4f4869b4.' ,'397777'

日常维护：
3，balance_switch true或者balance_switch flase，配置master是否执行平衡各个regionserver的region数量，当我们需要维护或者重启一个regionserver时，会 关闭balancer，这样就使得region在regionserver上的分布不均，这个时候需要手工的开启balance。