hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-13389) [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
Date Thu, 02 Apr 2015 21:49:57 GMT
stack created HBASE-13389:
-----------------------------

             Summary: [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
                 Key: HBASE-13389
                 URL: https://issues.apache.org/jira/browse/HBASE-13389
             Project: HBase
          Issue Type: Bug
          Components: Performance
            Reporter: stack


HBASE-12600 moved the edit sequenceid from tags to instead exploit the mvcc/sequenceid slot
in a key. Now Cells near-always have an associated mvcc/sequenceid where previous it was rare
or the mvcc was kept up at the file level. This is sort of how it should be many of us would
argue but as a side-effect of this change, read-time optimizations that helped speed scans
were undone by this change.

In this issue, lets see if we can get the optimizations back -- or just remove the optimizations
altogether.

The parse of mvcc/sequenceid is expensive. It was noticed over in HBASE-13291.

The optimizations undone by this changes are (to quote the optimizer himself, Mr [~lhofhansl]):

{quote}
Looks like this undoes all of HBASE-9751, HBASE-8151, and HBASE-8166.
We're always storing the mvcc readpoints, and we never compare them against the actual smallestReadpoint,
and hence we're always performing all the checks, tests, and comparisons that these jiras
removed in addition to actually storing the data - which with up to 8 bytes per Cell is not
trivial.
{quote}

This is the 'breaking' change: https://github.com/apache/hbase/commit/2c280e62530777ee43e6148fd6fcf6dac62881c0#diff-07c7ac0a9179cedff02112489a20157fR96





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message