You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Jean-Marc Spaggiari <je...@spaggiari.org> on 2015/04/10 16:36:15 UTC

Re: Nondeterministic outcome based on cell TTL and major compaction event order

Hum. Good catch. Maybe when we expire the cell when need to check
configured number of versions and place a delete tombstone to replace the
expired cell? That works when version = 1. But what when version is
greater? I mean, what should be a correct behavior?

JM
Le 2015-04-10 07:27, "Cosmin Lehene" <cl...@adobe.com> a écrit :

> 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
>
>
>
>
>