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