hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ski Gh3" <ski...@gmail.com>
Subject Re: Other CC examined in HBase transaction model?
Date Tue, 07 Oct 2008 22:54:08 GMT
Two quick follow-up questions:

Which version of hbase do we need to download in order to use to OCC
functionality?0.18.0?
I guess no setting is required by the user, where hregionserver was used
will now be transactionalregion, right?

How can this be combined with secondary index? Didn't find the code for that
in 0.18.0, is that still
work in progress?

Thanks a lot!

On Mon, Oct 6, 2008 at 2:26 PM, Clint Morgan <clint.a.m@gmail.com> wrote:

> I implemented the OCC functionality. Went that route because it seemed
> relatively straightforward and has acceptable performance for our
> workloads.
> Also I saw something somewhere that made me think that google was using OCC
> for transactions in AppEngine.
>
> My intuition is that where the OCC approach really gets into trouble is
> when
> transactions start to frequently conflict (EG, when the "optimistic" hope
> no
> longer holds). Of course, as you increase the life of a transaction, you
> increase the probability it will conflict with another.
>
> I don't know enough about timstamp-, or MV-CCs to compare "scalability" to
> the OCC approach.
>
> -clint
>
> On Mon, Oct 6, 2008 at 11:19 AM, Jaeyun Noh <metalain@gmail.com> wrote:
>
> > Hi,
> >
> > I looked at the source codes implemented to support Multi-region
> > transaction
> > feature. (HBASE-669)
> > It uses optimistic concurrency control. Did any guys consider other CC
> like
> > timestamp-based CC or multiversion CC?
> >
> > I think it's okay in read-dominated and relatively short transaction
> > workloads. In other case, is MVCC more scalable rather than OCC?
> > What do you think of pros/cons of other concurrency control schemes in
> > Hbase
> > transactions?
> >
> > Just I'm curious that hbase transaction uses other CCs or not.
> >
> > Regards,
> > Jaeyun Noh.
> >
>

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