Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
  b=WXduwj1xIzTRLQy+af7RwO8ZU1NA1PNX0KsCGvZEMcA4cU60VAnA3Iw9thsfqO9ew07Ch/AgnMehdSRu8Cjet4HIT0KwdpayIeJeTR2XN+6WSBlyL/ErVNqE0Ex2XTnXXQs+kFvHqbFbS9KUpV9YhlkmYFgdx4Vr9SwKCfObaUc=;
Message-ID: <1371050074.79458.YahooMailNeo@web162404.mail.bf1.yahoo.com>
Date: Wed, 12 Jun 2013 08:14:34 -0700 (PDT)
From: Rahul Ravindran <rahulrv@yahoo.com>
Reply-To: Rahul Ravindran <rahulrv@yahoo.com>
Subject: Downside of too many HFiles
To: "user@hbase.apache.org" <user@hbase.apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="736800001-28581649-1371050074=:79458"

--736800001-28581649-1371050074=:79458
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=0AI am trying to understand the downsides of having a large number o=
f hfiles by having a large=A0hbase.hstore.compactionThreshold=0A=0A=A0 This=
 delays major compaction. However, the amount of data that needs to be read=
 and re-written as a single hfile during major compaction will remain the s=
ame unless we have large number of deletes or expired rows=0A=0AI understan=
d the random reads will be affected since each hfile may be a candidate for=
 the row, but is there any other downside I am missing?=0A=0A=0A~Rahul.
--736800001-28581649-1371050074=:79458--