hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kireet <kir...@feedly.com>
Subject Re: HBase load problems
Date Thu, 17 Oct 2013 12:56:26 GMT
Sorry for the confusion, I was trying to get at if it would be a large 
operation or there would be a large disruption right after increasing 
the max region size. It sounds like it wouldn't.

Getting back to the original question, if we do 90%+ of our reads/writes 
to very recent data, would it make sense to keep that in a separate 
table? It seems like that may keep things more optimized, the block 
cache would be more efficient, compactions would run quicker with much 
less data on the 'recent data' table and perhaps less often on the 
'older data' table(s), etc.

On 10/17/13 12:52 AM, Stack wrote:
> On Wed, Oct 16, 2013 at 6:26 PM, Kireet <kireet@feedly.com> wrote:
>> is there a downside to going to larger regions?
> Generally we see pluses (See Bigger Regions in
> http://hbase.apache.org/book/important_configurations.html for the latest
> scripture on the topic).  Downsides would be something like compactions run
> longer (coarsely, same overall work, just takes longer to complete a region)
>> It looks like merge is a larger operation, so changing the config setting
>> would simply cause existing regions to grow to the larger value right?
>> Would the way to confirm this be to check compaction rates and also maybe
>> the size of store files in hdfs?
> I'm not sure I understand the question above Kireet.  You doing merges?
>   Yes, you can just change the configs on the cluster and regions will just
> grow (will need to rolling restart the cluster to pick up the config.)
> Please ask again what you would confirm.
> Thanks,
> St.Ack
> P.S. Feedly-fan here.

View raw message