[
https://issues.apache.org/jira/browse/HBASE-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ryan rawson updated HBASE-2248:
-------------------------------
Attachment: HBASE-2248-rr-alpha1.txt
Here is my patch to address the issue.
Some notes:
- we use a single forward pushing read point to accomplish atomicity. Right
now with appends and memstore puts mixed in, this causes writes to appear to be
serialized. There is no sync block which prevents multiple puts from being done
at the same time though. When we restructure WAL append to happen in one go,
and memstore put to happen after, this issue will go away.
- this patch does atomicity at a multi-family level. This means that if a write
is going across multiple families, and we do a concurrent scan (AND if a
concurrent flush also happens) we will only read the previously completely
written row. No partial multi-family row reads.
- Deletes are also atomic. By no longer removing KeyValues from memstore we
make it so. Also adjusted Gets to use 1 row Scans, and put in a TODO for a
bloomfilter hook.
- During a scan, we will ride over a snapshot and see the new data. We will
also reset the read point between every row, so a scan will see new values as
they are inserted _after_ it's current read point. If a row is updated after a
scan has already seen it, it will of course not see that value.
Some thanks:
- Todd for pointing out a case where read-your-own-writes might not happen
- Hints from the HBASE-2248-GetsAsScans patch for doing single row scans.
> 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
> Priority: Blocker
> Fix For: 0.20.4
>
> Attachments: HBASE-2248-demonstrate-previous-impl-bugs.patch,
> HBASE-2248-GetsAsScans3.patch, HBASE-2248-rr-alpha1.txt,
> HBASE-2248-ryan.patch, hbase-2248.gc, HBASE-2248.patch, hbase-2248.txt,
> readownwrites-lost.2.patch, readownwrites-lost.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.