hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: Nondeterministic outcome based on cell TTL and major compaction event order
Date Fri, 10 Apr 2015 14:36:15 GMT
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" <clehene@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
>
>
>
>
>

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