hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-980) Undo core of HBASE-975, caching of start and end row
Date Tue, 04 Nov 2008 08:28:46 GMT

     [ https://issues.apache.org/jira/browse/HBASE-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

stack updated HBASE-980:

    Attachment: 980.patch

Commit message:

M src/test/org/apache/hadoop/hbase/regionserver/TestHStoreFile.java
    Undo tests of features removed.
M  src/java/org/apache/hadoop/hbase/regionserver/HStore.java
    Restore how we used calculate first and final keys.  Also removed
    an unnecessary reset checking if needs split.
M  src/java/org/apache/hadoop/hbase/io/HBaseMapFile.java
    Undo caching of first and last key (HBASE-975)
    (getBloomFilterKey): Move to BloomFilterMapFile.
M  src/java/org/apache/hadoop/hbase/io/HalfMapFileReader.java
    Undo dependence on first and final keys doing halfmapfile.
M  src/java/org/apache/hadoop/hbase/io/BloomFilterMapFile.java
    (getBloomFilterKey): Moved here from HBaseMapFile.

Patch passes all tests.

> Undo core of HBASE-975, caching of start and end row
> ----------------------------------------------------
>                 Key: HBASE-980
>                 URL: https://issues.apache.org/jira/browse/HBASE-980
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>             Fix For: 0.19.0
>         Attachments: 980.patch
> Profiling, I learned that the HBASE-975 makes things worse rather than better.  For every
Reader opened -- one is opened per store file when we open a region as well as a Reader per
file when we compact and then another Reader whenever a Scanner is opened -- the change adds
about 4 seeks and at least in the case of compacting and scanning, to no benefit. Even where
it is of benefit, when going against HalfMapFiles or when many Store files and we're testing
to see if row is in file, it looks like the number of seeks saved are miniscule -- definetly
not something that would show up in timings.
> This issue is about undoing the get of first and last key on open of a store file, the
heart of HBASE-975 (975 included a bunch of cleanup refactoring. That'll stay).
> Profiling seeks, I did notice that we do an extra seek during a get, a reset that takes
us to the start of the file.  Then internally to getClosest, the core of our get, we're also
doing a seek to closest index.  Let me try undoing the extra seek and see if it breaks things.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message