hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Mergen" <l...@solatis.com>
Subject Re: Question about how queries are distributed
Date Mon, 04 Aug 2008 17:39:36 GMT
Hello Andrew,


Well, I must say that I am very pleased with the ease of integration that
Thrift brought into my (C++) project; I got it up and running within a
single weekend.

However, as I was suspecting, the Thrift functionality does appear to be
lacking compared to the native Java API -- since HBase is not a project
where you want to force your users into a specific development environment,
I do feel this should be fixed (especially since you cannot efficiently
write locality aware map/reduce jobs with the Thrift API, unless you will be
running a Thrift server on every single slave node in your cluster).

I am not aware of the possibilities, especially since the HBase client
connects to the region servers "under the hood", where in all the
Thrift-like API's you have to manually setup communications. However, if no
one picked up on this by then, I will be willing to look into it in a few
months from now.


Regards,

Leon Mergen


On Mon, Aug 4, 2008 at 6:50 PM, Andrew Purtell <apurtell@yahoo.com> wrote:

> Something to think about is integration of Thrift with the master
> and regionserver themselves as a first class API. I think the
> Thrift (and also the REST) APIs as clients/front ends are proof-
> of-concepts more than anything else.
>
>   - Andy
>
> > From: Jean-Daniel Cryans <jdcryans@gmail.com>
> > Subject: Re: Question about how queries are distributed
> > To: hbase-user@hadoop.apache.org
> > Date: Monday, August 4, 2008, 6:05 AM
> > Ah ok I see what you meant! Yes, the Thrift client
> > communicates with a Thrift server which is bundled with
> > the Master, so the HBase client code doesn't run on your
> > local machine that queries HBase.
> > So yes, there may be a scalability problem
>
>
>
>
>


-- 
Leon Mergen
http://www.solatis.com

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