[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liang Xie updated HBASE-4811:
-----------------------------
Attachment: HBase-4811-0.94.3modified.txt
Attached HBase-4811-0.94.3modified.txt is an our internal draft implementation
for reverse scan. I thought it may be not suitable to merge into trunk or any
branch, so i didn't make a patch against trunk or 0.94 branch, drop here just
in case some guys are interesting on it, for reference only:) We didn't
impletement it like leveldb&cassandra's way, which done in block layer, our
policy is more focused on upper logic layer(scanner & Kv heap), though we still
use seekBefore api.
Performance: i ran PerformanceEvaluation, observed about 20%-40% degraded on
scanRange10/100/1000, and approximately 50% degraded on randomSeekScan.
> 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
> Reporter: John Carrino
> Attachments: HBase-4811-0.94.3modified.txt
>
>
> 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
