hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3276) delete followed by a put with the same timestamp
Date Fri, 26 Nov 2010 23:15:19 GMT

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

HBase Review Board commented on HBASE-3276:

Message from: "Pranav Khaitan" <pranavkhaitan@gmail.com>

bq.  On 2010-11-26 14:54:45, Ryan Rawson wrote:
bq.  > trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 1373
bq.  > <http://review.cloudera.org/r/1252/diff/1/?file=17712#file17712line1373>
bq.  >
bq.  >     what are all the consequences for not sorting by type when using KVComparator?
 Does this mean we might create HFiles that not sorted properly, because the HFile comparator
uses the KeyComparator directly with ignoreType = false. 
bq.  >     
bq.  >     While in memstore we can rely on memstoreTS to roughly order by insertion time,
and the Put/Delete should probably work in that situation, you are talking about modifiying
a pretty core and important concept in how we sort things.
bq.  >     
bq.  >     There are other ways to reconcile bugs like this, one of them is to extend the
memstoreTS concept into the HFile and use that to reconcile during reads.  There is another
JIRA where I proposed this.  
bq.  >     
bq.  >     If we are talking about 0.92 and beyond I'd prefer building a solid base rather
than dangerous hacks like this.  Our unit tests are not extremely extensive, so while they
might pass, that doesnt guarantee lack of bad behaviour later on.
bq.  >

Agree. As I mentioned, this is a major change and more thought needs to be given to it.

However, to resolve issues like HBASE-3276, we need either such a change or extend the memstoreTS
concept to HFile as you mentioned.

About consequences, I don't see anything negative here. This change only affects the sorting
of keys having same row, col, timestamp. After this change, all keys with the same row, col,
ts will be sorted purely based on the order in which they were inserted. When a memstore is
flushed to HFile, the memstoreTS takes care of ordering. During compactions, the KeyValueHeap
breaks ties by using the sequence ids of storefiles. 

- Pranav

This is an automatically generated e-mail. To reply, visit:

> delete followed by a put with the same timestamp
> ------------------------------------------------
>                 Key: HBASE-3276
>                 URL: https://issues.apache.org/jira/browse/HBASE-3276
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Kannan Muthukkaruppan
>            Assignee: Kannan Muthukkaruppan
> [Note: This issue is relevant only for cases that don't use the default "time" based
versions, but provide/manage versions explicitly.]
> The fix for HBASE-1485 ensures that if there are multiple puts with the same timestamp
the later one wins.
> However, if there is a delete for a specific timestamp, then the later put doesn't win.

> Say for example the following is the sequence of operations:
> put                         row/col/v1 - value1
> deleteColumn     row/col/v1
> put                         row/col/v1 - value2
> Without the deleteColumn(), HBASE-1485 ensures that "value2" is the winner.
> However, with the deleteColumn() thrown into the mix, the delete wins, and one cannot
insert a new value at that version. [The only, unsatisfactory, workaround at this point seems
to be trigger a major compaction. The major compact would clear the delete marker, and allow
new cells to be created with that version again.] 
> ---
> Seems like it might not be too complicated to extend the fix for HBASE-1485 to also respect
ordering between delete/put operations. I'll look into this further.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message