hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Baranau <alex.barano...@gmail.com>
Subject Re: Re: Re: Why can the capacity of a table with TTL grow continuously?
Date Wed, 11 Mar 2015 22:54:33 GMT
Quick question: have you by any chance noticed the region number to grow a
lot over the time of your measurements? Note that regions are not merged
automatically back if they shrink (incl. due to TTL) after being split (
http://hbase.apache.org/book.html#ops.regionmgt)

Alex Baranau
--
http://cdap.io - open source framework to build and run data applications on
Hadoop & HBase

On Wed, Mar 11, 2015 at 3:12 PM, Alex Baranau <alex.baranov.v@gmail.com>
wrote:

> Expired rows are also deleted on minor compaction. But, depending on the
> distribution of the writes you may have some regions that don't get any
> writes and hence their files will stay in "frozen" state without any
> compaction being triggerred on them, until major compaction is fired for
> that specific region or the whole table. Given that you reclaimed only a
> bit of space - part of that could be due to this..
>
> http://hbase.apache.org/book.html#ttl also
> mentions hbase.store.delete.expired.storefile config property - be sure to
> have it as true to delete the whole store files (unless files are deleted,
> they occupy space in hdfs).
>
> Alex Baranau
>
> http://cdap.io - open source framework to build and run data applications on
> Hadoop & HBase
>
> On Tue, Mar 10, 2015 at 9:15 PM, David chen <c77_cn@163.com> wrote:
>
>> Thanks lars,
>> I ever ran scan to test TTL for several times,  the data expired could
>> not be seen.
>> In my application scene, the capacity of everyday collecting data should
>> be almost similar. so the new collecting data should not be more than the
>> data expired.
>> Following your way, I forced a major compaction this morning, the space
>> reduced from 946G to 924G.
>> In order to reclaim the expired space, must force the major compaction?
>
>
>

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