hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2248) Provide new non-copy mechanism to assure atomic reads in get and scan
Date Fri, 05 Mar 2010 02:47:27 GMT

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

Todd Lipcon commented on HBASE-2248:
------------------------------------

Hey Ryan

I looked over this patch a bit this afternoon. It's clever but I think it can result in loss
of read-your-own-writes consistency for a single client. Consider this scenario:

|| Action || Read # || Write # || memstoreRead || memstoreWrite ||
| Client A begins a put on row R   | - | 1 | 0 | 1 |
| Client B begins a put on row S   | - | 2| 0 | 2 |
| Client B finishes a put on row S | - | - | 0 | 2 |
| Client B initiates a get on row S | 0 | - | 0 | 2 |

So, since client A's put #1 is still ongoing on a separate row, client B is unable to read
version #2 of its row.

I think dropping consistency below read-your-own-writes is bad, even though it's rare that
the above situation would occur. Under high throughput I think it's possible to occur, and
it could be very very bad if people are relying on this level of consistency to implement
transactions, etc.

One possible solution is that completeMemstoreInsert can spin until memstoreRead >= e.getWriteNumber().
Given that it only has to wait for other concurrent writers to finish, a spin on memstoreRead.get()
should only go a few cycles and actually be reasonably efficient.

I'll think a bit about whether there are other possible solutions.

> Provide new non-copy mechanism to assure atomic reads in get and scan
> ---------------------------------------------------------------------
>
>                 Key: HBASE-2248
>                 URL: https://issues.apache.org/jira/browse/HBASE-2248
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.3
>            Reporter: Dave Latham
>             Fix For: 0.20.4
>
>         Attachments: HBASE-2248-demonstrate-previous-impl-bugs.patch, HBASE-2248-ryan.patch,
hbase-2248.gc, HBASE-2248.patch, Screen shot 2010-02-23 at 10.33.38 AM.png, threads.txt
>
>
> HBASE-2037 introduced a new MemStoreScanner which triggers a ConcurrentSkipListMap.buildFromSorted
clone of the memstore and snapshot when starting a scan.
> After upgrading to 0.20.3, we noticed a big slowdown in our use of short scans.  Some
of our data repesent a time series.   The data is stored in time series order, MR jobs often
insert/update new data at the end of the series, and queries usually have to pick up some
or all of the series.  These are often scans of 0-100 rows at a time.  To load one page, we'll
observe about 20 such scans being triggered concurrently, and they take 2 seconds to complete.
 Doing a thread dump of a region server shows many threads in ConcurrentSkipListMap.biuldFromSorted
which traverses the entire map of key values to copy it.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message