有人知道regionserver队列大小是什么意思吗?
根据doc的定义:
9.2.5. hbase.regionserver.compactionqueuesize压缩队列的大小。这是该区域内目标为压缩的门店数量。
它是存储(或存储文件)的数量?我听说regionserver有两个版本需要压缩。
我有一个任务,使用顺序键(非分布式)以热点样式写入数据。我在度量历史中发现,在某个时候,压缩队列大小为4。这在理论上是不可能的,因为我在任何时候都只有一个要写的存储(顺序键)。
然后我翻到日志,发现有任何关于队列大小大于0的提示:每个主要的压缩都会说“此选择在队列中0秒”
013-11-26 12:28:00778 info[regionserver60020-smallcompactions-1385440028938]regionserver.hstore:已完成mytable.key.md5的f1中3个文件的主要压缩。。。。md5….(尺寸=607.8 m),仓库总尺寸为645.8 m。此选择已在队列中0秒,执行时间为39秒。
更让人困惑的是:早期版本不是启用了多线程,只是将每个压缩作业分配给一个线程,这就是为什么存在压缩队列的原因?
可惜hbase文档中没有详细的解释。
1条答案
按热度按时间a1o7rhls1#
我不完全理解你的问题。但让我尽我所能来回答这个问题。
首先让我们来谈谈hbase的一些术语。来源
一
Region
在hbase中,定义为Rows
在两排钥匙之间。如果你有不止一个ColumnFamily
在你的Table
,你会得到一个Store
每ColumnFamily
每Region
. 每Store
会有一个MemStore
0或更多StoreFiles
存储文件是在刷新memstore时创建的。每隔一段时间,后台线程就会触发一次压缩,以控制文件的数量。压实有两种类型:主要压实和次要压实。当一个存储的目标是一个小的压缩,它也会拿起一些相邻的存储文件,并重写为一个。轻微压缩不会删除已删除/过期的数据。如果一个较小的压缩拾取了一个存储中的所有storefiles,它将被提升为一个较大的压缩。在主要压缩中,存储的所有存储文件都重写为一个存储文件。好 啊。。。那么什么是压缩队列?它是regionserver中已作为压缩目标的存储数。类似地,flush queue是等待flush的memstore数。
至于为什么可以异步执行时会有一个队列的问题,我不知道。在hbase邮件列表中,这将是一个很好的问题。它往往有更快的响应时间。
编辑:压缩队列不会占用regionserver 100%的资源。