HBase Region的定位

触发region flush的因素有很多,如手动触发,memstore压力触发,memstore到达限制触发,flush时间触发等. regionserver的flush由 flush实际操作步骤为 1.获得region写锁,将region的所有store执行prepare,产生snapshort,释放region写锁 2.将region的所有store执行flushcache,将数据写入hdfs中的一个或多个临时文件中 3.将临时文件移到region/store相应的目录下,删除memstor

Region Server的整体架构 本文主要介绍Region的整体架构,后续再慢慢介绍region的各部分具体实现和源码 RegionServer逻辑架构图 RegionServer职责 1.      监听协作,通过zk来侦听master.meta位置.集群状态等信息的变化,更新本地数据. 2.      管理region的offline.online.open.close等操作,这些操作是和hmaster配合这来做的,region的状态有如下这些 offline.opening.open.

Nosql = Not only SQLmongodb:我觉得定位是取代关系型数据库,想当一个主流数据库.因为他有非结构化.方便扩充字段.写性能优于mysql.万事万物有利有弊,mongodb的内存型缓存内容,让其速度飞快,带来内存率多,掉电数据问题等,加上自身代码还有很多bug带来不如老牌关系型数据库稳定,特别是在主从等分布式环境,其设计也带来诸多问题.redis:是一个小而美的数据库,主要用在key-value 的内存缓存,读写性能极佳,list,set,hash等几种简单结构使得使用也很简

现象描述:某个regionserver服务挂掉后,此节点的Regions为0. 重启及数据恢复过程如下:() 切记在hadoop用户下: 第一步启动regionserver /hbaseStallDir/bin/graceful_stop.sh 192.168.5.164 /hbaseStallDir/bin/hbase-daemon.sh start regionserver /app/cloud/hadoop/bin/hadoop-daemon.sh start datanode 第二部:启

http://hbase.apache.org/book.html#ops.capacity.regions.count In production scenarios, where you have a lot of data, you are normally concerned with the maximum number of regions you can have per server. too many regions has technical discussion on th

hbase 0.94.0版本中,对于region的split方式引入了一个非常方便的SplitPolicy,通过这个SplitPolicy,可以主动的干预控制region split的方式.在org.apache.Hadoop.hbase.regionserver包中,可以找到这么几个自带的splitPolicy: ConstantSizeRegionSplitPolicy, IncreasingToUpperBoundRegionSplitPolicy, and KeyPrefixRegion

先来一张大图. Hbase上Regionserver的内存分为两个部分,一部分作为Memstore,主要用来写:另外一部分作为BlockCache,主要用于读数据:这里主要介绍写数据的部分,即Memstore.当RegionServer(RS)收到写请求的时候(writerequest),RS会将请求转至相应的Region.每一个Region都存储着一些列(a set of rows).根据其列族的不同,将这些列数据存储在相应的列族中(Column Family,简写CF).不同的CF中的数据存

很长一段时间以来,一个region同一时间只能在一台RS(Region Server)中打开.如果一个region同时在多个RS上打开,就是multi-assign问题,会导致数据不一致甚至丢数据的情况,这是要避免和解决的.对于正常情况而言,region本质上是单点服务的,当RS宕机时,这个RS上的region无法提供服务,直到他们在另外的RS上重新上线为止.我们首先讨论这种单点服务会导致哪些问题,然后,看看有什么解决方案. region单点导致的问题 从正常和异常两个方面对region单点可能

1  hbase hbck -repair 强制修复 如果ok就可以 2 不ok,找到hdfs上对应的该表位置,删除,之后在使用hbase hbck -repair 解决过程: 第一次,使用了方法二,然后解决了问题(自己可以查其他博客,有很多这样的博客文章) 第二次,过几天又出现了这种情况,然后用方法1直接修复成功(总结优先使用方法1 ,不行的话,再用方法2强制暴力解决) 产生原因: 1 我使用了Phoenix,然后同时有读和写操作,导致了HBASE不稳定,再加上机器配置不高 2 之后调整了读写