Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Mon, 6 Jun 2016 12:37:21 +0000 (UTC)
From: "Phil Yang (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12976049.1465216605000.444.1465216641160@Atlassian.JIRA>
In-Reply-To: <JIRA.12976049.1465216605000@Atlassian.JIRA>
References: <JIRA.12976049.1465216605000@Atlassian.JIRA> <JIRA.12976049.1465216605163@arcas>
Subject: [jira] [Created] (HBASE-15968) Strong semantics of versions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 06 Jun 2016 12:37:24 -0000

Phil Yang created HBASE-15968:
---------------------------------

             Summary: Strong semantics of versions
                 Key: HBASE-15968
                 URL: https://issues.apache.org/jira/browse/HBASE-15968
             Project: HBase
          Issue Type: New Feature
            Reporter: Phil Yang
            Assignee: Phil Yang


In HBase book, we have a section in Versions called "Current Limitations" s=
ee http://hbase.apache.org/book.html#_current_limitations

{quote}
28.3. Current Limitations

28.3.1. Deletes mask Puts
Deletes mask puts, even puts that happened after the delete was entered. Se=
e HBASE-2256. Remember that a delete writes a tombstone, which only disappe=
ars after then next major compaction has run. Suppose you do a delete of ev=
erything =E2=87=90 T. After this you do a new put with a timestamp =E2=87=
=90 T. This put, even if it happened after the delete, will be masked by th=
e delete tombstone. Performing the put will not fail, but when you do a get=
 you will notice the put did have no effect. It will start working again af=
ter the major compaction has run. These issues should not be a problem if y=
ou use always-increasing versions for new puts to a row. But they can occur=
 even if you do not care about time: just do delete and put immediately aft=
er each other, and there is some chance they happen within the same millise=
cond.

28.3.2. Major compactions change query results
=E2=80=A6=E2=80=8Bcreate three cell versions at t1, t2 and t3, with a maxim=
um-versions setting of 2. So when getting all versions, only the values at =
t2 and t3 will be returned. But if you delete the version at t2 or t3, the =
one at t1 will appear again. Obviously, once a major compaction has run, su=
ch behavior will not be the case anymore=E2=80=A6=E2=80=8B (See Garbage Col=
lection in Bending time in HBase.)

{quote}

These limitations result from the current implementation on multi-versions:=
 we only consider timestamp, no matter when it comes; we will not remove ol=
d version immediately if there are enough number of new versions.=20

So we can get a stronger semantics of versions by two guarantees:
1, Delete will not mask Put that comes after it.
2, If a version is masked by enough number of higher versions (MAXVERSIONS)=
, it will never be seen any more.

Some examples for understanding:
(delete t<=3D3 means use Delete.addColumns to delete all versions whose ts =
is not greater than 3, and delete t3 means use Delete.addColumn to delete t=
he version whose ts=3D3)

case 1: put t2 -> put t3 -> delete t<=3D3 -> put t1, and we will get t1 bec=
ause the put is after delete.
case 2: maxversion=3D2, put t1 -> put t2 -> put t3 -> delete t3, and we wil=
l always get t2 no matter if there is a major compaction, because t1 is mas=
ked when we put t3 so t1 will never be seen.
case 3: maxversion=3D2, put t1 -> put t2 -> put t3 -> delete t2 -> delete t=
3, and we will get nothing.
case 4: maxversion=3D3, put t1 -> put t2 -> put t3 -> delete t2 -> delete t=
3, and we will get t1 because it is not masked.
case 5: maxversion=3D2, put t1 -> put t2 -> put t3 -> delete t3 -> put t1, =
and we can get t3+t1 because when we put t1 at second time it is the 2nd la=
test version and it can be read.
case 6:maxversion=3D2, put t3->put t2->put t1, and we will get t3+t2 just l=
ike what we can get now, ts is still the key of versions.

Different MAXVERSIONS may result in different results even the size of resu=
lt is smaller than MAXVERSIONS(see case 3 and 4).  So Get/Scan.setMaxVersio=
ns will be handled at end after we read correct data according to CF's  MAX=
VERSIONS setting.

The semantics is different from the current HBase, and we may need more log=
ic to support the new semantic, so it is configurable and default is disabl=
ed.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)