Grokbase Groups HBase dev July 2010
FAQ
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/323/#review403
-----------------------------------------------------------

Ship it!


I don't know this code too well but what I see here makes sense to me. Good stuff Pranav.

- stack

On 2010-07-15 01:38:38, Pranav Khaitan wrote:

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/323/
-----------------------------------------------------------

(Updated 2010-07-15 01:38:38)


Review request for hbase, Jonathan Gray, Karthik Ranganathan, and Kannan Muthukkaruppan.


Summary
-------

This patch addresses the following issues:

1. After it is done with reading the required timestamps, the QueryMatcher should return a NEXT_COL so that it doesn't keep on reading every kv till the end of the column.

2. Before returning NEXT_COL, it also checks if any further columns are required. If no columns are required, then it returns NEXT_ROW instead of returning NEXT_COL. This saves significant time and another round of iteration.

3. Before seeking to NEXT_ROW, we check if we are already on the last row. If we are on the last row, then we can return false. This avoids one more call to next() and saves times.

4. Provides useful input for HBase-2450 and HBase-1517 which can take advantage of these return codes.

5. Optimizes Get queries with only one column.

6. Fixing a bug which occurred when versions were processed before filters were applied.

7. If we know (using filters/timestamps) that we don't need any more keys for a particular column, then there should be a mechanism to send this information to ExplicitColumnTracker.


This addresses bug HBASE-2517.
http://issues.apache.org/jira/browse/HBASE-2517


Diffs
-----

trunk/src/main/java/org/apache/hadoop/hbase/io/TimeRange.java 963961
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ExplicitColumnTracker.java 963961
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java 963961
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java 963961
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java 963961
trunk/src/test/java/org/apache/hadoop/hbase/client/TestMultipleTimestamps.java 963961

Diff: http://review.hbase.org/r/323/diff


Testing
-------

Existing tests run successfully with some of them going through the modified code path. Added specialized unit tests for this purpose. Did manual debugging to see if the optimization is being done and correct match codes are being returned.


Thanks,

Pranav

Search Discussions

  • Jonathan Gray at Jul 15, 2010 at 5:06 pm
    -----------------------------------------------------------
    This is an automatically generated e-mail. To reply, visit:
    http://review.hbase.org/r/323/#review405
    -----------------------------------------------------------

    Ship it!


    +1 from me as well


    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java
    <http://review.hbase.org/r/323/#comment1724>

    Good catch on this ordering.



    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java
    <http://review.hbase.org/r/323/#comment1725>

    Again, good stuff


    - Jonathan

    On 2010-07-15 01:38:38, Pranav Khaitan wrote:

    -----------------------------------------------------------
    This is an automatically generated e-mail. To reply, visit:
    http://review.hbase.org/r/323/
    -----------------------------------------------------------

    (Updated 2010-07-15 01:38:38)


    Review request for hbase, Jonathan Gray, Karthik Ranganathan, and Kannan Muthukkaruppan.


    Summary
    -------

    This patch addresses the following issues:

    1. After it is done with reading the required timestamps, the QueryMatcher should return a NEXT_COL so that it doesn't keep on reading every kv till the end of the column.

    2. Before returning NEXT_COL, it also checks if any further columns are required. If no columns are required, then it returns NEXT_ROW instead of returning NEXT_COL. This saves significant time and another round of iteration.

    3. Before seeking to NEXT_ROW, we check if we are already on the last row. If we are on the last row, then we can return false. This avoids one more call to next() and saves times.

    4. Provides useful input for HBase-2450 and HBase-1517 which can take advantage of these return codes.

    5. Optimizes Get queries with only one column.

    6. Fixing a bug which occurred when versions were processed before filters were applied.

    7. If we know (using filters/timestamps) that we don't need any more keys for a particular column, then there should be a mechanism to send this information to ExplicitColumnTracker.


    This addresses bug HBASE-2517.
    http://issues.apache.org/jira/browse/HBASE-2517


    Diffs
    -----

    trunk/src/main/java/org/apache/hadoop/hbase/io/TimeRange.java 963961
    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ExplicitColumnTracker.java 963961
    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java 963961
    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java 963961
    trunk/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java 963961
    trunk/src/test/java/org/apache/hadoop/hbase/client/TestMultipleTimestamps.java 963961

    Diff: http://review.hbase.org/r/323/diff


    Testing
    -------

    Existing tests run successfully with some of them going through the modified code path. Added specialized unit tests for this purpose. Did manual debugging to see if the optimization is being done and correct match codes are being returned.


    Thanks,

    Pranav

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieshbase, hadoop
postedJul 15, '10 at 4:17p
activeJul 15, '10 at 5:06p
posts2
users2
websitehbase.apache.org

2 users in discussion

Jonathan Gray: 1 post Stack: 1 post

People

Translate

site design / logo © 2022 Grokbase