hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject Re: Why does the default hbase.hstore.compactionThreshold is 3?
Date Wed, 07 Apr 2010 19:11:40 GMT
I recommend reading the Bigtable paper to learn more about these
architectural things.


On 4/7/10 8:32 AM, "ChingShen" <chingshenchen@gmail.com> wrote:

> Thanks, JG
> 
>    As you mentioned at HBASE-2375, if we make decision to split based on
> aggregate size of all StoreFiles, and compactionThreshold is 5, does it mean
> that we don't need to do compaction forever?
> and please allow me to ask a silly question about compaction, why do we need
> the minor/major compaction in HBase? what's advantages of the minor/major
> compaction? speed up for read operations?
> 
> Thanks in advance.
> 
> Shen
> 
> On Wed, Apr 7, 2010 at 2:06 PM, Jonathan Gray <jgray@facebook.com> wrote:
> 
>> Shen,
>> 
>> You are right.  Currently the default flush size is 64MB, the
>> compactionThreshold is 3, and the splitSize/max.filesize is 256MB.  So we
>> end up compacting into a 192MB file when filling an empty region.
>> 
>> Take a look at HBASE-2375 (
>> https://issues.apache.org/jira/browse/HBASE-2375).  That issue deals with
>> changing some of this behavior as well as the defaults.
>> 
>> JG
>> 
>> 


Mime
View raw message