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 emulating? 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. Thanks, --Suraj On Sat, Mar 5, 2011 at 2:21 PM, Todd Lipcon <t...@cloudera.com> wrote: > On Sat, Mar 5, 2011 at 2:10 PM, Ryan Rawson <ryano...@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 >
