On Wed, Mar 11, 2015 at 3:54 PM, Alex Baranau <[email protected]> wrote:
> 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) > They're not currently, but we'd like to see it :) https://issues.apache.org/jira/browse/HBASE-13103 On Wed, Mar 11, 2015 at 3:12 PM, Alex Baranau <[email protected]> > 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 <[email protected]> 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? > > > > > > >
