hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tsuna <tsuna...@gmail.com>
Subject Re: HTable thread safety in 0.20.6
Date Fri, 04 Mar 2011 08:24:38 GMT
On Thu, Mar 3, 2011 at 8:34 PM, Suraj Varma <svarma.ng@gmail.com> wrote:
> This is interesting - so, doesn't asynchbase have any dependency on hbase
> jar or hadoop jar? How does it achieve this version independence?

Yes asynchbase doesn't depend on the HBase jar or Hadoop jar.  It's
just a re-implementation of the HBase client, but done differently.
The version independence is achieved by using the getProtocolVersion
RPC.  Depending on the version of the server, the client will adjust
its behavior to match the server's expectations.

> Also - does this mean that we could just swap the zookeeper quorum to that
> of a different version cluster and achieve a no outage upgrade (from
> client's perspective)?

Theoretically, yes.

In practice, bear in mind that HBase has a bad track record of
breaking backward compatibility between virtually every release (even
minor ones), although they often bump the protocol version number even
though there are no client-visible API changes (e.g. because only some
internal APIs used by the master or other administrative APIs
irrelevant for the client changed).  For a long time asynchbase didn't
actually care what version the server was, because the subset of the
API it was using was fairly stable.  Having said that, I'm hopeful
that since HBase is becoming increasingly popular and prevalent among
"NoSQL" databases, the versions are going to be increasingly backward
compatible and changes will be implemented in such a way that the
client will be able to detect different server versions and adjust
itself accordingly.  Eventually, I hope it'll be possible to have
rolling upgrades of a cluster, at least between minor versions.

Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com

View raw message