hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ramkrishna vasudevan <ramkrishna.s.vasude...@gmail.com>
Subject Re: Design review: Secondary index support through coprocess
Date Tue, 21 Jan 2014 04:14:49 GMT
Generally when we thought of this Secondary indexing soln, the index table
is generally an inverted table but the definition of the rowkey differs and
how many of such inverted table changes.  In Huawei's impl it is 1.
Next point is, should the CP calls cross the Region server boundaries or it
should be with in that RS.
Now this is more applicable for the writes.  As Jesse rightly points out
the index table should be consistent with the main table and making
anything asynchronous in this write path would definitely make consistency
a big problem and definitely leads to dead locks.
The problem of RPC handlers and going across RS is now a tradeoff with
colocation. I think we will fall in any one of the category.

Finally, we internally have discussed on scope of having cross region
transactions atleast in the case of co-located regions.  This is an
interesting problem but if we have this we would be able to have this write
path(with index) more reliable.

Regards
Ram




On Tue, Jan 21, 2014 at 4:33 AM, Andrew Purtell <apurtell@apache.org> wrote:

> On Mon, Jan 20, 2014 at 2:53 PM, Jesse Yates <jesse.k.yates@gmail.com
> >wrote:
>
> > .In Phoenix,
> > we kind of get around the deadlock issue by separating out the write
> layer
> > for indexes to make it queuable and using our own thread pools to make it
> > somewhat async. It just ends up being hard to ensure consistency when you
> > don't block on the write being committed :)
> >
>
> Yes and yes.
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

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