hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Zhong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13389) [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
Date Sat, 04 Apr 2015 23:18:33 GMT

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

Jeffrey Zhong commented on HBASE-13389:

Thanks [~lhofhansl] for looking this. I think your patch can help a bit.

Do we need valid (non 0) mvcc readpoints for committed data (i.e. data that was flushed to
an HFile and hence we'll never need to replay any HLogs for those)? Do we need these anywhere
but in the memstore?
There are three cases(I could think of and maybe more) that we need the logSeqId(mvcc) around
to help us keep the put order.

Assuming all put/deletes are of same row & timestamp(version) 
case 1) region server recovery case
We need mvcc(logSeqId) only when region is in recovery mode but not after recovery.

case 2) replication receiving side, we need logSeqId to maintain the order because region
move or recovery in replication playing side cause puts out of order
We need mvcc for couple of days(to be safe) so that at least the data eventually in receiving
side are correct.

case 3) put , delete, put. Currently delete overshadows the later put but with logSeqId we
can easily solve the issue because logSeqId is the real version of a put.
Seems to me not needed(before I thought we need to keep mvcc around till a major compaction)



> [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
> -------------------------------------------------------------
>                 Key: HBASE-13389
>                 URL: https://issues.apache.org/jira/browse/HBASE-13389
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>         Attachments: 13389.txt
> 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
> 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

View raw message