hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chandrashekhar Kotekar <shekhar.kote...@gmail.com>
Subject Re: HBase co-processor performance
Date Thu, 16 Jul 2015 13:18:45 GMT
Hi,

Thanks for the inputs. As you said, it is better to change database design
than moving this business logic to co-processors, and sorry for duplicate
mail. I guess duplicate mail was in my mobile's outbox and after syncing
mobile that mail was sent.


Regards,
Chandrash3khar Kotekar
Mobile - +91 8600011455

On Wed, Jul 15, 2015 at 12:40 PM, anil gupta <anilgupta84@gmail.com> wrote:

> Using coprocessor to make calls to other Tables or remote Regions is an
> ANTI-PATTERN. It will create cyclic dependency between RS in your cluster.
> Coprocessors should be strictly used for operation on local Regions. Search
> mailing archives for more detailed discussion on this topic.
>
> How about denormalizing the data and then just doing ONE call? Now, this
> becomes more of a data modeling question.
>
> Thanks,
> Anil Gupta
>
>
> On Tue, Jul 14, 2015 at 11:39 PM, Chandrashekhar Kotekar <
> shekhar.kotekar@gmail.com> wrote:
>
> > Hi,
> >
> > REST APIs of my project make 2-3 calls to different tables in HBase.
> These
> > calls are taking 10s of milli seconds to finish.
> >
> > I would like to know
> >
> > 1) If moving business logic to HBase co-processors and/or observer will
> > improve performance?
> >
> > Idea is like to pass all the related information to HBase co-processors
> > and/or observer, co-processor will make those 2-3 calls to different
> HBase
> > tables and return result to the client.
> >
> > 2) I wonder if this approach will reduce time to finish or is it a bad
> > approach?
> >
> > 3) If co-processor running on one region server fetches data from other
> > region server then it will be same as tomcat server fetching that data
> from
> > HBase region server. Isn't it?
> >
> > Regards,
> > Chandrash3khar Kotekar
> > Mobile - +91 8600011455
> >
>
>
>
> --
> Thanks & Regards,
> Anil Gupta
>

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