hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17924) Consider sorting the row order when processing multi() ops before taking rowlocks
Date Mon, 22 May 2017 04:41:04 GMT

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

stack commented on HBASE-17924:

I like [~jerryhe]'s question. Not sure how sort makes a difference ("...conflicts faster..."
implies concurrent threads are moving through the batch in lock-step); and if we are going
to sort batches, would be good to do it across the board so we could lean on batches being
sorted (say, skip taking lock if second batch on a row); i.e. +1 on the semantic improvement.
 I'm in this section at the mo. It is looking like our reeentrant read/write lock, the basis
of our current row locking, goes to hell if there are more than a few read-then-modify operations
in the mix (i.e. a bunch of increments on a row also taking mutations). Thanks.

> Consider sorting the row order when processing multi() ops before taking rowlocks
> ---------------------------------------------------------------------------------
>                 Key: HBASE-17924
>                 URL: https://issues.apache.org/jira/browse/HBASE-17924
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 2.0.0, 1.1.8
>            Reporter: Andrew Purtell
>            Assignee: Allan Yang
>             Fix For: 2.0.0, 1.4.0
>         Attachments: HBASE-17924.patch, HBASE-17924.v0.patch, HBASE-17924.v2.patch, HBASE-17924.v3.patch,
HBASE-17924.v4.patch, HBASE-17924.v5.patch
> When processing a batch mutation, we take row locks in whatever order the mutations were
added to the multi op by the client.
> {noformat}
> RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow -> HRegion#mutateRowsWithLocks
-> HRegion#processRowsWithLocks
> {noformat}
> Or
> {noformat}
> RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
>       HRegion#get 
>     | HRegion#append 
>     | HRegion#increment 
>     | HRegionServer#doBatchOp -> HRegion#batchMutate -> HRegion#doMiniBatchMutation
> {noformat}
> multi() is fed by client APIs that accept a RowMutations object containing actions for
multiple rows. The container for ops inside RowMutations is an ArrayList, which doesn't change
the ordering of objects added to it. The protobuf implementation of the messages for multi
ops do not reorder the list of actions. When processing multi ops we iterate over the actions
in the order rehydrated from protobuf.
> We should discuss sorting the order of ops by row key when processing multi() ops before
taking row locks. Does this make lock ordering more predictable for server side operations?
Yes, but potentially surprising for the client, right? Is there any legitimate reason we should
take locks out of row key sorted order because the client has structured the request as such?

This message was sent by Atlassian JIRA

View raw message