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 <[email protected]> wrote:
is there a downside to going to larger regions?
Generally we see pluses (See 2.5.6.2 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.
