hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chunhui shen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4811) Support reverse Scan
Date Thu, 13 Jun 2013 03:49:21 GMT

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

chunhui shen commented on HBASE-4811:

bq.So would: ReversedRegionScanner -> KVHelp -> RerversedStoreScanner -> ReversedKVHeap
-> (MemstoreScanner|StoreFileScanner) work?
Need ReversedRegionScanner -> ReversedKVHeap, because we need a reversed sort of scanners
in ReversedKVHeap and call seekToPreviousRow for RegionScanner#nextRow, otherwise the scan
order would be wrong.

bq.ReversedKeyValueHeap should not need backwardSeek, since all calls to (re)seek, etc, call
backwardSeek anyway.
ReversedKeyValueHeap should support backwardSeek and seekToPreviousRow even if no calls. Is
it better to understand that prohibit calling (re)seek in ReversedKeyValueHeap and ReversedStoreScanner

bq.do we need NonReversedNonLazyKeyValueScanner? Could add "unsupported" implementations for
these methods to NonLazyKeyValueScanner.
MemStoreScanner extends from NonLazyKeyValueScanner, it seems not appropriate if add "unsupported"
implementations to NonLazyKeyValueScanner
> Support reverse Scan
> --------------------
>                 Key: HBASE-4811
>                 URL: https://issues.apache.org/jira/browse/HBASE-4811
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client
>    Affects Versions: 0.20.6, 0.94.7
>            Reporter: John Carrino
>            Assignee: Liang Xie
>         Attachments: 4811-trunk-v10.txt, 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt,
HBase-4811-0.94-v2.txt, hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
> All the documentation I find about HBase says that if you want forward and reverse scans
you should just build 2 tables and one be ascending and one descending.  Is there a fundamental
reason that HBase only supports forward Scan?  It seems like a lot of extra space overhead
and coding overhead (to keep them in sync) to support 2 tables.  
> I am assuming this has been discussed before, but I can't find the discussions anywhere
about it or why it would be infeasible.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message