You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "ryan rawson (JIRA)" <ji...@apache.org> on 2010/06/02 01:31:38 UTC

[jira] Commented: (HBASE-2649) Make use of storefile 'order' making certain decisions during merge sort

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

ryan rawson commented on HBASE-2649:
------------------------------------

The old get code essentially did this.  We decided to remove it for simplicity in HBASE-2248.  Having things controlled by an arbitrary opaque concept (Store file order) is probably not a good idea.

Specifically the old get code which orders store files for Puts caused a situation where the insert order via store files overrides the timestamp (user settable thing) and made it so Gets and Scans were giving different answers.  I think we should NOT consider doing so, and even though tombstones stay longer than we'd want to, going for simplicity and easy to understand APIs and inner workings is better.

What we might consider is allowing access to tombstone markers via some API so people can get to understand how their data is being masked.  Right now the Result() return only has Put KeyValues.

> Make use of storefile 'order' making certain decisions during merge sort
> ------------------------------------------------------------------------
>
>                 Key: HBASE-2649
>                 URL: https://issues.apache.org/jira/browse/HBASE-2649
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: stack
>
> When we merge sort results currently there is no regard for storefile order.  This issue is about exploiting store file order at certain junctures.  For example, if we have N KVs all of the same coordinates -- same r/f/q/type/ts -- then the one from the storefile that was made most recently should prevail.  Also, we might consider order when looking at deletes so our tombstones are less *tombstoney* in that they'll only apply to values that are in storefiles older than the one that carries the delete marker (this latter sounds hard but putting it out there anyways).

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