hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Beaudreault <bbeaudrea...@hubspot.com>
Subject Re: Poll: HBase usage by HBase version
Date Thu, 19 Mar 2015 00:46:44 GMT
My only complaint about this poll is the labels: "0.94.x - I like stable
releases".  It's not really about the stable releases for me, it's more
about the extremely difficulty of overcoming "the singularity" from 0.94 ->
0.96+ with no downtime in a reasonably complex production system.
Hortonwork's replication bridge may help with this, and we're hoping to put
engineering effort into this sometime this year.  But I'm sure I'm not the
only one for whom this is the sole reason to still be on 0.94.  Otherwise I
can't wait for the features and bug fixes in later versions and would
welcome *any* tools or JIRAs to help soften the blow of this upgrade.

On Wed, Mar 18, 2015 at 6:09 PM, lars hofhansl <larsh@apache.org> wrote:

> Realistically this should be weighed by number of machines.If you run a
> small 5 node cluster, sure, you can upgrade easily. But your vote does not
> count as much as somebody who's running 1000 machines.
> -- Lars
>       From: Otis Gospodnetic <otis.gospodnetic@gmail.com>
>  To: "user@hbase.apache.org" <user@hbase.apache.org>
>  Sent: Thursday, March 12, 2015 7:45 AM
>  Subject: Poll: HBase usage by HBase version
>
> Hi,
>
> Let's see where we are! :)
>
> 1-question poll:
> http://blog.sematext.com/2015/03/11/hbase-poll-version/
>
> Btw:
> 6 months ago the guess was that HBase version usage distribution was:
> 60% 0.94
> 30% 0.96
> 10% 0.98
>
> Another person said:
>
> *Now that 0.96 has been EOL'd you should see users migrating to 0.98
> rapidly, so the number should be more like 50% 0.94, 40% 0.98 10% 0.96
> within the next few months*
>
> See http://search-hadoop.com/m/DHED4VXL6y
>
> Thanks!
> Otis
> --
> Monitoring * Alerting * Anomaly Detection * Centralized Log Management
> Solr & Elasticsearch Support * http://sematext.com/
>
>
>
>

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