一、热点问题
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请求,集群是不是感觉有点崩溃!!