hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Whiting <je...@qualtrics.com>
Subject Re: HBase wire compatibility
Date Thu, 16 Feb 2012 23:55:57 GMT
It seems like the only heavy part of the client would be the zookeeper interactions (forgive
ignorance if I'm wrong).  Other than zookeeper only a basic understanding of regions need
to be 
understood.  So if the zookeeper interactions could be removed and pushed somewhere else in
stack that could make the client much thinner.

I understand not maintaining multiple clients nor do I think the project should maintain another

client right now.  However now seems like the time to plan for new clients in other languages.
will be the next time the client / server protocol is changed?  I'm guessing most people would
hopefully never again.  IMHO since you are redoing the communication why not improve the protocol
allow for a leaner the client.  A leaner client would be more likely to work across major
changes, would be easier to maintain, would hide implementation details and could have less

dependencies.  One of the reasons the client doesn't do well across major changes is because
of how 
heavy it is. Even if the client is never implemented in another language a thinner client
would seem 
to be an improvement.

What I'm suggesting may not be possible but it seems like it is worth keeping in mind through
design and implementation process.


On 2/16/2012 4:09 PM, Todd Lipcon wrote:
> On Thu, Feb 16, 2012 at 3:04 PM, Jeff Whiting<jeffw@qualtrics.com>  wrote:
>> Will this allow for hbase clients in other languages?  It seems that if pb
>> are being used then any language pb supports could have a first class client
>> and not have to use a separate (and not super maintained) thrift server. You
>> would want to keep the client to be light though if it were to be ported to
>> other languages.
>> IMHO it seems that if we are going to the work of redoing the client
>> communications we should be considering other languages.  It seems like
>> having first class clients in various languages could only increase hbase
>> adoption which would be a good thing :-)  I would really like to see hbase
>> be more usable from other languages besides java.
> The issue is that HBase's client is necessarily not thin. It requires
> a lot of knowledge of HBase itself -- so certainly moving to PB would
> get us one step closer, but it would still be quite a bit of work to
> write a new client in another language. Certainly if someone comes
> along with one, that would be nice, but I don't think we should take
> it upon the project (yet) to maintain any other language clients.
> -Todd
>> On 2/13/2012 12:01 PM, Jimmy Xiang wrote:
>>> Hello,
>>> As HBase installation base is getting bigger, we are ready to work on the
>>> wire compatibility issue.
>>> The goal is to make HBase easier for operators to upgrade, while it is
>>> also easier for developers to
>>> enhance, re-architect if necessary.
>>> The attached is a proposal we came up.  We'd like to start with two
>>> phases:
>>> Phase 1: Compatibility between client applications and HBase clusters
>>> Phase 2: HBase cluster rolling upgrade within same major version
>>> Could you please review?
>>> Thanks,
>>> Jimmy
>> --
>> Jeff Whiting
>> Qualtrics Senior Software Engineer
>> jeffw@qualtrics.com

Jeff Whiting
Qualtrics Senior Software Engineer

View raw message