Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Hadoop Java Versions


Copy link to this message
-
Re: Hadoop Java Versions
Good point Todd.

I was speaking from the experience of people I know who are using 0.20.x

On Thu, Jun 30, 2011 at 5:24 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 30, 2011 at 5:16 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
>
> > You have to consider the long-term reliability as well.
> >
> > Losing an entire set of 10 or 12 disks at once makes the overall
> > reliability
> > of a large cluster very suspect.  This is because it becomes entirely too
> > likely that two additional drives will fail before the data on the
> off-line
> > node can be replicated.  For 100 nodes, that can decrease the average
> time
> > to data loss down to less than a year.  This can only be mitigated in
> stock
> > hadoop by keeping the number of drives relatively low.  MapR avoids this
> by
> > not failing nodes for trivial problems.
> >
>
> I'd advise you to look at "stock hadoop" again. This used to be true, but
> was fixed a long while back by HDFS-457 and several followup JIRAs.
>
> If MapR does something fancier, I'm sure we'd be interested to hear about
> it
> so we can compare the approaches.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB