Maybe we should just not counts the cells with TTL when counting for the versions? That way, what ever we do we always keep the initial value?
Better to have an extra version and have a consistent behaviour I think... JMS Le 2015-04-17 15:28, "Michael Segel" <michael_se...@hotmail.com> a écrit : > I think you misunderstood the question(s). > > How do you define the meaning of the TTL attribute? > > Is the TTL a special form of the delete tombstone? > > The reason I ask this is that if we look at your example you’ve stated > that if a compaction occurred prior to the end of life of cell 2, cell 1 > would be destroyed. > That doesn’t make sense as an expected result. > > This is why I am asking what is the defined contract of the TTL feature. > > Cell 1 should never be deleted. (unless you explicitly state the number of > versions to be 1 then it would be marked for deletion when you insert cell > 2.) > > Thx > > -Mike > > > > On Apr 13, 2015, at 6:12 PM, Cosmin Lehene <cleh...@adobe.com> wrote: > > > > The ambiguity seems to lie at the intersection of TTL and version > "garbage collection" during compactions. > > > > Major compactions can lead to nondeterministic results when multiple > versions are involved (slightly captured in the book > http://hbase.apache.org/book.html#versions and > http://www.ngdata.com/bending-time-in-hbase/ ) > > TTL expirations don't result in deletes (at least not in the classical > sense with a tombstone). > > > > Cosmin > > > > _______________________________________ > > From: Michael Segel <michael_se...@hotmail.com> > > Sent: Friday, April 10, 2015 8:35 AM > > To: dev@hbase.apache.org > > Subject: Re: Nondeterministic outcome based on cell TTL and major > compaction event order > > > > Interesting. > > There seems to be some ambiguity in what happens between a TTL and a > deletion. > > > > Is the TTL a delete or is it a separate type of function? > > > > That is to say when you inserted version 2 of the cell, did you intend > to just have version 2 exist for a little while and then default to version > 1 or did you mean that when you inserted version 2, you wanted to delete > everything prior to version 2 and then when version 2 expires, it then goes > away? > > > > The documentation isn’t clear on this point. > > > > To give you an example where you wouldn’t want to have the TTL on a cell > also delete prior versions… > > > > Suppose you’re storing map data in HBase. You have an attribute (speed) > associated to a road link. > > > > If the road is a 65 MPH highway, then the base speed (default speed) is > 65MPH. However if there’s construction planned for the road then you need > to reset the speed to 45 mph while there is construction. You know that > the construction is supposed to last X months, so you reset the speed limit > to 45 with a TTL on that cell version only. > > > > Another example is if you’re storing price for a given sku in a given > region of your retail chain. So you want to reduce the price by 20% for a > 2 week period. > > Again, you set that discount to live for 2 weeks with a TTL, then revert > back to original price. > > > > So I guess there should be a clarification as to what is intended for > the TTL to do? > > > > Does that make sense? > > > > > > > > > > > >> On Apr 10, 2015, at 9:26 AM, Cosmin Lehene <cleh...@adobe.com> wrote: > >> > >> I've been initially puzzled by this, although I realize how it's likely > as designed. > >> > >> > >> The cell TTL expiration and compactions events can lead to either some > (the older) data left or no data at all for a particular (row, family, > qualifier, ts) coordinate. > >> > >> > >> > >> Write (r1, f1, q1, v1, 1) > >> > >> Write (r1, f1, q1, v1, 2) - TTL=1 minute > >> > >> > >> Scenario 1: > >> > >> > >> If a major compaction happens within a minute > >> > >> > >> it will remove (r1, f1, q1, v1, 1) > >> > >> then after a minute (r1, f1, q1, v1, 2) will expire > >> > >> no data left > >> > >> > >> Scenario 2: > >> > >> > >> A minute passes > >> > >> (r1, f1, q1, v1, 2) expires > >> > >> Compaction runs.. > >> > >> (r1, f1, q1, v1, 1) remains > >> > >> > >> > >> This seems, by and large expected behavior, but it still seems > "uncomfortable" that the (overall) outcome is not decided by me, but by a > chance of event ordering. > >> > >> > >> I wonder we'd want this to behave differently (perhaps it has been > discussed already), but if not, it's worth a more detailed documentation in > the book. > >> > >> > >> What do you think? > >> > >> > >> Cosmin > >> > >> > >> > >> > > > > The opinions expressed here are mine, while they may reflect a cognitive > thought, that is purely accidental. > > Use at your own risk. > > Michael Segel > > michael_segel (AT) hotmail.com > > > > > > > > > > > > > > The opinions expressed here are mine, while they may reflect a cognitive > thought, that is purely accidental. > Use at your own risk. > Michael Segel > michael_segel (AT) hotmail.com > > > > > >
