HBase Flush 机制

定义在 hbase-site.xml 文件

## Count of RPC Listener instances spun up on RegionServers
## 一个 region server 可以同时处理的请求个数 (包括增删查改), 超过这个值的请求会在 Queue 里排队
hbase.regionserver.handler.count : 30

## 以下几个参数是关于 MemStore 刷入 HFile 的机制
##   1. MemStore 超过 128M 时刷入 (默认每 10 秒检查一次)
##   2. MemStore 超过 4 * 128M 时 block 更新 MemStore 的操作,并强制做 flush,这是为了处理出现 spike 的场景
##   3. 当 RegionServer 所有 MemStore 的总大小超过 RegionServer 的 heap 的 40% 时,
##      会 block 所有更新 MemStore 的操作,并强制做 flush,从占内存大的 MemStore 开始
##   4. 当 RegionServer 所有 MemStore 的总大小超过 RegionServer 的 heap 的 40% * 0.95 时,
##      选择占用内存大的 MemStore 阻塞更新操作,并进行 flush
##   5. 当 WAL(Write-ahead log,预写日志) 数量,也就是 HLog 文件数据大于 32 时,
##      会进行 flush,从最旧的 HLog 文件对应的 Region 开始
##   6. Region 的数据更新超过一定阈值 (30 millions) 时 flush
##   7. 定期 (1 小时) 进行 flush
##   8. 也可以手动刷入,HBase shell -> flush "TableName"

## if a MemStore exceed 128M, flush to HDFS HFile
## can flush in hbase shell manaully : flush ‘TABLENAME‘
hbase.hregion.memstore.flush.size : 134217728 (128M)

## block update(write,insert,delete) action if a MemStore exceed flush.size*multiplier, for spike traffic scenario
## throw RegionTooBusyException
hbase.hregion.memstore.block.multiplier : 4

## Maximum size of all memstores in a region server before new updates are blocked and flushes are forced
hbase.regionserver.global.memstore.size : 0.4

## Maximum size of all memstores in a region server before flushes are forced
hbase.regionserver.global.memstore.size.lower.limit : 95% of hbase.regionserver.global.memstore.size

## If more than this many logs, force flush of oldest region to oldest edit goes to disk.
hbase.regionserver.maxlogs : 32

## force a flush if there are already enough changes for one region in memstore
hbase.regionserver.flush.per.changes : 30000000

## Maximum amount of time an edit lives in memory before being automatically flushed
hbase.regionserver.optionalcacheflushinterval : 3600000 (1 hour)

## Maximum HStoreFile size in HDFS
## hadoop fs -du -s -h /apps/hbase/data/data/default/REGULARDATAPHOENIXTABLE/*
hbase.hregion.max.filesize : 10737418240 (10G)

## The time (in miliseconds) between ‘major‘ compactions of all HStoreFiles in a region
## 多久做一次 major compact
hbase.hregion.majorcompaction : 604800000 (7 days)

## Max number of HStoreFiles to compact per ‘minor‘ compaction
## 一次 minor compact 最多操作多少个 HFile
hbase.hstore.compaction.max : 10

原文地址:https://www.cnblogs.com/moonlight-lin/p/12695397.html

时间: 2024-10-11 20:45:20

HBase Flush 机制的相关文章

hibernate flush 机制

针对昨天同事遇到的hibernate的问题.算是hibernate最基本的东西.具了解,这个问题很多人遇到过,也很常见,却遇到了还经常会懵了. 为了加深印象,知其然,知其所以然. 之后单纯用原始的Hibernate框架做了一些验证,并且打开执行SQL打印输出台的,得出的结论: 前提是在同一事务中间: 1.利用sql语句, session.createSQLQuery(sql).executeUpdate();进行插入,输出台打印出sql插入语句: 再利用sql语句,进行session.creat

HBase 手动 flush 机制梳理

