本篇文章给大家分享的是有关怎么理解HBase1.x 读缓存BlockCache,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。缓存对于任何一个数据库都非常重要,如果有条件允许,我们更愿意把所有的数据都缓存到内存中,就不存在任何的磁盘IO,但对于大数据来说缓存所有数据几乎是不可能的,基于二八法则,我们80%的业务请求都集中在20%的数据里面,如果把这20%的数据缓存到内存中,数据库的性能将会有极大的提升。HBase上Regionserver的内存分为两个部分:一部分作为Memstore,主要用来写;另外一部分作为BlockCache,主要用于读。1)写请求会先写入Memstore,Regionserver会给每个HStore提供一个Memstore,当Memstore满128MB以后,此时当前的HRegion中所有的MemStore会Flush到HDFS中。当一个regionserver中的所有MemStore的大小总和超过了hbase.regionserver.global.memstore.upperLimit
的大小,默认40%的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中,Flush顺序是MemStore大小的倒序,直到总体的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit
,默认38%的内存使用量。2)读请求先到Memstore中查数据,查不到就到BlockCache中查,再查不到就会到磁盘上读,并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略,因此BlockCache达到上限heapsize * hfile.block.cache.size * 0.85
后,会启动淘汰机制,淘汰掉最老的一批数据。一个Regionserver上有一个BlockCache和N个Memstore,它们的大小之和不能大于等于heapsize * 0.8
,否则HBase不能正常启动。为了高效获取数据,HBase设置了BlockCache机制,内存中缓存block,Block大体来分为两类,一类是JVM的heap内存,一类是heap off内存;第一类的cache策略叫做LRUCache,第二类Cache策略有SlabCache以及Bu 香港云主机cketCache两类;BlockCache是Region Server级别的,一个Region Server只有一个Block Cache,在Region Server启动的时候完成Block Cache的初始化工作。到目前为止,HBase先后实现了3种Block Cache方案,LRUBlockCache是最初的实现方案,也是默认的实现方案;HBase 0.92版本实现了第二种方案SlabCache,见HBASE-4027
;HBase 0.96之后官方提供了另一种可选方案BucketCache,见HBASE-7404
。BlockCache在HBase中所处的位置如下图中所示:Least-Recently-Used,HBase默认的BlockCache实现方案,LRU缓存把最近最少使用的数据移除,让给最新读取的数据。而往往最常读取的,也是读取次数最多的,所以,利用LRU缓存,我们能够提高系统的性能。LRUBlockCache将缓存分为三块:single-access区、mutil-access区、in-memory区,分别占到整个BlockCache大小的25%、50%、25%。single-access 优先级:当一个数据块第一次从HDFS读取时,它会具有这种优先级,并且在缓存空间需要被回收(置换)时,它属于优先被考虑范围内。它的优点在于:一般被扫描(scanned)读取的数据块,相较于之后会被用到的数据块,更应该被优先清除mutil-access优先级:如果一个数据块,属于Single Access优先级,但是之后被再次访问,则它会升级为Multi Access优先级。在缓存里的内容需要被清除(置换)时,这部分内容属于次要被考虑的范围in-memory-access优先级:表示数据可以常驻内存,一般用来存放访问频繁、数据量小的数据,比如元数据,用户也可以在建表的时候通过设置列族属性IN-MEMORY= true将此列族放入in-memory区,两种具体实现方式如下:a.在Java中可以调用: HColumnDescriptor.setInMemory(true);b.在hbase shell 中创建或修改一个表时,可以使用 IN_MEMORY => true,例如:create ‘t’, {NANME => ‘f’, IN_MEMORY => ‘true’}弊端:使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多,从而可能引发臭名昭著的Full GC,触发可怕的’stop-the-world’暂停;尤其在大内存条件下,一次Full GC很可能会持续较长时间,甚至达到分钟级别。大家知道Full GC是会将整个进程暂停的(称为stop-the-wold暂停),因此长时间Full GC必然会极大影响业务的正常读写请求。在1.0版本后被废弃了(HBASE-11307);内部结构是划分为两块,80%和20%;缓存的数据如小于等于blocksize,则放在在前面的区域(80%区域);如果block大于1x但是小于2x将会放置到后面区域(20%区域);如果大于2x则不进行缓存。和LRUBlockCache相同,SlabCache也使用Least-Recently-Used算法对过期Block进行淘汰。和LRUBlockCache不同的是,SlabCache淘汰Block的时候只需要将对应的bufferbyte标记为空闲,后续cache对其上的内存直接进行覆盖即可。线上集群环境中,不同表不同列族设置的BlockSize都可能不同,很显然,默认只能存储两种固定大小Block的SlabCache方案不能满足部分用户场景,比如用户设置BlockSize = 256K,简单使用SlabCache方案就不能达到这部分Block缓存的目的。因此HBase实际实现中将SlabCache和LRUBlockCache搭配使用,称为DoubleBlockCache。一次随机读中,一个Block块从HDFS中加载出来之后会在两个Cache中分别存储一份;缓存读时首先在LRUBlockCache中查找,如果Cache Miss再在SlabCache中查找,此时如果命中再将该Block放入LRUBlockCache中。弊端:经过实际测试,DoubleBlockCache方案有很多弊端。比如SlabCache设计中固定大小内存设置会导致实际内存使用率比较低,而且使用LRUBlockCache缓存Block依然会因为JVM GC产生大量内存碎片。因此在HBase 0.98版本之后,该方案已经被不建议使用。这种策略是阿里设计出来的 CDH集群用的这种策略,BucketCache通过配置可以工作在三种模式下:heap,offheap和file。无论工作在那种模式下,BucketCache都会申请许多带有固定大小标签的Bucket,和SlabCache一样,一种Bucket存储一种指定BlockSize的数据块,但和SlabCache不同的是,BucketCache会在初始化的时候申请14个不同大小的Bucket,而且即使在某一种Bucket空间不足的情况下,系统也会从其他Bucket空间借用内存使用,不会出现内存使用率低的情况。接下来再来看看不同工作模式,heap模式表示这些Bucket是从JVM Heap中申请,offheap模式使用DirectByteBuffer技术实现堆外内存存储管理,而file模式使用类似SSD的高速缓存文件存储数据块。弊端:实际实现中,HBase将BucketCache和LRUBlockCache搭配使用,称为CombinedBlockCache。和DoubleBlockCache不同,系统在LRUBlockCache中主要存储Index Block和Bloom Block,而将Data Block存储在BucketCache中。因此一次随机读需要首先在LRUBlockCache中查到对应的Index Block,然后再到BucketCache查找对应数据块。BucketCache通过更加合理的设计修正了SlabCache的弊端,极大降低了JVM GC对业务请求的实际影响,但也存在一些问题,比如使用堆外内存会存在拷贝内存的问题,一定程度上会影响读写性能。以上就是怎么理解HBase1.x 读缓存BlockCache,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注开发云行业资讯频道。
这篇文章主要介绍了电脑重装系统后开不了机的解决方法,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。原因分析电脑重装后开不了机,究其原因是系统重装失败。在重装系统的过程中,如果不小心中断了系统安装过…
免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。