I've had a similar question... perhaps the client promotes a compaction to "major" if:
a) the threshold for compaction is reached ( hbase.hstore.compactionThreshold ) or (and?) b) the maximum number of files to process in a "minor" compaction is high enough to result in all files being processed into one ( hbase.hstore.compaction.max ) Can someone confirm if this is correct, or if there are other factors to causing a major compaction that I am missing? Neil Yalowitz On Thu, Jan 26, 2012 at 10:06 AM, yonghu <[email protected]> wrote: > Hello Mikael, > > I think disabling the major compaction in the timed and client-issued > situation is not a problem. The problem is the size-based. From the > mailing list, it only talks about the situation of minor compaction > not major compaction, if I understand right. So, I want to know if > someone can tell me how to close the major compaction in size-based > situation. > > Thanks > > Yong > I saw the description which indicating the size of store file can also > trigger major compaction. > > On Thu, Jan 26, 2012 at 3:54 PM, Mikael Sitruk <[email protected]> > wrote: > > Yong hi > > > > As far as i know setting hbase.hregion.majorcompaction to 0 will disable > > the time based trigger only. > > Client are always able to invoke the major compact, no matter what is the > > value of the hbase.hregion.majorcompaction. > > > > Perhaps client invocation of compaction can me disabled with the security > > package. > > > > Anyway i'm digging into 0.92, I hope to get those insight soon. > > > > Mikael.S > > > > On Thu, Jan 26, 2012 at 4:39 PM, yonghu <[email protected]> wrote: > > > >> Thanks for your response. > >> > >> I knew that major compact can be triggered based on client, time and > >> size. In my situation, I have to close the functionality of major > >> compact. So, if I set the ‘hbase.hregion.majorcompaction’ into 0, it > >> will close all the three situations or I have to set it separately for > >> each case. BTW, my hbase version is 0.92. > >> > >> Thanks! > >> > >> Yong > >> > >> On Thu, Jan 26, 2012 at 3:09 PM, Mikael Sitruk <[email protected] > > > >> wrote: > >> > look at the thread http://search-hadoop.com/m/GHUWQ1xnbj21, it > explain a > >> > lot on major compaction and enhancement over versions > >> > > >> > Mikael.S > >> > > >> > > >> > On Thu, Jan 26, 2012 at 3:51 PM, Damien Hardy <[email protected]> > >> wrote: > >> > > >> >> Le 26/01/2012 14:43, yonghu a écrit : > >> >> > Hello, > >> >> > > >> >> > I read this blog http://outerthought.org/blog/465-ot.html. It > >> mentions > >> >> > that every 24 hours the major compaction will occur. My question is > >> >> > that if there are any other conditions which can trigger major > >> >> > compaction happening? For example, when the size of store file > reaches > >> >> > the threshold (I think this will cause minor compaction or region > file > >> >> > split, not major compaction, but not quite sure). > >> >> > > >> >> > Thanks! > >> >> > > >> >> > Yong > >> >> > >> >> Hello, > >> >> I think when there is massive delete on the table or change table > >> >> attribute like TTL (that is susseptible of remove a lot of > >> >> versions/rows) or COMPRESSION wich gain a lot of disk space on each > >> region. > >> >> > >> >> Cheers, > >> >> > >> >> -- > >> >> Damien > >> >> > >> >> > >> > > >> > > >> > -- > >> > Mikael.S > >> > > > > > > > > -- > > Mikael.S >
