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

Hanjie Gu edited comment on HBASE-4811 at 6/21/17 7:50 AM:
-----------------------------------------------------------

I am confused  about the top Description.
In my opinion reverse scan will output reversely, from bottom to up, starting 
from the point of start key.
That is given the such example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2

Shouldn't a reversed scan from 'ddd' to 'bbb'(exclude) output like this:
ddd/c1:q2/value2
ddd/c1:q1/value1
ccc/c1:q2/value2
ccc/c1:q1/value1

However, the Description says like this:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2

did it wrote error? or I have a misunderstand???


was (Author: jackgu):
I am confused  about the top Description.
In my opinion reverse scan will output reversely, from bottom to up, starting 
from the point of start key.
That is given the such example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2

Shouldn't a reversed scan from 'ddd' to 'bbb'(exclude) output like this:
ddd/c1:q2/value2
ddd/c1:q1/value1
ccc/c1:q2/value2
ccc/c1:q1/value1
???

However, the Description says like this:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2

did it wrote error? or I have a misunderstand?

> Support reverse Scan
> --------------------
>
>                 Key: HBASE-4811
>                 URL: https://issues.apache.org/jira/browse/HBASE-4811
>             Project: HBase
>          Issue Type: New Feature
>          Components: Client
>    Affects Versions: 0.20.6, 0.94.7
>            Reporter: John Carrino
>            Assignee: chunhui shen
>             Fix For: 0.98.0
>
>         Attachments: 4811-0.94-v22.txt, 4811-0.94-v23.txt, 4811-0.94-v25.txt, 
> 4811-0.94-v3.txt, 4811-trunk-v10.txt, 4811-trunk-v29.patch, 
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, hbase-4811-0.94 
> v21.patch, hbase-4811-0.94-v24.patch, HBase-4811-0.94-v2.txt, 
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, 
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, 
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch, 
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch, 
> hbase-4811-trunkv19.patch, hbase-4811-trunkv1.patch, 
> hbase-4811-trunkv20.patch, hbase-4811-trunkv21.patch, 
> hbase-4811-trunkv24.patch, hbase-4811-trunkv24.patch, 
> hbase-4811-trunkv25.patch, hbase-4811-trunkv26.patch, 
> hbase-4811-trunkv27.patch, hbase-4811-trunkv28.patch, 
> hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, hbase-4811-trunkv7.patch, 
> hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward. 
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
>  System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> 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 was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to