hbase-issues mailing list archives

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

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

Lars Hofhansl commented on HBASE-13389:
---------------------------------------

Sure. After discussions we had ([~stack], [~apurtell], and I) I think we can reinstate my
original code, where we check against the oldest running scanner and if all Cell in an HFile
are older than that scaner (in terms of MVCC timestamp) we can set them to 0 and not store
them upon compaction.

The observation being that we only need MVCC stamps in the HFile to cover flushes/compactions
that happen while a current scanner is running.
All other cases we should be covering with metadata in the HFiles trailer, not on individual
Cells.

[~jeffreyz], do you agree? HBASE-12600 changed that, and I bet you had a very good reason.


> [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
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