hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Daniel Cryans <jdcry...@apache.org>
Subject Re: HBase growing after issuing alter command with TTL and COMPRESSION
Date Tue, 18 Oct 2011 17:46:36 GMT
First thing about TTL, it's specified in seconds (whereas everything else in
HBase is ms) so watch out for that.

Regarding the size of your table, what you are asking is hard to answer
without having access to your machine. What actually grew? The store files?
Or is new store files due to the flushed memstores when the table was
disabled? I can't say.

You could try issuing a major compaction from the shell and then look at the
region server web ui to see if the store file sizes are shrinking. They
should, or maybe you aren't measuring the right thing, hard to tell.

Hope this helps a little,


On Tue, Oct 18, 2011 at 12:12 AM, Joel Halbert <joel@su3analytics.com>wrote:

> I have a stand alone instance of HBase (no hadoop) running on a single
> machine.
> It was originally at 32G, after updating some of the column definitions
> from the shell:
> alter 'table', {NAME =>'mycol', TTL => <two_months>}
> alter 'table', {NAME =>'mycol', COMPRESSION => 'GZ'}
> The data store has now grown from 32G to 51G (not caused by new data!).
> I'd like to understand why running the alter command has caused this,
> and when will it shrink again? Most of the data in the table is older
> than the TTL I have specified and so I was expecting it to shrink pretty
> soon, at the next major compaction. As this was ~ 24 hours ago I'm
> surprised it's not yet happened.
> Thanks,
> Joel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message