背景：

创建一个表的时候默认一个region，同时也是一个regionServer，因此大量的读写操作可能造成负载压力过大，因此增加regionserver数及region的数可以有效的提供并发能力，并且多个region可以负载到多个regionserver上有效提供并发能力。

列族设计

hbase的列族应该越少越好因为一个列族对应的一个store，因此如果有多个列族就对应多个store，占用的空间多另一方面查询的时候需要跨store查询。增加 IO开销。 因此建议使用尽量少的列族。而且多个列族容易出bug
原则经常查询的放到一个列族，不经常查的放到另外一个列族

压缩选择

压缩.png
结论:读多建议使用Snappy，写多建议使用GZIP
在创建表时指定压缩方案:
create ‘表名’ , {NAME=’列族’,COMPRESSION=>’压缩方案’}
给以及建好的表添加压缩方案:
alter ‘表名’ , {NAME=’列族’,COMPRESSION=>’压缩方案’}

案例:
create ‘MOMO_CHAT:MSG’,{NAME=>’C1’,COMPRESSION=>’GZ’}

表的版本设计

表的版本设计需要根据业务确定默认版本是 1，节省空间。查看可以通过describe ‘namespace:table’

预分区

通过指定startrow,endrow 来指定分区数，在创建表的时候就在多个region上，在插入数据的时候rowkey将插入到对应的region上，设置方式

  1. 1.指定分区
  2. create 'momo:region_test','cf1',SPLITS=>['1','2','3']
  3. 2.通过Hash分区（16进制） 特别主要注意的是使用HexString 分区后rowkey必须转16进制否则还是存在数据倾斜
  4. create '表名' ,'列族名称1', .... , {NUMREGIONS=>N , SPLITALGO=>'HexStringSplit'}

自动分区

rowkey设置原则

3.1rowkey官方设置要求

1.rowkey尽量短不要长，因为rowkey存储在内存中太长的rowkey占用太多的空间加快memstore的flush操作
一般的话10-100个字节
2.rowkey不要顺序增加，避免自增造成数据都存到一个region
3.使用Long比String 类型占用的空间更少
4.保证rowkey的唯一性，否则数据覆盖

3.2如何避免数据热点问题

数据热点问题就是数据集中一个或其中的几个region不平均，主要采取下面几种方式
1.反转策略，比如时间戳，手机号，保证前缀不同落在不同的region
2.加盐 ，给rowkey加固定长度的随机数，从而保证数据落到不同的region上
3.使用hash取模， 给相同的数据加相同的盐