Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 22 Sep 2016 08:20:20 +0000 (UTC)
From: "Phil Yang (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12976049.1465216605000.635743.1474532420848@Atlassian.JIRA>
In-Reply-To: <JIRA.12976049.1465216605000@Atlassian.JIRA>
References: <JIRA.12976049.1465216605000@Atlassian.JIRA> <JIRA.12976049.1465216605163@arcas>
Subject: [jira] [Updated] (HBASE-15968) MVCC-sensitive semantics of versions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 22 Sep 2016 08:20:23 -0000


     [ https://issues.apache.org/jira/browse/HBASE-15968?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Yang updated HBASE-15968:
------------------------------
    Attachment: HBASE-15968-v4.patch

Fix the bug for raw scan(use normal semantics directly), and add a test.=20
Fix reviews
Fix findbugs warnings

> MVCC-sensitive 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
>         Attachments: HBASE-15968-v1.patch, HBASE-15968-v2.patch, HBASE-15=
968-v3.patch, HBASE-15968-v4.patch
>
>
> In HBase book, we have a section in Versions called "Current Limitations"=
 see 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. =
See HBASE-2256. Remember that a delete writes a tombstone, which only disap=
pears after then next major compaction has run. Suppose you do a delete of =
everything =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 max=
imum-versions setting of 2. So when getting all versions, only the values a=
t t2 and t3 will be returned. But if you delete the version at t2 or t3, th=
e one at t1 will appear again. Obviously, once a major compaction has run, =
such behavior will not be the case anymore=E2=80=A6=E2=80=8B (See Garbage C=
ollection in Bending time in HBase.)
> {quote}
> These limitations result from the current implementation on multi-version=
s: we only consider timestamp, no matter when it comes; we will not remove =
old 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 (VERSIONS i=
n cf's conf), it will never be seen any more.
> Some examples for understanding:
> (delete t<=3D3 means use Delete.addColumns to delete all versions whose t=
s is not greater than 3, and delete t3 means use Delete.addColumn to delete=
 the version whose ts=3D3)
> case 1: put t2 -> put t3 -> delete t<=3D3 -> put t1, and we will get t1 b=
ecause the put is after delete.
> case 2: maxversion=3D2, put t1 -> put t2 -> put t3 -> delete t3, and we w=
ill always get t2 no matter if there is a major compaction, because t1 is m=
asked when we put t3 so t1 will never be seen.
> case 3: maxversion=3D2, put t1 -> put t2 -> put t3 -> delete t2 -> delete=
 t3, and we will get nothing.
> case 4: maxversion=3D3, put t1 -> put t2 -> put t3 -> delete t2 -> delete=
 t3, 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 =
latest version and it can be read.
> case 6:maxversion=3D2, put t3->put t2->put t1, and we will get t3+t2 just=
 like what we can get now, ts is still the key of versions.
> Different VERSIONS may result in different results even the size of resul=
t is smaller than VERSIONS(see case 3 and 4).  So Get/Scan.setMaxVersions w=
ill be handled at end after we read correct data according to CF's  VERSION=
S setting.
> The semantics is different from the current HBase, and we may need more l=
ogic to support the new semantic, so it is configurable and default is disa=
bled.


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