hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liang Xie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4811) Support reverse Scan
Date Mon, 01 Jul 2013 10:14:22 GMT

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

Liang Xie commented on HBASE-4811:
----------------------------------

[~zjushch], we need to change one line in HFileReaderV2.seekBefore() in trunk patch(but not
0.94's):
{code}
      if (reader.getComparator().compare(firstKey.array(),
          firstKey.arrayOffset(), firstKey.limit(), key, offset, length) == 0)
{code}

to:

{code}
      if (reader.getComparator().compare(firstKey.array(),
          firstKey.arrayOffset(), firstKey.limit(), key, offset, length) >= 0)
{code}

Because HBASE-7845(optimize hfile index key) was in trunk already, it'll have an impact here.
We(Xiaomi) are running a 0.94 modified version with HBASE-7845 in production cluster, and
changed "==" to ">=".
                
> 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-trunkv11.patch, 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

Mime
View raw message