hbase-issues mailing list archives

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

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

Jonathan Gray commented on HBASE-2649:
--------------------------------------

I'm interested in this for the first use case.  As for second case, as Ryan said, this is
basically what we used to do.  I think as far as deletes and such are concerned, we need to
nail down what we do/don't want to do during a flush and during minor compactions.

With HBASE-2248 we now have MemStore taking care of the ordering of duplicate versions, so
within each StoreFile, they will be ordered with the most recent at the top.  The only thing
that remains to properly handle ordering of duplicate versions is cross-StoreFile.

One solution is to include sequence numbers for every KV in the StoreFiles.  The other is
this jira.  I am +1 on this jira and have a general idea how to do it.

> 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
>             Fix For: 0.21.0
>
>
> 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.


Mime
View raw message