mysql hbase写入性能_HBase性能调优

1、垃圾回收(GC)参数配置

Hbase是java开发的,也是运行在java虚拟机jvm中,所以也可以通过GC参数配置调优;

主要调节的是RegionServer节点的JVM垃圾回收参数;

垃圾回收策略:Parraller New Collector垃圾回收策略;并行标记回收器(Concurrent Mark-Sweep Collector),避免GC停顿

使用:一般用于用于写在hbase-env.sh

export HBASE_REGIONSERVER_OPTS="-Xmx8g -Xms8G

-Xmn128m -XX:UseParNewGC -XX:UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=70 -verbose:gc

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps

-Xloggc:$HBASE_HOME/logs/gc-${hostname}-hbase.log"

2、HBase内存管理

HBase上的Regionserver的内存主要分为两部分,一部分作为Memstore,主要用来写;一部分作为BlockCache,主要用于读。

写请求会先写入Memstore,Regionserver会给每个region提供一个Memstore,当Memstore满128M(hbase.hregion.memstore.flush.size)以后,会启动flush刷新到磁盘,当Memstore的总大小超过限制时(heapsizehbase.regionserver.global.memstore.upperLimit0.9),会强行启动flush进程,从最大的Memstore开始flush知道低于限制

b706f1dfbfda

image.png

b706f1dfbfda

image.png

读请求先到Memstore中查数据,查不到就到BlockCache中查,再查不到就会到磁盘上读,并把读的结果放入BlockCache。由于ClockCache采用的是LRU(最近最少使用)策略,因此BlockCache达到上限(heapsizehfile.block.cache.size0.85)后,会启动淘汰机制,淘汰掉最老的一批数据。

在注重读响应时间的应用场景下,可以将BlockCache设置大些,Memstore设置小些,以加大缓存命中率。

如果不希望自动触发溢写,就将值调大

hbase.hregion.memstore.flush.size

134217728

一般在企业中这个参数是禁用的

hbase.hregion.majorcompaction

604800000

直接将值设置为0就可以了,表示禁用

何时执行split

hbase.hregion.max.filesize

10737418240

一般建议将值调大,在期间手动去触发split

Memstore刷写数据到磁盘时,造成RegionServer内存碎片增多,当生存时间较长的数据从堆的老年代空间刷写到磁盘,就会产生内存孔洞。由于碎片过多导致没有足够大的连续内存空间,JVM就会暂停工作进程,进行垃圾回收(GC),导致HBase的RegionServer对外服务停顿

本地Memstore缓存机制:启用本地memstore分配缓存区(Memstore-Local Allocation Buffers,MSLAB),也就是允许从堆中分配相同大小的对象,一旦这些对象分配并且最终被回收,就会在堆中留下固定大小的孔洞,这些孔洞可被重复利用,GC就无需使应用程序进程停顿来回收内存空间,配置参数hbase.hregion.memstore.mslab.enabled,默认为true。

3、启动SNAPPY压缩

HBase列存储,比较占用空间,所以一般需要采用压缩算法,(从mysql导入hbase数据时发现,原本在mysql中30G数据,在hbase中占用150G),其中snappy性能优异,而且CDH中,直接安装了snappy的库。

使用方式:

1、创建时指定格式;

hbase> create 'test', { NAME => 'c', COMPRESSION => 'SNAPPY' }

2、修改已经创建好的列簇的压缩格式

disable 'test'

alter 'test', NAME => 'c', COMPRESSION => 'snappy'

enable 'test'

major_compact 'test' --修改之后,需要做一个major合并才能养压缩格式生效

describe 'test' --查看有没有生效

注:snappy是需要单独下载并编译安装的

4、预创建Region

创建HBase时,就预先根据可能的RowKey划分出多个Region而不是默认的一个,从而可以将后续的读写操作负载均衡到不同的Region上,避免热点现象;

HBase表的预分区需哟啊紧密结合业务场景来选择分区的key值,每个region都有一个startKey和一个endKey来表示该region存储的rowKey范围;

//有以下四种创建方式:

create 'ns1:t1' , 'f1' , SPLITS => ['10','20','30','40'] ;

create 't1','f1',SPLITS_FILE => 'splits.txt', OWNER=> 'johnode' ;

——其中splits.txt文件内容是每行一个rowkey值

create 't1','f1',{NUMREGIONS => 15, SPLITALGO =>'HexStringSplit'}

JavaAPI

HTableDescriptor desc = new HTableDescriptor(TableName.valueOf(weibo_content));

HColumnDescriptor family = new HColumnDescriptor(Bytes.toBytes("cf"));

// 开启列簇 -- store的块缓存

family.setBlockCacheEnabled(true);

family.setBlocksize(1024 * 1024 * 2);

family.setCompressionType(Algorithm.SNAPPY);

family.setMaxVersions(1);

family.setMinVersions(1);

desc.addFamily(family);

// admin.createTable(desc);

byte[][] splitKeys = { Bytes.toBytes("100"), Bytes.toBytes("200"), Bytes.toBytes("300") };

admin.createTable(desc, splitKeys);

5、负载均衡

balance_switch,master用来均衡各个regionserver上region数量

6、避免Region热点

热点现象:某个小的时段内,对HBase的读写请求集中到极少数的Region上,导致这些Region所在的RegionServer处理请求量骤增,负载量明显偏大,而其他的RegionServer明显空闲;

出现的原因:主要是因为Hbase表设计时,rowKey设计不合理造成的;

解决办法:Rowkey的随机散列+创表预分区

RowKey设计原则:

1、总的原则:避免热点现象,提高读写性能;

2、长度原则:最大长度64KB,开发通常10-16个字节,因为Hbase中每个单元格是以key-value进行存储的,因此每个value都会存储rowkey,所以rowkey越来越占空间;

3、散列原则:将时间上连续产生的rowkey散列化,以避免集中到极少数Region上

4、唯一原则:必须在设计上保证rowkey的唯一性

RowKey设计结合业务:

在满足rowkey设计原则的基础上,往往需要将经常用于查询的字段整合到rowkey上,以提高检索查询效率

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值