对应 HBase 版本0.94.1,对照了开源的版本和工作使用的某发行版 问题:在 HBase shell 里面输入 flush 'table_or_region_name'之后,发生了什么?具体的实现是怎么样的?对于现有的某个表,我如何在做操作之前估算 flush 执行的时间? 1. HBase shell 入口 HBase shell 使用 ruby 实现,在 putty 敲hbase shell,调用的是${HBASE_HOME}/bin/hbase这个 bash 脚本,根据shell这个

hbase寻址机制详解

2019/2/20 星期三 //参考链接为 : https://www.cnblogs.com/qingyunzong/p/8692430.html 系统如何找到某个row key(或者某个row key range(范围))所在的region big table 使用三层类似B+树的结构来保存region 位置第一层是保存zookeeper 里面的文件,它持有root region 的位置.第二层root region 是.META.表的第一个region 其中 保存了.META.z表 其它r

Hbase 写入机制详解与MVCC机制

Hregion.doMiniBatchMutation 内部实现 1.获取相关的锁,由于HBase要确保行一级的原子性,所以获取锁的时候获取的是整个rowkey的锁而不是单个cell的锁:也只有当至少获取一个锁的时候,这个方法才会继续,否则直接返回. 2.更新cell中的时间戳(timestamp)以及获取mvcc相关参数,其中timestamp(也可以叫做version)可以在客户端自己手动指定,所以在一致性上不能用来做参考,也许正是因此才会引入一个叫做sequenceId的概念(当然更多的用

HBase底下的存储机制

Split机制:可以理解为HDFS上Block一分二的情况.每个Table一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阀值的时候,Hregion就会等分会两个新的Hregion.当table中的行不断增多,就会有越来越多的Hregion. 非实时,定期触发. HRegion是Hbase中分布式存储和负载均衡的最小单元,相当于HDFS的Block. Flush机制: HStore存储是HBase存储的核心,其中由两部分组成,MemStore和StoreFile

HBase 事务和并发控制机制原理

作为一款优秀的非内存数据库,HBase和传统数据库一样提供了事务的概念,只是HBase的事务是行级事务,可以保证行级数据的原子性.一致性.隔离性以及持久性,即通常所说的ACID特性.为了实现事务特性,HBase采用了各种并发控制策略,包括各种锁机制.MVCC机制等.本文首先介绍HBase的两种基于锁实现的同步机制,再分别详细介绍行锁的实现以及各种读写锁的应用场景,最后重点介绍MVCC机制的实现策略. HBase同步机制 HBase提供了两种同步机制,一种是基于CountDownLatch实现的互

HBase数据管理/寻址机制以及行键设计

1.hbase对数据的管理机制 1.1.hbase中的表很大---bigtable,都是分布式存储在集群的各个regionserver上    1.2.分布式存储时,需要对表进行切分,首先是按行切分成若干个hregion    1.3.表的每一个hregion都会被一个regionserver所管理    1.4.每一个hregion随着插入数据的增多,一旦达到一个阈值,会被regionserver分裂成两个    1.5.在一个hregion内部还会被按照列族切分成若干个store单元    

HBase – Memstore Flush和flush shell操作 深度解析

//memstore flush机制 和flush shell命令刷新//Memstore是HBase框架中非常重要的组成部分之一,是HBase能够实现高性能随机读写至关重要的一环.深入理解Memstore的工作原理.运行机制以及相关配置,对hbase集群管理.性能调优都有着非常重要的帮助. 写机制(大约)1.HBase是基于LSM-Tree模型的,2.所有的数据更新插入操作都首先写入Memstore中(同时会顺序写到日志HLog中),3.达到指定大小之后再将这些修改操作批量写入磁盘,生成一个新

HBase学习总结(3):HBase的数据模型及工作机制

一.HBase数据模型 HBase模式里的逻辑实体包括: (1)表(table):HBase用表来组织数据.表名是字符串(String),由可以在文件系统路径里使用的字符组成. (2)行(row):在表里,数据按行存储.行由行键(rowkey)唯一标识.行键没有数据类型,总是视为字节数组byte []. (3)列族(column family):行里的数据按照列族分组,列族也影响到HBase数据的物理存放,因此,它们必须事前定义并且不轻易修改.表中每行拥有相同列族,尽管行不需要在每个列族里存储数