HBase Block Cache的重要实现细节和In-Memory Cache的特点

                注:本文基于HBase 0.94.1的源码进行分析。本文原文连接: http://blog.csdn.net/bluishglc/article/details/21516067,转载请著明出处!

每load一个block到cache时,都会检查当前cache的size是否已经超过了“警戒线”,这个“警戒线”是一个规定的当前block cache总体积占额定体积的安全比例,默认该值是0.85,即当加载了一个block到cache后总大小超过了既定的85%就开始触发异步的evict操作了。

evict的逻辑是这样的:遍历cache中的所有block,根据它们所属的级别(single,multi,in-memory)分拨到三个优先级队列中,队头元素是最旧(最近访问日间值最小)的那个block。对这个三队列依次驱逐对头元素,释放空间。

所以说:in-memory的block与其他类型的block并无本质上的不同,它不会长久驻留cache而不被逐出cache, 当不断有新的in-memory的block被访问,而现有in-memory cache已达到上限时,旧的in-memory block就会被替换出去,除非,所有in-memory的block的总体积小于in-memory cache。

但是in-memory的block确实不同于其他两种block的地方在于它的这个“in-memory”特征是静态指定的(在column family上设置),不会像其他两种cache会因访问频率而发生改变,这就决定了它的独立性,另外两种block访问次数再多也不会被放到in-memory的区段里去,in-memory的block不管是第几次访问,总是被放置到in-memory的区段中。

从in-memory cache的这些特性上来看,需要特别强调的是:

1. 标记IN_MEMORY=>'true'的column family的总体积最好不要超过in-memory cache的大小(in-memory cache = heap size * hfile.block.cache.size * 0.85 * 0.25),特别是当总体积远远大于了in-memory cache时,会在in-memory cache上发生严重的颠簸。

2. 换个角度再看,普遍提到的使用in-memory cache的场景是把元数据表的column family声明为IN_MEMORY=>'true。实际上这里的潜台词是:元数据表都很小。其时我们也可以大胆地把一些需要经常访问的,总体积不会超过in-memory cache的column family都设为IN_MEMORY=>'true'从而更加充分地利用cache空间。就像前面提到的,普通的block永远是不会被放入in-memory cache的,只存放少量metadata是对in-memory cache资源的浪费(未来的版本应该提供三种区段的比例配置功能)。           

猜你喜欢

转载自blog.csdn.net/qq_44919253/article/details/89520273
今日推荐