Hbase memstore 的刷写时机

HBase会在如下几种情况下触发flush操作,需要注意的是MemStore的最小flush单元是HRegion而不是单个MemStore。可想而知,如果一个HRegion中Memstore过多,每次flush的开销必然会很大,因此我们也建议在进行表设计的时候尽量减少ColumnFamily的个数。hbase官方文档总结的刷写时机有6种:

  1. Memstore级别限制:当Region中任意一个MemStore的大小达到了上限(hbase.hregion.memstore.flush.size,默认128MB),会触发Memstore刷新。
  2. Region级别限制:当Region中所有Memstore的大小总和达到了上限(hbase.hregion.memstore.block.multiplier hbase.hregion.memstore.flush.size,默认 2 128M = 256M),会触发memstore刷新。
  3. Region Server级别限制:当一个Region Server中所有Memstore的大小总和达到了上限(hbase.regionserver.global.memstore.upperLimit * hbase_heapsize,默认 40%的JVM内存使用量),会触发部分Memstore刷新。Flush顺序是按照Memstore由大到小执行,先Flush Memstore最大的Region,再执行次大的,直至总体Memstore内存使用量低于阈值(hbase.regionserver.global.memstore.lowerLimit * hbase_heapsize,默认 38%的JVM内存使用量)。
  4. 当一个Region Server中HLog数量达到上限(可通过参数hbase.regionserver.maxlogs配置)时,系统会选取最早的一个 HLog对应的一个或多个Region进行flush
  5. HBase定期刷新Memstore:默认周期为1小时,确保Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题,定期的flush操作有20000左右的随机延时。
  6. 手动执行flush:用户可以通过shell命令 flush ‘tablename’或者flush ‘region name’分别对一个表或者一个Region进行flush。 虽然总的会有6种,细分下flush的时机有三个:一个是单纯的put/delete引起了memstore的变化的,第二个是region的split,merge,compact引起region变化的,第三个是有一个定时线程轮询每一个region是否需要flush(PeriodiaMemStoreFlusher,是一个chore)。

第一个会在hbase的update时候发生,首先会调用checkResources()方法检查资源,这个checkResources()实际上就是检查HRegion的MemStore大小是否超过一定的阈值(hbase.hregion.memstore.flush.size),如果超过,则会调用requestFlush()方法发起对该HRegion的MemStore进行flush的请求,并抛出RegionTooBusyException异常,阻止该操作继续,后续将要讲的Delete、Append等数据更新操作也是如此,在开始执行操作前都会调用这个checkResources()方法来检查资源。而requestFlush方法核心的方法即是调用HRegion的flushcache方法。

第二个是region的splite/merge/compact,在做这些region级别的操作前,都会直接调用flushchache()方法(有关这个方法在上一篇文档中有详细分析),然后再执行操作。这个比较好理解,因为一个region根据CF对应了一系列的Memstore,当region发生变更时所对应的CF的Memstore肯定需要做相应调整,所以要持久化刷硬盘。一般这些过程在hmaster和zk的帮助下都进行的比较快。

第三个是PeriodMemStoreFlusher来定时的刷memstore。

这个定时任务也比较简单,就是定时去检查对应的region以及RegionServer的memstore是否到达了阈值然后去刷写。

需要注意的regionserver的刷写会阻塞整个rs的写,而且这时候很容易发生fullgc,这将很影响整个集群的性能,所以在hbase的文档中也建议,在业务低峰期进行手动刷写,保证不在业务高峰的时候触发memstore刷写条件而影响性能。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏美团技术团队

缓存那些事

前言 一般而言,现在互联网应用(网站或App)的整体流程,可以概括如图1所示,用户请求从界面(浏览器或App界面)到网络转发、应用服务再到存储(数据库或文件系统...

4614
来自专栏小勇DW3

常用的JVM调优参数总结汇总【随时查阅学习】

表示设置JVM启动内存的最大值为20M,必须以M为单位。将-Xmx和-Xms设置为一样可以避免JVM内存自动扩展。大的项目-Xmx和-Xms一般都要设置到10G...

864
来自专栏北京马哥教育

Redis 基础、高级特性与性能调优 | 一文看全

本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍。之后在性能调优等方面进行更深入的介绍和指导。 概述...

4696
来自专栏上善若水

L011Linux和androidNDK之socket出错情况的处理:Interrupted system call,Try again

L011Linux和androidNDK之socket出错情况的处理:Interrupted system call,Try again

912
来自专栏流媒体

Linux下Socket编程(四)——epoll的使用简介

相比于select,epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中,它是采用轮询来处理的,轮询的fd数目越多,...

712
来自专栏大闲人柴毛毛

深入理解JVM(六)——JVM性能调优实战

如何在高性能服务器上进行JVM调优? 为了充分利用高性能服务器的硬件资源,有两种JVM调优方案,它们都有各自的优缺点,需要根据具体的情况进行选择。 1. 采用...

2856
来自专栏QQ会员技术团队的专栏

从 0 实现一个延迟代理服务

部门会定期进行容灾演习,也期望能够验证到各个服务的\"最差服务能力\"。即验证被调出现较高延迟或者过载的时候,主调的服务能力是否符合预期。要想做这种演习,其核心...

1932
来自专栏Java架构沉思录

优雅实现延时任务之Redis篇

PS:这篇文章昨天已经推送过了,不过忘了标原创,今天标个原创再发一次,昨天看了的可以不用往下看了。

702
来自专栏QQ会员技术团队的专栏

从0实现一个延迟代理服务

需求背景: 后台业务逻辑类服务,其实现通常都会依赖其他外部服务,比如存储,或者其他的逻辑server。 有一类比较典型的问题: 假设主调方A是同步处理模型,有一...

2208
来自专栏黄日成的专栏

大话 Select、Poll、Epoll

提到select、poll、epoll相信大家都耳熟能详了,三个都是IO多路复用的机制,可以监视多个描述符的读/写等事件。

8.5K11

扫码关注云+社区