一、热点问题

1.热点问题描述

某一时间段内客户端并发读写操做集中在某一个region上或者某一台regionserver上，导致region或者regionserver的负载压力过大，是其他的好几倍，就造成热点问题。针对rowkey某个范围的比较，造成压力过大，浪费集群资源

2.解决：预分区，一开始创建表时就指定有多少个region

（a）create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
（b）create 't2', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}	
（c）create 't3', 'f1', SPLITS_FILE => 'splits.txt'  -》通过某个文件	   
（d）byte[][]splits={Bytes.toBytes("100"),Bytes.toBytes("100"),Bytes.toBytes("100")}

3.检测结果

put 't1','5000','f1:name','tom'	->插入(40,无穷)region   
put 't1','01','f1:name','tom'->插入(,10)region 
put 't1','22','f1:name','tom'->插入(20,30)region 
put 't1','1002','f1:name','tom'	->插入(10,20)region 
put 't1','a','f1:name','tom'	->插入(40,无穷)region

二、表设计原则

1. rowkey设计

（1）rowkey的长度原则：最多给到64kb，长度10-100个字节，越短越好，不要超过16个字节
   -》在hfile中按照kv（key-value）存储，如果rowkey过长，数据量非常大，造成hfile只能大量存储rowkey值.影响存储效率
   -》数据缓存到内存memstore，如果rowkey过长，内存有效利用率会降低，无发缓存更多的数据，影响存储效率
（2）rowkey散列原则(hash):将顺序打乱，多个字段进行组合
   -》组成：timestamp + uuid，其中，timestamp逐渐变化的预分区，所以效果不太明显
   -》uuid + timestamp 实现散列，uuid 可能随意的 + 预分区，所以效果明显
   -》加随机数：
           给rowkey随机分配一个前缀使他的排序有变化，打乱排序 --》按照自己的想法，将数据分配到不同的region
           缺点：写请求就会分散到多个regionservers，读的时候，增加了比较时间，读的效率就会稍微底低点
       -》字段反转
（3）rowkey唯一原则，必须保证rowkey在设计时必须是唯一的
   -》使用编码 -》长度、唯一、散列
       -》MD5
       -》crc32

2.列簇设计

（1）个数不要太多，3个以内，不要超过3个，名称不要太长
（2）最好列簇能使用一个就尽量使用一个
-》flush和compact以每一个region为基础的，一个列簇中的数据进行flush，将会影响到其他列簇的数据也会进行flush
-》如果说多个列簇都进行flush或compact，会导致大量的I/O请求，集群是不是感觉有点崩溃！！

HBase(6)：热点与表的设计原则