简单HBase笔记

 一、Client-side write buffer 客户端缓存请求

描述:可以缓存客户端的请求,以此来减少RPC的次数,但是缓存只是被存在一个ArrayList中,所以多线程访问时不安全的。
可以使用getWriteBuffer()方法来取得客户端缓存中的数据。 默认关闭。
二、Scan的Caching
描述: next( )方法请求一行就要使用一次RPC,即使你指定了next(int nbRows)也一样,很明显这在性能上会存在一些问题,特别是每次都是请求一个很小的cell的时候。这时候,我们可以考虑在每次RPC的时候,取出更多的row, 这就被称为 scanner caching。这个cache可以在作用在两个层面上:table与scan. 在table层面上, 所有对这table的scan都会激活cache,你也可以只针对某一个scan进行cache。
但是你需要权衡RPC次数与内存使用,假设你把缓存数设置的太高了,就会适得其反。因为每次RPC需要取更多的数据,然后从服务器传到客户端,假设超过了客户端设置的heap最大值,那么就会发生OOM异常。不仅如此,就算没有发生OOM异常,但是由于传输时间长或者客户端处理的时候过长,没有在lease规定的时间内完成,那么就会抛出ScannerTimeoutException。

三、Scan的Batching
描述:之前说到了scan的caching,是针对行级别的,但是有时候row特别长,那cache起来就很有压力了,这个时候,hbase给我们的另一种解决方案是batching, batching是针对列的。它可以控制每次请求next()要取出多少列。当然,就如之前所说,不要batch太多列,会有OOM与ScannerTimeoutException的风险。
显然2和3可以结合起来使用,在减少RPC次数的情况下,也能控制row和column的获取。

四、RowLock
描述:mutate操作,put delete checkAndPut,等等,都会排它的执行,即它们肯定是串行操作的,不会发生并行操作。而get操作是不加锁的,而是使用multiversion concurrency control style来处理,说白了就是读已经存在的最新的记录。
http://en.wikipedia.org/wiki/Multiversion_concurrency_control , 但是要注意一点,假如lease过期了,那么你回来再想使用这个rowlock的时候,就会抛出UnKnownRowLockException。

五、Preflushing on Stop
描述:当某台rs接收到被关闭的要求时,注意这里,是正常的被通知下线,而不是由于什么自身的异常导致的下线,rs会检查所有的memstore,任何大小超过hbase.hregion.preclose.seize配置的memstore会被强制刷新到硬盘(这里指hdfs). 在这个阶段的时候,rs包括region还是正常可以服务的,等到preflush完后,memstore里面剩下的基本上都不多了,只要再执行一次flush就完成了,注意,到后面的那次flush的时候,rs已经不再接收请求了。preflush与其说是提高了region的可用性,不如说是使得rs的关闭更加平滑。

六、region split
描述: 这个是最最基础的问题了,当然,hbase大多数的bug就是出现在这里。当region中的storefile的总大小大于hbase.hregion.max.filesize设置的大小时,这个region就要split,在这个region一分为二的过程中,进行的非常快,因为hbase只需要为两个新的region(在hbase中也成为daughters)建两个reference file而已.当两个daughters准备上可以上线的时候,后台线程会把父region的store files写到两个子region中,同时也会替换掉reference file。最后master会看看到底需不需要做load balance。

七、Compactions
描述 当region内的storefile的数量大于hbase.hstore.compaction.min(hbase.hstore.compactionThreshold)时,就会触发minor compaction,而每次minor ompaction所包含的最大文件数由hbase.hstore.compaction.max指定。并且,hbase.hstore.compaction.min.size(通常设置成和memstore flush的值一样)与hbase.hstore.compaction.max.size(通常设置为Long.MAX_VALUE)会进一步限制参与compact的文件。与minor compaction不同, major compact会把所有的store里面的文件合成一个大文件,compact的类型在检查阶段就已经确定好了。以下几种情况会触发检查compaction,1、shell中的compact或者major_compact请求 2、memstore flush后 3、请求相应的api中的majorCompact( ) 4、后台线程轮询,时间由hbase.server.thread.wakefrequency和hbase.server.thread.wakefrequency,multiplier相乘所得。假如你在shell中请求了major_compact,或者请求了api中的majorCompact,都会强制执行majorCompact,在其它情况下,rs会依据hbase.hregion.majorcompaction来判断是否应该执行major。

split和compact相对来说复杂点,我找时间再把源码拉出来分析下吧。说到源码,我把源码中compact线程中比较重要的一段注释提一下:
合并storefiles,这可能需要一点时间。在这段时间时间中store还是能够正常提供服务的,它还是能从storefile中取值,也能从memstore中写入新的storefile。直到新的合并完的storefile已经全部写到硬盘了,原来的storefiles才会删掉。





你可能感兴趣的:(hbase)