hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: HBase reads, isolation levels and RegionScanner internal locking
Date Fri, 12 Sep 2014 18:25:05 GMT
Michael,

This is not a row-level locking - it is region-wide lock. This is a major
reason of  the following performance problems:

1) Multi gets are bad if inside the same region
2) Multiple scanners over the same region are bad
3) Scan during compaction are bad.

I need some input from HBase folks here:

1) READ_UNCOMMITTED safe if lock free?
2) Confirmation that region-wide lock is for read consistency only.


On Fri, Sep 12, 2014 at 11:04 AM, Stack <stack@duboce.net> wrote:

> On Thu, Sep 11, 2014 at 3:58 PM, Vladimir Rodionov <vladrodionov@gmail.com
> >
> wrote:
>
> > Hi, all
> >
> > We have two isolation levels in (used to be in Scan) in Query now. See:
> > https://issues.apache.org/jira/browse/HBASE-11936
> >
> > I moved isolation levels API from Scan upward to Query class. The reason:
> > this API was not available for Get operations. The rationals? Improve
> > performance of get and multi-gets over the same region.
> >
> > As many of you aware, RegionScannerImpl is heavily synchronized on
> internal
> > region's lock.  Now some questions:
> >
> > 1. Is it safe to bypass this locking (in next() call) in READ_UNCOMMITTED
> > mode?
>
> We will do all necessary checks, of course, before calling nextRaw().
> > 2. What was the reason of this locking in a first place for reads in
> > READ_COMMITTED mode? Except obvious - no-dirty-reads allowed? Can someone
> > tell me what else bad can happen?
> >
>
>
> There is only the obvious (that I know of) Vladimir.  We've been so fixated
> on ensuring consistent view on a row, we've not done the work to allow
> other read types. I'm not sure what would happen if you were to skirt row
> lock.  Try hacking on TestAtomicOperation to undo lock and see what
> happens?
>
> St.Ack
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message