[
https://issues.apache.org/jira/browse/HBASE-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15031:
--------------------------
Attachment: 14460.v0.branch-1.0.patch
This 1.0 patch will be very different to what goes upstream in master branch.
Fixing here first because this is where it is needed most.
Here is changeset message:
{code}
Patch for branch-1.0 first. Will address later branches with a different
approach (a more radical fixup). Here we are trying to be safe making minimal
change.
This patch adds a fast increment. To enable it you set the below configuration
to true in your hbase-site.xml configuration:
hbase.increment.fast.but.narrow.consistency
This sets region to take the fast increment path. Constraint is that caller
can only access the Cell via Increment; intermixing Increment with other
Mutations will give indeterminate results. Get will work or an Increment of zero
will return current value.
So, to add the above, we effectively copy/paste current Increment after doing
a bunch of work to try and move common code out into methods that can be
shared. Current increment becomes a switch and dependent on config we take the
slow but consistent or the fast but narrowly consistent code path. Increment
code path has too much state that it needs to keep up so hard to shrink it down
more
than what we have here without radical refactor (TODO in master patch; the
refactor is needed because even cursory exploration has us DUPLICATING lists
of Cells ... some of which is addressed on fast path here but more to do; fast
path also simplifies the write to hbase so am able to drop some of the state
keeping).
Adds a carryForward set of methods for Tags handling which allows us clean up
some duplicated code.
So, difference between fastAndNarrowConsistencyIncrement and
slowButConsistentIncrement is
that the former holds the row lock until the sync completes; this allows us to
reason that
there are no other writers afoot when we read the current increment value. This
means
we do not wait on mvcc reads to catch up to writes before we proceed with the
read, the
root of the slowdown seen in HBASE-14460. The fast-path also does not wait on
mvcc to
complete before returning to the client and we reorder the write so that the
update of
memstore happens AFTER sync returns; i.e. the write pipeline is less zigzagging
now.
Added some simple concurrency testing and then a performance testing tool for
Increments.
Added test that Increment of zero amount returns the current Increment value.
{code}
> Fix merge of MVCC and SequenceID performance regression in branch-1.0
> ---------------------------------------------------------------------
>
> Key: HBASE-15031
> URL: https://issues.apache.org/jira/browse/HBASE-15031
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Affects Versions: 1.0.3
> Reporter: stack
> Assignee: stack
> Attachments: 14460.v0.branch-1.0.patch
>
>
> Subtask with fix for branch-1.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
