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

shen guanpu commented on HBASE-7263:
------------------------------------

"HBASE-7051 and HBASE-4583 implement option #1. The downside, as mentioned, is 
that you have to wait for updates on other rows, since MVCC is per-row."

Do you mean it is not per-row for option 2( Have an MVCC per-row (table 
configuration): this avoids the unnecessary contention of 1))
                
> Investigate more fine grained locking for checkAndPut/append/increment
> ----------------------------------------------------------------------
>
>                 Key: HBASE-7263
>                 URL: https://issues.apache.org/jira/browse/HBASE-7263
>             Project: HBase
>          Issue Type: Improvement
>          Components: Transactions/MVCC
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>            Priority: Minor
>
> HBASE-7051 lists 3 options for fixing an ACID-violation wrt checkAndPut:
> {quote}
> 1) Waiting for the MVCC to advance for read/updates: the downside is that you 
> have to wait for updates on other rows.
> 2) Have an MVCC per-row (table configuration): this avoids the unnecessary 
> contention of 1)
> 3) Transform the read/updates to write-only with rollup on read.. E.g. an 
> increment would just have the number of values to increment.
> {quote}
> HBASE-7051 and HBASE-4583 implement option #1.  The downside, as mentioned, 
> is that you have to wait for updates on other rows, since MVCC is per-row.
> Another option occurred to me that I think is worth investigating: rely on a 
> row-level read/write lock rather than MVCC.
> Here is pseudo-code for what exists today for read/updates like checkAndPut
> {code}
> (1)  Acquire RowLock
> (1a) BeginMVCC + Finish MVCC
> (2)  Begin MVCC
> (3)  Do work
> (4)  Release RowLock
> (5)  Append to WAL
> (6)  Finish MVCC
> {code}
> Write-only operations (e.g. puts) are the same, just without step 1a.
> Now, consider the following instead:
> {code}
> (1)  Acquire RowLock
> (1a) Grab+Release RowWriteLock (instead of BeginMVCC + Finish MVCC)
> (1b) Grab RowReadLock (new step!)
> (2)  Begin MVCC
> (3)  Do work
> (4)  Release RowLock
> (5)  Append to WAL
> (6)  Finish MVCC
> (7)  Release RowReadLock (new step!)
> {code}
> As before, write-only operations are the same, just without step 1a.
> The difference here is that writes grab a row-level read lock and hold it 
> until the MVCC is completed.  The nice property that this gives you is that 
> read/updates can tell when the MVCC is done on a per-row basis, because they 
> can just try to acquire the write-lock which will block until the MVCC is 
> competed for that row in step 7.
> There is overhead for acquiring the read lock that I need to measure, but it 
> should be small, since there will never be any blocking on acquiring the 
> row-level read lock.  This is because the read lock can only block if someone 
> else holds the write lock, but both the write and read lock are only acquired 
> under the row lock.
> I ran a quick test of this approach over a region (this directly interacts 
> with HRegion, so no client effects):
> - 30 threads
> - 5000 increments per thread
> - 30 columns per increment
> - Each increment uniformly distributed over 500,000 rows
> - 5 trials
> Better-Than-Theoretical-Max: (No locking or MVCC on step 1a): 10362.2 ms
> Today: 13950 ms
> The locking approach: 10877 ms
> So it looks like an improvement, at least wrt increment.  As mentioned, I 
> need to measure the overhead of acquiring the read lock for puts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to