hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ryan rawson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2649) Make use of storefile 'order' making certain decisions during merge sort
Date Tue, 01 Jun 2010 23:31:38 GMT

    [ 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.

View raw message