博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
HBase2.0新特性之In-Memory Compaction
阅读量:5842 次
发布时间:2019-06-18

本文共 2240 字,大约阅读时间需要 7 分钟。

In-Memory Compaction是HBase2.0中的重要特性之一,通过在内存中引入LSM结构,减少多余数据,实现降低flush频率和减小写放大的效果。本文根据HBase2.0中相关代码以及社区的、,介绍In-Memory Compaction的使用和实现原理。

原理

概念和数据结构

In-Memory Compaction中引入了MemStore的一个新的实现类 CompactingMemStore 。顾名思义,这个类和默认memstore的区别在于实现了在内存中compaction。

CompactingMemStore中,数据以 segment 作为单位进行组织,一个memStore中包含多个segment。数据写入时首先进入一个被称为 active 的segment,这个segment是可修改的。当active满之后,会被移动到 pipeline 中,这个过程称为 in-memory flush 。pipeline中包含多个segment,其中的数据不可修改。CompactingMemStore会在后台将pipeline中的多个segment合并为一个更大、更紧凑的segment,这就是compaction的过程。

如果RegionServer需要把memstore的数据flush到磁盘,会首先选择其他类型的memstore,然后再选择CompactingMemStore。这是因为CompactingMemStore对内存的管理更有效率,所以延长CompactingMemStore的生命周期可以减少总的I/O。当CompactingMemStore被flush到磁盘时,pipeline中的所有segment会被移到一个snapshot中进行合并然后写入HFile。
image

在默认的MemStore中,对cell的索引使用ConcurrentSkipListMap,这种结构支持动态修改,但是其中存在大量小对象,内存浪费比较严重。而在CompactingMemStore中,由于pipeline里面的数据是只读的,就可以使用更紧凑的数据结构来存储索引,减少内存使用。代码中使用CellArrayMap结构来存储cell索引,其内部实现是一个数组。

image

compaction策略

当一个active segment被flush到pipeline中之后,后台会触发一个任务对pipeline中的数据进行合并。合并任务会对pipeline中所有segment进行scan,将他们的索引合并为一个。有三种合并策略可供选择:Basic,Eager,Adaptive。

Basic compaction策略和Eager compaction策略的区别在于如何处理cell数据。Basic compaction不会清理多余的数据版本,这样就不需要对cell的内存进行拷贝。而Eager compaction会过滤重复的数据,并清理多余的版本,这意味着会有额外的开销:例如如果使用了MSLAB存储cell数据,就需要把经过清理之后的cell从旧的MSLAB拷贝到新的MSLAB。basic适用于所有写入模式,eager则主要针对数据大量淘汰的场景:例如消息队列、购物车等。
Adaptive策略则是根据数据的重复情况来决定是否使用Eager策略。在Adaptive策略中,首先会对待合并的segment进行评估,方法是在已经统计过不重复key个数的segment中,找出cell个数最多的一个,然后用这个segment的numUniqueKeys / getCellsCount得到一个比例,如果比例小于设定的阈值,则使用Eager策略,否则使用Basic策略。

使用

配置

2.0中,默认的In-Memory Compaction策略为basic。可以通过修改hbase-site.xml修改:

hbase.hregion.compacting.memstore.type

也可以单独设置某个列族的级别:

create ‘
’, {NAME => ‘
’, IN_MEMORY_COMPACTION => ‘
’}

性能提升

社区的博客中给出了两个不同场景的测试结果。使用YCSB测试工具,100-200 GB数据集。分别在key热度符合Zipf分布和平均分布两种情况下,测试了只有写操作情况下写放大、吞吐、GC相比默认memstore的变化,以及读写各占50%情况下尾部读延时的变化。

测试结果如下表:

 

key热度分布 写放大 吞吐 GC 尾部读延时
Zipf 30%↓ 20% ↑ 22% ↓ 12% ↓
平均分布 25%↓ 50% ↑ 36% ↓ 无变化

转自:https://yq.aliyun.com/articles/573702

 


交流

如果大家对HBase有兴趣,致力于使用HBase解决实际的问题,欢迎加入Hbase技术社区群交流:

微信HBase技术社区群,假如微信群加不了,可以加秘书微信: SH_425 ,然后邀请您。

 

 

​  钉钉HBase技术社区群

转载于:https://www.cnblogs.com/hbase-community/p/8879871.html

你可能感兴趣的文章
前端应该掌握的网络知识(1)
查看>>
单独管理image
查看>>
<context:annotation-config> 跟 <context:component-scan>诠释及区别
查看>>
写单元测试的好处(转)
查看>>
本地工程提交github
查看>>
uCOS:时钟节拍代码追踪
查看>>
linux操作系统cp命令
查看>>
QT的一个奇怪问题,设置了Qt::Tool后,点击弹出对话框的确定取消按钮,程序直接退出。...
查看>>
GBK转utf-8,宽字符转窄字符
查看>>
第十二周编程总结
查看>>
【MySQL】4、Select查询语句
查看>>
(转)关于SimpleDateFormat安全的时间格式化线程安全问题
查看>>
【工具】switchhost
查看>>
Linux之tomcat日志管理
查看>>
Intent跳转传list集合
查看>>
Codeforces VK Cup 2015 A.And Yet Another Bracket Sequence(后缀数组+平衡树+字符串)
查看>>
spring+springMvc+struts的SSH框架整合
查看>>
二叉树 - 已知前中,求后序遍历
查看>>
逆序数技巧 - 牛客
查看>>
Linux 内核
查看>>