hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Varma <svarma...@gmail.com>
Subject Re: HTable thread safety in 0.20.6
Date Mon, 07 Mar 2011 05:25:02 GMT
Thanks all for your insights into this.

I would agree that providing mechanisms to support no-outage upgrades going
forward would really be widely beneficial. I was looking forward to Avro for
this reason.

Some follow up questions:
1) If asynchbase client to do this (i.e. talk wire protocol and adjust based
on server versions), why not the native hbase client? Is there something in
the native client design that would make this too hard / not worth

2) Does asynchbase have any limitations (functionally or otherwise) compared
to the native HBase client?

3) If Avro were the "native" protocol that HBase & client talks through,
that is one thing (and that's what I'm hoping we end up with) - however,
isn't spinning up Avro gateways on each node (like what is currently
available) require folks to scale up two layers (Avro gateway layer + HBase
layer)? i.e. now we need to be worried about whether the Avro gateways can
handle the traffic, etc.

In our application, we have Java clients talking directly to HBase. We
debated using Thrift or Stargate layer (even though we have a Java client)
just because of this easier upgrade-ability. But we finally decided to use
the native HBase client because we didn't want to have to scale two layers
rather than just HBase ... and Avro was on the road map. An HBase client
talking native Avro directly to RS (i.e. without intermediate "gateways"
would have worked - but that was a ways ...

I think now that we are in the .90s, an option to do no-outage upgrades
(from client's perspective) would be really beneficial.


On Sat, Mar 5, 2011 at 2:21 PM, Todd Lipcon <todd@cloudera.com> wrote:

> On Sat, Mar 5, 2011 at 2:10 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
> > As for the past RPC, it's all well to complain that we didn't spend
> > more time making it more compatible, but in a world where evolving
> > features in an early platform is more important than keeping backwards
> > compatibility (how many hbase 18 jars want to talk to a modern
> > cluster? Like none.), I am confident we did the right choice.  Moving
> > forward I think the goal should NOT be to maintain the current system
> > compatible at all costs, but to look at things like avro and thrift,
> > make a calculated engineering tradeoff and get ourselves on to a
> > extendable platform, even if there is a flag day.  We aren't out of
> > the woods yet, but eventually we will be.
> Hear hear! +1!
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera

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