[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789063#comment-13789063 ]
chunhui shen commented on HBASE-4811: ------------------------------------- Maybe caching the variable of 'reversed' in Scan.class will take something. Like: {code} public boolean isReversed() { if (this.reversed == null) { byte[] attr = getAttribute(REVERSED_ATTR); this.reversed = attr == null ? false : Bytes.toBoolean(attr); } return this.reversed; } public void setReversed(boolean reversed) { setAttribute(REVERSED_ATTR, Bytes.toBytes(reversed)); this.reversed = reversed; } {code} I have tested the above performance case, the result is near 15.82s vs 15.70s. But haven't got large difference like 17.1s vs 16.1s. After caching the variable of 'reversed' , the performance seems to be better, but I'm not very sure since all the tests are not completely stable in my environment and the gap is small > 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-v3.txt, 4811-trunk-v10.txt, > 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, hbase-4811-0.94 > v21.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-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 > NOTE: when setting reversed as true for a client scan, you must set the start > row, else will throw exception. Through {@link > Scan#createBiggestByteArray(int)},you could get a big enough byte array as > the start row > 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.1#6144)