Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 atif_ijaz_khan@hotmail.com does not designate 216.139.236.26 as permitted
 sender)
Date: Wed, 6 Jun 2012 12:23:09 -0700 (PDT)
From: Atif Khan <atif_ijaz_khan@hotmail.com>
To: hbase-dev@hadoop.apache.org
Message-ID: <1339010589957-4018881.post@n3.nabble.com>
In-Reply-To: 
 <CADcMMgFDemap1JmRZrPo+onHwjdPukX9ZBvx_nw8caBX5KDteA@mail.gmail.com>
References: <1338953363055-4018856.post@n3.nabble.com>
 <1339006541587-4018878.post@n3.nabble.com>
 <CADcMMgFDemap1JmRZrPo+onHwjdPukX9ZBvx_nw8caBX5KDteA@mail.gmail.com>
Subject: Re: Shared HDFS for HBase and MapReduce
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is beginning to sound like a catch-22 problem.  I think I personally
would lean towards a single HDFS (high performing) cluster that can be
shared between various types of applications (realtime vs analytics).  Then
control/balance resource requirements for each application.  This would work
for scenarios where I can predict the different types of
applications/workloads before hand.  However, if for some reason the nature
of workload is to shift, that could potentially throw off the whole resource
equilibrium.

Are there any additional Hadoop specific monitoring tools that can be
deployed to predict resource/performance bottlenecks in advance (in addition
to regular BMC type tools)?

--
View this message in context: http://apache-hbase.679495.n3.nabble.com/Shared-HDFS-for-HBase-and-MapReduce-tp4018856p4018881.html
Sent from the HBase - Developer mailing list archive at Nabble.com.