Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 19 Mar 2016 12:47:33 +0000 (UTC)
From: "Mathias Herberts (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12951623.1458338814000.67453.1458391653440@Atlassian.JIRA>
In-Reply-To: <JIRA.12951623.1458338814000@Atlassian.JIRA>
References: <JIRA.12951623.1458338814000@Atlassian.JIRA>
 <JIRA.12951623.1458338814585@arcas>
Subject: [jira] [Commented] (HBASE-15487) Deletions done via
 BulkDeleteEndpoint make past data re-appear
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-15487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202745#comment-15202745 ] 

Mathias Herberts commented on HBASE-15487:
------------------------------------------

>From thinking more about it I guess the problem is probably related more to the way 'VERSIONS' is enforced than to the delete operation itself.

By setting 'VERSIONS' at table creation time it is expected that only that many versions of a cell will be retained. We assume 'VERSIONS' was set to 1 for the purpose of the present explanation.

The 'VERSIONS' parameter seems to be enforced during a Scan, even if the data being scanned is still in the memstore since a Scan done with a requested number of versions >  'VERSIONS' won't return more than 'VERSIONS' versions of the cell.

When issueing a Delete against a cell which was written more than 'VERSIONS' time, one would expect that the deletion removes all versions of the cell since no versions past the last one will be retained at compaction time.

But it seems that only the last version is deleted and the one prior to that then becomes visible again when it was not visible before (Scan with setMaxVersions() won't return it).


> Deletions done via BulkDeleteEndpoint make past data re-appear
> --------------------------------------------------------------
>
>                 Key: HBASE-15487
>                 URL: https://issues.apache.org/jira/browse/HBASE-15487
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.0.3
>            Reporter: Mathias Herberts
>         Attachments: HBaseTest.java, HBaseTest.java
>
>
> The Warp10 (www.warp10.io) time series database uses HBase as its underlying data store. The deletion of ranges of cells is performed using the BulkDeleteEndpoint.
> In the following scenario the deletion does not appear to be working properly:
> The table 't' is created with a single version using:
> create 't', {NAME => 'v', DATA_BLOCK_ENCODING => 'FAST_DIFF', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS=> '1', MIN_VERSIONS => '0', TTL => '2147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY =>'false', BLOCKCACHE => 'true'}
> We write a cell at row '0x00', colfam 'v', colq '', value 0x0
> We write the same cell again with value 0x1
> A scan will return a single value 0x1
> We then perform a delete using the BulkDeleteEndpoint and a Scan with a DeleteType of 'VERSION'
> The reported number of deleted versions is 1 (which is coherent given the table was created with MAX_VERSIONS=1)
> The same scan as the one performed before the delete returns a single value 0x0.
> This seems to happen when all operations are performed against the memstore.
> A regular delete will remove the cell and a later scan won't show it.
> I'll attach a test which demonstrates the problem.


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